The 10-Step FDE Delivery Loop

Reading boundary: This chapter separates official facts, the FDE working framework, and claims that still require field evidence. The framework is not an industry certification or compliance standard.

1. The loop is a sequence of evidence gates, not a waterfall

[FDE working framework] The ten steps provide a default order. They are not contractual phases, departmental handoffs, or a percentage-complete model. Evidence found later can force the project back: real-sample failures may invalidate the value hypothesis, evals may require less autonomy, and production controls may change the architecture.

A step is complete only when its exit conditions can be reviewed. A meeting, a submitted document, or a successful demo is an activity, not sufficient proof of delivery.

Use the same evidence states throughout the project: Missing, Planned, Observed, Verified, Contested, and Not publishable.

2. Three lines run through every step

Line	Persistent question	Typical evidence	False completion signal
Value	Is the problem worth solving, and is the result better than the baseline?	Volume, time, quality, risk, cost, adoption, outcome	A model demo or an estimated ROI
Reliability	How does the system fail, stay constrained, recover, and remain evaluated?	Evals, permissions, logs, rollback, SLOs, incidents	One successful run
Organization	Who decides, accepts risk, uses the system, and owns it after launch?	Sponsor, owner, RACI, approvals, training, transfer	“The project team owns it”

3. Minimum role set

One person may hold several roles, but no role may disappear.

Role	Minimum accountability
Business sponsor	Priority, resources, and business risk tolerance
Process owner	Current workflow, baseline, acceptance, and adoption outcome
FDE delivery lead	Integrity of the outcome chain, evidence gates, and cross-team decisions
Engineering/platform owner	Architecture, integration, deployment, and technical operation
Domain and eval owner	Correctness, severe failure, task sets, and human grading rules
Data/security/privacy/legal owners	Approval within their authority for data use, access, and risk controls
Service owner	Post-launch SLOs, alerts, incidents, cost, and change management
Users/adoption owner	Workflow participation, testing, feedback, training, and adoption decision

The FDE does not replace these owners. The FDE makes missing ownership visible and prevents the project from being declared complete while responsibility remains unresolved.

4. Ten-step overview

Step	Primary decision	Accountable lead	Minimum evidence	Exit condition
1. Observe the real work	What work are we actually changing?	FDE + process owner	Current-state map, roles, real cases	User, trigger, end state, and exceptions are confirmed
2. Establish the value baseline	Is the problem measurable and worth solving?	Process owner	Baseline, metric definitions, stop conditions	Testable value hypothesis approved by sponsor
3. Lock ownership and decision rights	Who decides, accepts, carries risk, and operates?	Sponsor	Accountability charter, RACI, gates	Every critical decision has one accountable role
4. Validate delivery boundaries	Do data, permissions, systems, law, and procurement allow it?	Governance owners	Data map, permission matrix, risk register	No ownerless hard blocker remains
5. Choose the minimum system shape	What is the simplest operable solution?	Engineering owner + FDE	Options, ADR, autonomy level	Minimum approach and trade-offs approved
6. Build a real-sample vertical slice	Do critical assumptions survive a real path?	Engineering owner	Runnable slice, traces, failure log	Continue, redesign, or stop decision made
7. Turn failure modes into eval gates	What quality and risk justify real traffic?	Eval owner	Task set, graders, thresholds, regression	Repeatable gate approved by business and risk owners
8. Integrate the production control plane	Can the system operate under identity, audit, and failure controls?	Engineering/security/service owners	Interfaces, permissions, audit, rollback drill	High-risk actions controlled; response path works
9. Prove adoption with controlled traffic	Do users complete real work and create net value?	Process/adoption owner	Release, usage, quality, cost, feedback	Scale, modify, or stop criteria reached
10. Convert the project into a sustainable service	Can the organization operate without the original FDE?	Service owner	SLOs, continuous evals, training, transfer drill	Independent operation or explicit retained service

5. Step 1: Observe the real work

Decision

What specific work, performed by which real user at which trigger, is the project trying to change?

Inputs

• The sponsor’s initial opportunity hypothesis
• A preliminary stakeholder list
• Permission to observe the workflow and inspect representative cases
• Known confidentiality, privacy, and access limits

Actions

1. Observe or interview the people who perform the work, not only their managers.
2. Map triggers, inputs, decisions, actions, handoffs, waiting, exceptions, and end states.
3. Separate the documented process from the process that actually happens, including spreadsheets, chat, copying, and manual compensation.
4. Select representative normal, edge, failed, and high-risk cases.
5. Record the systems, data, permissions, and human judgment currently involved.

