“Feed it back to product” sounds sensible in a field-engineering meeting. It is not a governance instruction.

What exactly is being fed back? A customer's raw records? A generalized observation about a workflow? An evaluation set built from real cases? A product requirement? Code written during the deployment? Those assets have different owners, risks, and useful lives. Calling all of them “feedback” hides the decisions that make field learning useful or exposed.

The field-to-product loop is a real part of the FDE model. Current OpenAI and Anthropic role descriptions connect deployment work with reusable product or research learning. AI Engineer speakers from Factory and Cognition also describe field teams as a source of recurring product signals.

That evidence establishes an operating objective. It does not establish contractual rights. A job description cannot determine who owns customer data, code, or evaluation artifacts. My analysis is that a durable loop needs five asset types, each with explicit ownership and disposition.

1. Customer data and operational context

This category includes records, prompts, outputs, logs, workflow observations, configuration, screenshots, and the contextual detail that makes the deployment intelligible. It is usually the most sensitive and the least appropriate to treat casually.

Before access, ask what is needed for the approved purpose, where it may be processed, who may see it, how long it may remain, and what happens at closeout. Use the smallest approved slice that can answer the current question. Keep identities, permissions, storage, logs, exports, and deletion visible.

Technical ability is not permission. An engineer's access inside a customer environment does not imply that a product team may retain or reuse the same material elsewhere.

Official provider controls show why product specificity matters. OpenAI publishes endpoint-level platform data controls. Anthropic's commercial-product guidance describes its processor role under its commercial terms. Both pages can change, and a specific enterprise agreement may differ. They are controls to verify, not substitutes for contract, privacy, security, or legal review.

2. Generalized patterns

A generalized pattern is an abstraction: several deployments might reveal, for instance, that an approval step is routinely missing from a workflow. The pattern is valuable because it can inform product design without carrying all of the source context.

But “anonymous” is not a magic word. A rare workflow, distinctive system combination, or precise failure mode may still identify a customer or expose proprietary practice. The team needs a test for when a lesson has been abstracted enough, who reviews that conclusion, what source material was excluded, and where the generalized learning may go.

The question is not whether learning should happen. It is whether the retained pattern still carries information the provider is not authorized to use.

3. Evaluation artifacts

Evaluation assets include test cases, rubrics, labels, expected results, failure categories, and production feedback used to judge behavior. They turn anecdotes into repeatable tests. They may also encode the customer's domain knowledge and real operating cases.

Ownership can differ across the evaluation design, source examples, labels, and any derived benchmark. Contracting, product, data, and legal owners may need to decide whether those parts transfer, remain with the client, may be generalized, or may be reused. There is no responsible default allocation hidden in the word “eval.”

The practical step is to separate the parts and record their provenance. An evaluation method can sometimes be reusable even when its customer examples are not. That possibility still requires an authorized decision.

4. Product requirements

A requirement describes product behavior: support a permission boundary, expose a review state, handle a failure mode, or add an integration. It is more abstract than the customer data that revealed it, yet it can still disclose strategy or confidential workflow design.

A disciplined field-to-product interface should capture the problem, recurrence evidence, affected product primitive, and operating consequence while excluding raw context that product does not need. Product ownership can then decide whether the signal becomes roadmap work, a reusable delivery asset, a bounded exception, or no action.

The key question is whether the requirement can be made useful without carrying customer context across the boundary.

5. Reusable code and configuration

Code may include connectors, prompts, policy configuration, orchestration, deployment scripts, interface components, and internal tools. “Reusable” can mean technically portable, contractually reusable, or merely similar enough to inspire new work. Those meanings should not be collapsed.

Record what existed before the engagement, what was created within it, what incorporates client material, what must transfer, and what may be retained or reused after authorized review. Repositories, dependency records, provenance, licenses, access, and data location should make the answer traceable.

A developer's memory is not an IP register. A copy in a provider repository should not silently decide the issue either.

Put disposition into intake

The five categories become manageable when deployment intake names a few fields for each: purpose, owner, approved location, access, permitted use, external feedback path, retention, transfer, deletion, and required approver. Material uncertainty becomes a decision with an owner instead of a promise to “sort out later.”

This worksheet would be an operating aid, not legal advice. It cannot replace contract, privacy, security, employment, records, or intellectual-property review. Terms vary by provider, product, customer agreement, region, and date. The delivery team's job is to surface the decisions early enough for authorized people to make them.

Customer proximity does not automatically create product learning. A useful loop is selective: retain what is authorized, generalize what can be responsibly abstracted, transfer what must remain with the client, and delete what no longer has an approved purpose.

The product compounds when the team can explain what crossed the field boundary and why. Quietly moving every artifact upstream is unmanaged exposure, not learning.

Sources and evidence notes

The five-asset taxonomy and disposition map are Scott's proposed analysis. Provider terms and customer agreements require current authorized legal review.