Launch, Operate, and Handoff
Key takeaway: 本文出自 davidahmann/fde-guide 项目在 DeepWiki 上的发布，系统阐述 Forward Deployed Engineering (FDE) 交付循环的终结阶段「Launch, Operate, and Handoff」。该阶段将已验证构建过渡为生产服务，核心围绕五个非线性的生产发布门禁（Gate 0: Design 至 Gate 4: Bounded）展开，门禁映射到 solution-release.release_status 状态，任何活跃门禁均可触发暂停或回滚。进入影子或金丝雀发布前，FDE 必须完成 Production Service Readiness (PSR) 包，采用 designed→tested→operational 的证据词汇严格衡量身份认证、持久状态、异步工作、遥测和失败回滚等维度的成熟度。客户交接以操作能力转移而非文档交付为标准，接收方须演示 Harness Changes、Evaluation、Incident Response 和 Reconciliation 四项能力。上线后进入分层运营节奏：连续关注安全可用，每日处理事件与 SLO，每周分析行为回归，每月基于实现价值 vs. 成本决定扩展或退役。生产学习环通过分类、夹具创建、门禁修复和移交 Field Learning Register，将现场经验闭环回工程，并定义客户配置、客户自有扩展、产品/平台能力和限时实验四类重用权限，确保知识产权与保密合规。
- Launch, Operate, and Handoff 是 FDE 交付循环的最终阶段，将已验证构建转变为生产服务，包含发布门禁、PSR、交接和持续审查。
- 发布流程采用非线性门禁模型，从 Design、Sandbox、Shadow、Canary 到 Bounded，任何活跃门禁都可触发暂停或回滚，且与 solution-release.release_status 绑定。
- 在进入 Shadow 或 Canary 之前必须完成 Production Service Readiness 包，使用 designed→tested→operational 等严格词汇衡量成熟度，且仅凭模型输出不能超越 designed。
- 客户交接以操作能力转移为唯一验收标准，接收方须演示安全变更、评估、事件响应和外部效果修正四项能力。
- 上线后运营遵循持续、每日、每周、每月的分层节奏，分别聚焦安全可用、事件管理、行为分析和价值采纳。
- 生产学习环通过分类、夹具创建、门禁修复和移交到 Field Learning Register，将生产信号闭环回工程，决定修复是否为可复用模式或平台变更。
- 现场学习成果必须清理重用权限，分为客户配置、客户自有扩展、产品/平台能力和限时实验四类，确保知识产权与保密约束。
FDE 交付循环的最后一环向来是成败的关键，这份指南直击「启动-运营-交接」的工程化核心。它没有空谈最佳实践，而是提供了从沙箱到全量发布的逐级门禁、可量化的生产就绪评估词汇，以及以操作能力转移为唯一验收标准的客户交接矩阵。对于任何试图在复杂环境中交付 AI/Agent 系统的团队，这套严谨的治理框架和持续学习闭环都值得一字一句地拆解复用。
Launch, Operate, and Handoff 是 FDE 交付循环的最终阶段，将已验证构建转变为生产服务，包含发布门禁、PSR、交接和持续审查。
—— 络石智能编辑部 · Editor's PickLaunch, Operate, and Handoff
Last indexed: 16 August 2026 (7d1d11)
Launch, Operate, and Handoff Copy link to header
This stage represents the culmination of the Forward Deployed Engineering (FDE) delivery loop, transitioning a system from a verified build into a production service. It encompasses rigorous release gating, the formal transfer of operational capability to the customer, continuous service review, and the extraction of reusable patterns into the field-learning register.
Production Release Gates Copy link to header
The release process follows a non-linear progression where any active gate can trigger a pause or rollback. For agentic systems, these gates are mapped to specific solution-release.release_status values and artifact bindings operations/release-gates.md 5-23
Gate Progression Model Copy link to header
Gate Requirements and Controls Copy link to header
| Gate | Primary Focus | Key Artifacts / Pass Conditions | Core Controls |
| --- | --- | --- | --- |
| 0: Design | Integrity | Workflow Charter, Data Readiness, System Design, Tool Contracts | ARC-001, CTX-001, TOL-001 |
| 1: Sandbox | Safety | 100% Contract Test pass, Deny-by-default Auth, Egress rules | SEC-001, REL-001, EVA-002 |
| 2: Shadow | Performance | Accepted outcome threshold met, 0 prohibited effects | VAL-001, OPS-001, EVA-001 |
| 3: Canary | Reliability | Tested Kill Switch, Staged Writes, On-call owner named | REL-004, OPS-002, SEC-006 |
| 4: Bounded | Expansion | Multi-tenant isolation, specific risk slice validation | IAM-002, CST-002, REL-005 |
Sources: operations/release-gates.md 5-115
Production Service Readiness (PSR) Copy link to header
Before advancing to shadow or canary gates, an FDE must complete a Production Service Readiness packet. This record assembles target-specific evidence against the Guide's controls templates/production-service-readiness.md 1-5
PSR Evidence Vocabulary Copy link to header
The PSR uses a strict vocabulary to describe maturity. Crucially, generated output or model judgment alone cannot advance a row beyond designed templates/production-service-readiness.md 23-32
required: Dimension applies, but evidence is missing.designed: Bounded design exists, but behavior not exercised.tested: Executable target-system evidence exists for representative/negative cases.operational: Production telemetry proves control is owned, monitored, and recoverable.
PSR System Mapping Copy link to header
The PSR ensures that high-level operational requirements are mapped to specific engineering entities and controls.
| PSR Dimension | Code/System Entity | Cited Controls |
| --- | --- | --- |
| Identity & Auth | Tenant binding, Scopes, Policy revision | IAM-001, SEC-005 |
| Durable State | Source of truth, Retention, Recovery point | STA-001, OPS-005 |
| Async Work | Queues, Idempotency keys, Retries | REL-001, REL-004 |
| Telemetry | Trace identity, Effect receipts, SLOs | OPS-001, OPS-006 |
| Failure/Rollback | Kill switch, Safe fallback, Readback | DEL-002, CTX-009 |
Sources: templates/production-service-readiness.md 38-90 tests/production-service-readiness.test.mjs 10-50
Customer Enablement and Handoff Copy link to header
Handoff is defined by the transfer of operating capability, not the delivery of documentation. The process is complete only when the receiving team demonstrates they can operate, change, and recover the system independently templates/customer-enablement-handoff.md 1-4
Handoff Capability Matrix Copy link to header
The receiving team must demonstrate proficiency in the following areas:
- Harness Changes: Safely versioning a behavior component and running affected-route tests templates/customer-enablement-handoff.md 38
- Evaluation: Authoring and running a new evaluation case with valid fixtures and graders templates/customer-enablement-handoff.md 37
- Incident Response: Executing a "Game Day" from detection to containment using the kill switch templates/customer-enablement-handoff.md 42
- Reconciliation: Identifying and correcting external effects via source-of-truth comparison templates/customer-enablement-handoff.md 43
Handoff Data Flow and Ownership Copy link to header
Sources: templates/customer-enablement-handoff.md 5-62 research/2026-08-10--fde-product-boundaries-and-capability-transfer.md 47-50
Continuous Operations and Review Copy link to header
Post-launch, the system enters a layered operating cadence. Governance is treated as a recurring set of decision rights rather than a one-time checklist playbooks/03-operate-and-scale.md 20-30
Operating Cadence Copy link to header
| Cadence | Focus | Key Decisions | | --- | --- | --- | | Continuous | Safety & Availability | Contain, degrade, or continue based on prohibited effects/denials. | | Daily | Incident Management | Reconcile effect-unknown runs; SLO burn management. | | Weekly | Behavior Analysis | Fix regressions; add replay fixtures for behavior clusters. | | Monthly | Value & Adoption | Expand, constrain, or retire based on realized value vs. cost. |
Production Learning Loop Copy link to header
FDEs use production signals to close the loop back to engineering:
- Triage: Identify the first divergent state or violated invariant playbooks/03-operate-and-scale.md 83-85
- Fixture Creation: Generate a sanitized replay fixture for the failure playbooks/03-operate-and-scale.md 87
- Gated Fix: Apply candidate fix on an isolated branch and verify against the regression suite playbooks/03-operate-and-scale.md 88-89
- Handoff to Product: Record the learning in the Field Learning Register to determine if the fix should be a reusable pattern or a platform change playbooks/03-operate-and-scale.md 92
Sources: playbooks/03-operate-and-scale.md 20-97 templates/production-service-review.md 1-116
Field Learning and Reuse Rights Copy link to header
- Customer Configuration: Target-specific settings.
- Target-Owned Extension: Code in the customer's normal repository.
- Product/Platform Capability: Shared features owned by product engineering.
- Time-Bounded Experiment: Assets with a mandatory destruction date.
Before field work is productized, FDEs must clear reuse rights, ensuring that intellectual property and confidentiality constraints are respected research/2026-08-10--fde-product-boundaries-and-capability-transfer.md 51-54
Tags
Related Topics
Expert Comment
This article is curated by the editorial team from public sources for reference only.