Accountable roles

• Accountable: process owner
• Responsible: FDE delivery lead
• Required participants: real users, domain experts, system owners, and data/privacy owners when sensitive data is involved

Required evidence

• A current-state workflow confirmed by at least one real user
• Named users, trigger, end state, major exceptions, systems, and roles
• A representative sample set with provenance and handling restrictions
• An explicit observation-gap note covering people, systems, or cases not yet seen

Exit conditions

• The team can state who performs what work and when.
• A real user confirms the critical path and at least one exception path.
• Sample access has a defined purpose and authorized scope.
• The project is no longer defined only as “build an agent,” “add RAG,” or another technology request.

Common failure

Treating policy documents as field reality; interviewing only executives; using curated demo cases; collecting more data than the discovery purpose requires; or inventing the workflow without end-user participation.

Evidence basis and boundary

OpenAI’s current FDE role explicitly includes discovery with leaders and frontline teams, while Palantir’s current role describes entering the customer’s operating reality. NIST MAP requires intended use, context, stakeholders, impacts, and limits to be understood. The workflow artifact and exit test above are this handbook’s working framework, not an official vendor process. [OAI-FDE] [PAL-ROLE] [NIST-RMF]

6. Step 2: Establish the value baseline

Decision

Is the problem measurable and valuable enough to justify delivery effort, and what evidence would stop the project?

Inputs

• The current workflow and representative cases
• Available volume, cycle-time, quality, cost, risk, or revenue data
• Sponsor priorities and an initial investment range

Actions

1. Rewrite the request as a measurable problem statement; AI usage is not an outcome.
2. Define each metric’s denominator, time window, source, exclusions, and owner.
3. Establish the current baseline, including hidden preparation, review, rework, waiting, and failure-handling labor.
4. Use target ranges instead of unsupported point promises.
5. Define minimum acceptable value, stop conditions, and the no-project counterfactual.

Accountable roles

• Accountable: process owner
• Responsible: FDE delivery lead and business analyst
• Approver: business sponsor

Required evidence

• One-page problem statement
• Metric dictionary and dated baseline snapshot
• Value hypothesis with calculation method
• Known measurement gaps and proxy-metric rationale
• Continue, pause, and stop conditions

Exit conditions

• At least one baseline can be measured repeatedly.
• The metric owner can explain its source and refresh cadence.
• The sponsor agrees what result justifies scale and what result justifies stopping.
• Model accuracy is not being used as a direct substitute for business value.

Common failure

Publishing a percentage without a denominator; ignoring review and integration cost; using executive enthusiasm as outcome evidence; moving the success definition after development begins; or having no stop condition.

Evidence basis and boundary

OpenAI’s Deployment Company describes a focused diagnostic, an impact-prioritized roadmap, and measurable results. Frontier similarly frames deployment around measurable impact in existing systems. These are first-party operating claims, not independent outcome studies. The baseline and stop-gate format is this handbook’s framework. [OAI-DEPLOY] [OAI-FRONTIER] [NIST-RMF]

7. Step 3: Lock ownership and decision rights

Decision

Who can decide scope, accept risk, approve launch, judge value, and own the service after launch?

Inputs

• Confirmed problem, baseline, and initial scope
• Business, engineering, data, governance, operations, and user stakeholders
• Budget, timing, and organizational constraints

Actions

1. Name the sponsor, process owner, FDE, engineering owner, eval owner, governance owners, service owner, and adoption owner.
2. Create gates for scope, data, architecture, eval, launch, residual risk, scale, and stop decisions.
3. Assign one accountable role, required evidence, and a response expectation to each gate.
4. Define escalation paths and distinguish advisory input from approval authority.
5. State which decisions the FDE drives but cannot approve on behalf of the business, security, legal, privacy, or operations functions.

Accountable roles

• Accountable: business sponsor
• Responsible: FDE delivery lead
• Required confirmation: every person named as accountable or approver

Required evidence

• Project accountability charter
• RACI or equivalent ownership matrix
• Gate and escalation map
• Decision-log location and retention rule
• Named authority for residual-risk acceptance and project termination

Exit conditions

• Every critical decision has one accountable role rather than “the project team.”
• Security, privacy, legal, data, and operations have explicit entry points before production.
• Real users have a formal role in discovery, eval, and adoption.
• A post-launch service owner exists before rollout.

Common failure

A sponsor who disappears after kickoff; many veto holders but no decision owner; the FDE being asked to accept legal or business risk; operations arriving only before launch; or a RACI that named participants never confirmed.

Evidence basis and boundary

NIST AI RMF calls for documented roles, responsibilities, communication lines, and accountable executive decisions. Frontier places access control, audit, adoption, and system deployment in one organizational operating model. The minimum role set and decision-gate format are this handbook’s synthesis. [NIST-RMF] [OAI-FRONTIER]

8. Step 4: Validate delivery boundaries

Decision

What is permitted, feasible, and supportable under the real data, identity, system, legal, procurement, and operating constraints?

Inputs

• Workflow, sample set, baseline, and ownership map
• Existing architecture, data assets, vendors, and policies
• Preliminary industry and legal requirements

Actions

1. Inventory data categories, sources, owners, purposes, minimum necessary scope, retention, and deletion rules.
2. Map data flows, external models, tools, plugins, delegated processing, and cross-border paths.
3. Inventory identities, roles, service accounts, approvals, segregation of duties, and audit requirements.
4. Validate network, private deployment, latency, capacity, procurement, contract, intellectual-property, and vendor-exit constraints.
5. Maintain a risk register separating hard blockers, mitigable risks, open assumptions, and accepted limitations.
6. Trigger the required privacy, security, legal, or domain reviews; authorized specialists determine applicability.

Accountable roles

• Accountable: the relevant data, security, privacy, legal, procurement, or platform owner
• Responsible: FDE for the integrated constraint record; engineering owner for technical evidence
• Approvers: governance owners within their delegated authority

Required evidence

• Data inventory and data-flow diagram
• Identity and permission matrix
• Deployment, vendor, and system-boundary record
• Risk register with owner, mitigation, due date, and status
• References to required assessments, approvals, or legal advice
• Explicit prohibited actions and experiment-isolation rules

Exit conditions

• No hard blocker lacks an owner or decision date.
• Prototype data, accounts, and environments have authorized and auditable boundaries.
• Critical production paths for network, identity, deployment, and procurement are either demonstrated or marked as unresolved production-equivalence gaps.
• Residual risks have written acceptance, a bounded mitigation, a lower-risk design, or a stop decision from the authorized owner.

Common failure

Assuming data is anonymous without testing; using personal accounts or broad shared credentials; moving data to a third party before review; treating prompts as access control; or treating a generic legal checklist as project-specific advice.

Evidence basis and boundary

NIST frames AI risk in deployment context and requires ongoing management. MCP guidance addresses least privilege, token audience, authorization, SSRF, and session risks within MCP systems. OWASP highlights prompt injection, sensitive information disclosure, excessive agency, tool misuse, and identity abuse. Chinese laws may add duties depending on the data, service, sector, and deployment. None of these sources alone certifies project compliance. [NIST-RMF] [NIST-GENAI] [MCP-SEC] [MCP-AUTH] [OWASP-LLM] [OWASP-AGENTIC] [CN-PIPL] [CN-DSL] [CN-NETDATA] [CN-GENAI]

9. Step 5: Choose the minimum system shape

Decision

What is the simplest system that can test value while remaining evaluable, governable, and operable?

Inputs

• Problem, baseline, constraints, and risk register
• Representative cases and preliminary failure modes
• Available models, tools, systems, and team capabilities

Actions

1. Compare doing nothing, process change, rules, search, conventional software, RAG, LLM workflows, and agents.
2. Separate deterministic work, model judgment, human approval, and actions that must not be automated.
3. Define agent autonomy, tool scope, state, memory, approval, and termination conditions.
4. Compare buy, build, joint delivery, and reuse of an existing platform.
5. Record architecture decisions, rejected options, and conditions for adding complexity later.
6. Design fallback behavior for model, tool, permission, or risk failure.

Accountable roles

• Accountable: engineering/platform owner
• Responsible: FDE and architecture/engineering team
• Consulted: process, eval, security, service, and procurement owners

Required evidence

• Options matrix and architecture decision record
• Autonomy and human-approval matrix
• Model, tool, data, and system boundary diagram
• Latency, capacity, and cost budget
• Fallback plan and list of assumptions to test

Exit conditions

• The team can explain why a simpler design is insufficient, or why an agent is unnecessary.
• Critical assumptions, limitations, and non-promises are documented.
• High-risk actions do not rely on the model approving itself.
• The design can be tested by the eval gate and controlled by the production gate.

Common failure

Choosing multi-agent architecture first; treating RAG, memory, or MCP as mandatory; adding autonomy for demo value; comparing only model accuracy; or selecting a design that only one specialist can maintain.

Evidence basis and boundary

Anthropic recommends starting with the simplest viable pattern and distinguishes predefined workflows from agents. OpenAI’s agent guide recommends agents for workflows where deterministic approaches break down, while advising teams to start small, validate with real users, and add capabilities over time. The option matrix and autonomy gate are this handbook’s framework. [ANT-AGENTS] [OAI-AGENT-GUIDE]

10. Step 6: Build a real-sample vertical slice

Decision

Can the critical assumptions survive a controlled end-to-end path through real formats, tools, and observable final state?

Inputs

• Approved minimum system shape
• Authorized representative cases and an isolated environment
• Critical assumptions, failure hypotheses, and preliminary acceptance criteria

Actions

1. Build the thinnest end-to-end slice rather than a broad platform.
2. Use real formats, permission models, and interfaces where possible; record every simulation gap.
3. Capture input version, configuration, model, tool calls, trace, output, and final environment state for each run.
4. Run normal, edge, failed, and adversarial cases.
5. Compare with the current workflow and disclose hidden human correction.
6. Ask real users when they would trust, reject, or escalate the result.
7. Keep production writes read-only, sandboxed, or explicitly human-approved.

Accountable roles

• Accountable: engineering owner
• Responsible: FDE and engineering team
• Required participants: domain/eval owner, real users, and relevant data/security owners

Required evidence

• Repeatable vertical-slice version
• Sample provenance and handling record
• Traces and verified final states
• Failure log, human corrections, and known limits
• Baseline comparison and assumption decision log

Exit conditions

• At least one critical value assumption and one reliability assumption are tested on representative cases.
• Success does not depend on undisclosed manual completion outside the system.
• Major failures are reproducible and localized.
• Production-equivalence gaps are explicit.
• The team records a continue, redesign, or stop decision.

Common failure

Cherry-picking easy cases; using fake integrations and permissions; losing version and trace information; hiding manual cleanup; or allowing a prototype to write with broad production credentials.

Evidence basis and boundary

OpenAI’s current FDE role connects prototype, design, build, and production rollout rather than treating the prototype as completion. Frontier emphasizes agents built around enterprise data, tools, permissions, controls, and evaluation loops. NIST warns against assuming tests generalize when conditions differ from deployment. The “thin vertical slice” gate is this handbook’s design. [OAI-FDE] [OAI-FRONTIER] [NIST-RMF]

11. Step 7: Turn failure modes into eval gates

Decision

Which tasks must succeed, which failures are tolerable, and which failures block real traffic regardless of average score?

Inputs

• Workflow, representative cases, and vertical-slice traces
• Observed failures, business risk, and rollout scope
• Current human or legacy-system baseline

Actions

1. Build the task set top-down from the intended workflow and bottom-up from traces, user feedback, and observed failures.
2. Cover successful completion and distinct failures such as missing input, conflicting evidence, wrong tool, invalid parameters, denied access, inconsistent state, unsafe action, and inability to complete.
3. Evaluate final outcomes, critical trajectory behavior, and safety controls separately.
4. Combine deterministic checks, rules, model graders, and human review; calibrate high-risk judgments with humans.
5. Define severity-specific thresholds for quality, review rate, cost, and latency.
6. Record dataset provenance, version, representativeness, contamination risk, and uncovered areas.
7. Run regression after changes to prompts, models, tools, data, policies, or code.

Accountable roles

• Accountable: domain/eval owner
• Responsible: FDE and eval/engineering team
• Approvers: process owner and relevant risk owner

Required evidence

• Versioned task set and coverage matrix
• Failure taxonomy and severity model
• Graders, rubrics, human calibration, and disagreement log
• Baseline and candidate regression results
• Launch thresholds, launch blockers, and known limitations
• Permission and safety tests for consequential actions

Exit conditions

• Core success paths and major failure modes are represented.
• Graders are repeatable and have human calibration or review.
• Severe failures have independent limits and cannot disappear inside an average.
• Business and risk owners approve the gate.
• Every relevant change can produce a reproducible regression comparison.

Common failure

Vibe-based acceptance; only positive examples; average accuracy without severe-error limits; model graders without human calibration; test contamination; judging only the response instead of the environment’s final state; or never updating evals from production failures.

Evidence basis and boundary

Anthropic’s official agent eval guide recommends top-down and bottom-up task design, coverage of successful and failed behavior, multiple grader types, and production monitoring. OpenAI recommends task-specific, logged, automated, and continuous evaluation. NIST cautions against generalizing from narrow or anecdotal tests. Thresholds and severity gates remain project decisions. [ANT-EVALS] [OAI-EVAL] [NIST-RMF]

12. Step 8: Integrate the production control plane

Decision

Can the system operate under enterprise identity, authorization, audit, transaction, failure, and incident controls?

Inputs

• Candidate system that passed the eval gate
• Architecture, permission plan, risk register, and production requirements
• Named service owner, release strategy, and support path

Actions

1. Use production identity and least privilege rather than shared broad tokens.
2. Validate user input, external content, model output, and tool arguments structurally.
3. Require preview and approval for payments, messages, deletion, approval, permission changes, or other consequential side effects.
4. Design idempotency, retry, timeout, transaction, compensation, rollback, and human takeover.
5. Audit the user, agent, tool, data, approver, time, parameters, and final state.
6. Test prompt injection, sensitive-data leakage, tool misuse, supply-chain, session, and token attacks.
7. Establish monitoring, alerting, draft SLOs, incident severity, stop controls, and a rollback drill.
8. Cover deprovisioning, employee departure, vendor change, and key rotation.

Accountable roles

• Accountable: engineering/platform and security owners within their control domains
• Responsible: engineering, platform, SRE/service teams; FDE maintains cross-domain evidence
• Approvers: authorized business, data, privacy, legal, and operational owners

Required evidence

• Interface contracts, data mapping, and error semantics
• Tool/data permission matrix and authorization flow
• Threat model, security test, and remediation record
• Queryable audit-log sample
• Idempotency, rollback, degradation, and takeover drill
• Runbook, SLO draft, alerts, and incident contacts
• Human-review design for consequential actions

Exit conditions

• Every production identity and permission maps to a minimum business need.
• Consequential writes have authorization, preview, approval, or an equivalent control.
• Critical failures are detectable and rollback or degradation has been exercised.
• Audit evidence can reconstruct who initiated what action, with which inputs and result.
• Service and security owners approve controlled traffic.

Common failure

One privileged service account for everyone; raw model text driving SQL, shell, or approvals; confusing MCP connectivity with authorization; retry without idempotency; logs that cannot link action to final state; or an incident process that depends on the original FDE.

Evidence basis and boundary

Frontier describes shared business context, execution, evaluation, and governance layers. OpenAI’s current guardrail guidance separates automatic validation from human approval for sensitive actions. MCP security guidance covers authorization and token boundaries. OWASP adds prompt-injection, excessive-agency, tool, and identity risks. The production-control checklist and exit gate are this handbook’s synthesis. [OAI-FRONTIER] [OAI-AGENT-GUIDE] [OAI-GUARDRAILS] [MCP-SEC] [MCP-AUTH] [OWASP-LLM] [OWASP-AGENTIC]

13. Step 9: Prove adoption with controlled traffic

Decision

Under real users, real work, and bounded risk, does the system support sustained task completion and better net value than the original process?

Inputs

• System that passed production controls
• Defined pilot population, workflow, support model, and rollback point
• Launch, adoption, quality, cost, and stop thresholds

Actions

1. Use shadow mode, parallel comparison, staged rollout, or a bounded cohort.
2. Train users inside the workflow, including limits, review points, escalation, and feedback.
3. Measure task completion, frequency, retention, human review, severe errors, latency, cost, support load, and exit reasons.
4. Distinguish opening the product or generating content from completing the real task.
5. Feed new production tasks and failures into evals.
6. Compare with the original baseline and record simultaneous process, policy, or incentive changes.
7. Make the pre-agreed scale, maintain, modify, or stop decision.

Accountable roles

• Accountable: process/adoption owner
• Responsible: FDE, product/operations, engineering, and support teams
• Approvers: sponsor, service owner, and relevant risk owners

Required evidence

• Release version, date, cohort, scope, and rollback point
• Real-task completion and adoption funnel
• Online quality, severe failure, human-review, and support data
• Latency, capacity, and unit cost
• User feedback, rejection, fallback, and workflow-change record
• Interim outcome comparison using the original metric definitions
• Scale, modify, maintain, or stop decision

Exit conditions

• Minimum operating stability holds over the agreed observation window.
• Target users complete real tasks, not only training or demos.
• Quality, cost, and adoption are all within bounds.
• Production failures enter the eval and remediation loop.
• Sponsor and process owner make an explicit next-stage decision.

Common failure

Counting provisioned accounts as adoption; reporting praise while hiding fallback; measuring only a short forced-use period; saving user time while adding larger review and support cost; patching prompts without updating evals; or allowing a low-value pilot to continue indefinitely.

Evidence basis and boundary

OpenAI’s current FDE role includes production adoption, measurable workflow impact, and feedback from leaders and frontline teams. Deployment Company materials similarly connect production systems, adoption, and measurable results. Anthropic recommends monitoring real production distributions because offline task sets remain incomplete. Adoption thresholds are this handbook’s project gate. [OAI-FDE] [OAI-DEPLOY] [ANT-EVALS] [NIST-RMF]

14. Step 10: Convert the project into a sustainable service

Decision

If the original FDE leaves tomorrow, can the organization operate, evaluate, recover, change, and retire the system?

Inputs

• Production, adoption, and interim outcome evidence
• Target operating and commercial model
• Open risks, technical debt, vendor dependencies, and product feedback

Actions

1. Name service, business, eval, security, and vendor owners.
2. Establish SLOs, cost budgets, capacity, alerts, on-call, incident, change, and release processes.
3. Maintain continuous evals using production samples, new tasks, and severe-failure tracking.
4. Review accounts, permissions, retention, vendors, models, and third-party tools on a defined cadence.
5. Complete runbooks, training, incident tabletop, rollback drill, and backup staffing.
6. Transfer code, configuration, prompts, pipelines, task sets, eval results, log access, and deployment authority.
7. Separate customer-specific configuration, reusable method, product gap, and customization that should be retired.
8. Set the next scale, maintain, rebuild, renew, or decommission decision date.

Accountable roles

• Accountable: service owner
• Responsible: customer engineering/service team and FDE
• Approvers: process owner, sponsor, and relevant risk owners

Required evidence

• Service catalog, SLOs, alerts, and incident process
• Cost, capacity, and vendor-dependency view
• Continuous-eval plan and regression history
• Access review, data-lifecycle, and key-rotation record
• Runbook, training, and drill results
• Asset and responsibility transfer checklist
• Product feedback, customization debt, and decommission plan

Exit conditions

• The new owner completes an operating check, incident exercise, and regression without live help from the original FDE.
• Production credentials, eval assets, logs, and release authority are institutionally owned.
• Model or vendor change has a re-evaluation and rollback path.
• Retained external operation has an explicit scope, SLO, cost, and exit mechanism.
• The service has a next value-review date and retirement criteria.

Common failure

Calling a document dump a handoff; teaching only normal use; leaving unique production access with one FDE; having no eval owner; accumulating unbounded customer customization; or never testing whether the service still creates value.

Evidence basis and boundary

Frontier emphasizes evaluation and optimization loops, governance, and repeatable patterns an organization can own. Deployment Company materials describe long-term operational support and adoption. Anthropic stresses production monitoring and updating evals from real traffic. NIST includes post-deployment monitoring, training, response, deactivation, and decommissioning. The independent-operation drill is this handbook’s exit test. [OAI-FRONTIER] [OAI-DEPLOY] [ANT-EVALS] [NIST-RMF]

15. Five decision gates

The ten steps organize delivery work. The five gates control whether the project deserves more time, access, risk, and capital. Stopping is a valid outcome at every gate.

Gate	Position	Required question	Valid decisions
G0: Worth solving?	After Step 2	Is the problem measurable, valuable, and bounded by stop conditions?	Continue discovery / pause / stop
G1: Permitted and feasible?	After Steps 4-5	Do ownership, data, permissions, architecture, and economics hold?	Prototype / reduce scope / redesign / stop
G2: Ready for real traffic?	After Step 7	Are tasks, failure modes, thresholds, and risk acceptance executable?	Controlled pilot / collect evidence / stop
G3: Ready for production operation?	After Step 8	Are identity, audit, rollback, incident response, and service ownership ready?	Stage rollout / delay / degrade / stop
G4: Scale and transfer?	Across Steps 9-10	Do value, adoption, reliability, and operating ownership hold together?	Scale / maintain / rebuild / retire

16. China-context hypotheses

The following are [China-context hypotheses], not universal descriptions of Chinese enterprises. Regulations can establish duties, but they do not prove that every organization follows the same process.

16.1 Procurement may precede discovery

Budget, tender, or contract scope may exist before the delivery team reaches real users. Maintain two explicit states: contractual deliverables and actual outcome evidence. Contract acceptance can contribute evidence, but it does not prove adoption or business result.

16.2 Prototype and production environments may diverge sharply

Early experiments may use public models or external SaaS, while production requires network isolation, private deployment, centralized identity, or approved infrastructure. Step 6 should maintain a production-equivalence gap list. Quality, latency, cost, and security claims should not be generalized across unresolved gaps.

16.3 Data, systems, process, and veto authority may sit in different departments

Business teams may own value but not data; technology teams may own systems but not workflow authority; risk functions may approve but not implement. Steps 3 and 4 should set cross-department evidence formats, decision deadlines, and escalation paths early.

16.4 A generic compliance checklist is insufficient

• China’s Personal Information Protection Law may affect purpose limitation, minimum necessary processing, sensitive personal information, automated decision-making, delegated processing, and cross-border handling. [CN-PIPL]
• The Data Security Law addresses classification, lifecycle security, and monitoring and response responsibilities. [CN-DSL]
• The Network Data Security Management Regulations took effect on January 1, 2025 and add requirements for network-data processing activities. [CN-NETDATA]
• The Interim Measures for Generative AI Services primarily address services offered to the public in mainland China. Applicability to an internal enterprise system depends on service users, function, industry, and deployment. [CN-GENAI]

This chapter is not legal advice. Authorized legal, privacy, security, and sector specialists must determine applicability.

16.5 Contract acceptance may over-weight documents, while adoption may be distorted by mandate

A project can satisfy interface, report, and training milestones without sustained use. Conversely, short-term mandatory usage can overstate adoption. Step 9 should preserve evidence of real task completion, fallback to the old process, human review, user exit reasons, and incentive changes.

16.6 Multi-vendor delivery needs a final owner

Model providers, integrators, software vendors, consultants, and internal teams may all contribute. The ownership model should separately assign model issues, business rules, interfaces, incidents, eval maintenance, data, prompts, and operating assets. “The vendor owns it” is not a sufficient role definition.

17. Evidence gaps for China enterprise claims

As of 2026-07-19, this chapter still lacks the following E2/E3 evidence:

1. Three China enterprise AI projects documented against the same ten-step framework.
2. One regulated-industry project with reviewable permission, audit, rollout, and transfer evidence.
3. One successful demo that failed to achieve adoption.
4. One project stopped because of data, procurement, cost, or ownership constraints.
5. Joint review of Steps 3, 4, and 8 by security, legal, privacy, procurement, and data-governance practitioners.
6. A redacted example where contractual acceptance metrics diverged from business outcomes.
7. Measured quality, latency, cost, and control differences between an external prototype and an isolated or private production environment.

Until these gaps are filled, the chapter can be published as a working delivery framework, but not as a method proven across Chinese enterprises.

19. English conclusion

The FDE is not valuable because the role combines product, engineering, consulting, and program management. The role is valuable when it prevents one stage of success from being mistaken for the success of the whole outcome chain.

At every step, ask:

1. What new evidence exists on the value line?
2. What new evidence exists on failure, control, recovery, and continuous evaluation?
3. Which decision, risk, and long-term owner is now explicit?

When those questions cannot be answered, the disciplined move is to go back, reduce scope, or stop. More features do not repair missing evidence.

---

Action asset

Open the FDE 10-Step Delivery Canvas for project kickoff, weekly review, stage gates, and transfer.

Sources and Evidence Boundaries

All sources below were accessed or rechecked on 2026-07-19. Short quotations elsewhere in the chapter remain within the editorial excerpt limits. Dynamic pages may change; citations should be read with the access date, and source changes or factual errors are welcome as correction reports.

ID	Primary source	Publisher/date	Supports	Does not prove
OAI-FDE	Forward Deployed Engineer, NYC	OpenAI; dynamic job page	Current OpenAI role scope across discovery, technical scoping, design, build, rollout, adoption, measurable workflow impact, and field feedback	A universal FDE definition or evidence that every engagement succeeds
OAI-DEPLOY	OpenAI launches the OpenAI Deployment Company	OpenAI; 2026-05-11	OpenAI’s stated deployment model, focused diagnostic, impact roadmap, production work, adoption, and measurable results	Independent validation of commercial or customer outcomes
OAI-FRONTIER	Introducing OpenAI Frontier	OpenAI; 2026-02-05	Enterprise context, execution, evaluation/optimization, controls, identity, audit, and repeatable production patterns	A vendor-neutral architecture standard or a compliance certification
OAI-AGENT-GUIDE	A practical guide to building agents	OpenAI; living guide	Agent suitability, starting small, real-user validation, tool design, fallback, guardrails, and human intervention	That an agent is required for the project or that the described pattern is optimal everywhere
OAI-EVAL	Evaluation best practices	OpenAI Developers; living documentation	Task-specific evaluation, logging, automated scoring, human judgment, and continuous regression	Business acceptance thresholds or independent proof of a deployed system’s quality
OAI-GUARDRAILS	Guardrails and human review	OpenAI Developers; living documentation	Automatic input/output/tool checks and human approval before sensitive side effects	Complete application security or authorization design
ANT-AGENTS	Building effective agents	Anthropic; 2024-12-19	Workflow/agent distinction, simple composable designs, tool contracts, and adding complexity only when justified	A universal production architecture or independent benchmark
ANT-EVALS	Demystifying evals for AI agents	Anthropic; 2026-01-09	Top-down and bottom-up task construction, success and failure coverage, mixed graders, traces/outcomes, and production monitoring	Project-specific risk tolerance, legal approval, or a complete security program
PAL-ROLE	Forward Deployed Software Engineer, New Grad - Commercial	Palantir official ATS; dynamic job page	Palantir’s current end-to-end FDE role, customer reality, stakeholder work, data, architecture, and operational change	The responsibility model of every Palantir team or the wider FDE market
NIST-RMF	Artificial Intelligence Risk Management Framework 1.0	NIST; 2023-01-26	Govern, Map, Measure, Manage; documented responsibilities; context; deployment-relevant testing; monitoring and retirement	Legal compliance by itself; the framework is voluntary and requires contextual implementation
NIST-GENAI	Generative AI Profile, NIST AI 600-1	NIST; 2024-07-26	GenAI-specific risk considerations and actions that extend AI RMF	China-specific legal compliance or project acceptance
MCP-SEC	MCP Security Best Practices	Model Context Protocol; living documentation	OAuth/authorization risks, least privilege, token handling, SSRF, sessions, and MCP threat patterns	Security outside the MCP boundary or compliance certification
MCP-AUTH	MCP Authorization	Model Context Protocol specification; 2025-11-25 version	Authorization roles, resource indicators, token audience, and protocol-level requirements	A complete enterprise IAM design or permission model for business actions
OWASP-LLM	OWASP Top 10 for LLM Applications	OWASP GenAI Security Project; current 2025 release	Prompt injection, sensitive information disclosure, excessive agency, output handling, supply-chain, and related LLM risks	Exhaustive threat coverage, legal compliance, or proof that mitigations work in a specific deployment
OWASP-AGENTIC	OWASP Top 10 for Agentic Applications for 2026	OWASP GenAI Security Project; published 2025-12-09 as the 2026 release	Tool misuse, identity/privilege abuse, memory/context risks, orchestration, and human-agent trust boundaries	A formal standard, certification, or complete project threat model
CN-PIPL	中华人民共和国个人信息保护法 / Personal Information Protection Law	National People’s Congress; passed 2021-08-20, effective 2021-11-01	Primary legal text for personal-information processing obligations in China	Project-specific legal advice or a conclusion that every AI project processes personal information
CN-DSL	中华人民共和国数据安全法 / Data Security Law	National People’s Congress; passed 2021-06-10, effective 2021-09-01; official full-text republication by CAC	Primary legal text for data classification, security management, monitoring, and response	A complete sector-specific compliance determination
CN-NETDATA	网络数据安全管理条例 / Network Data Security Management Regulations	State Council; promulgated 2024-09-30, effective 2025-01-01	Primary rules for network-data processing activities and related responsibilities	Automatic applicability to every internal AI experiment
CN-GENAI	生成式人工智能服务管理暂行办法 / Interim Measures for Generative AI Services	CAC and six other authorities; published 2023-07-13, effective 2023-08-15	Primary rules for generative AI services offered to the public in mainland China	A conclusion that every private or internal enterprise AI system falls within the same scope

Final evidence statement

• Official facts: current role expectations, published vendor methods, technical documentation, standards, and legal texts are cited with source and access date.
• First-party claims: OpenAI, Anthropic, and Palantir materials establish what those organizations say they do; they are not treated as independent proof of outcomes.
• FDE working framework: the ten names, sequence, three lines, artifacts, gates, evidence states, and exit conditions are original editorial synthesis for this handbook.
• China-context hypotheses: organizational and procurement variants remain hypotheses until supported by reviewable China enterprise project evidence.
• Beta status: this chapter is a public working framework. It has not been validated across Chinese enterprise projects and does not represent completed project-specific legal, privacy, security, confidentiality, or compliance review. The framework will continue to evolve; factual corrections and reviewable field evidence are welcome and will be reflected in later versions.