# Forward-Deployed Engineering Brief

Source: https://akoum.me/blog/forward-deployed-engineering-brief-template

Deployment: [short name]
Status: [discovery | build | validation | canary | scale | stopped]
Brief owner: [one editor]
Workflow owner: [person accountable for the current operation]
Technical owner: [person who will operate the deployed system]
Sponsor: [person who can decide scope and accept risk]
Decision date: [YYYY-MM-DD]
Last updated: [YYYY-MM-DD]

## 1. Outcome in one sentence

For [named users], improve [workflow outcome] from [baseline] to [target]
without worsening [quality, safety, cost, or compliance guardrail].

## 2. Current workflow and baseline

- Trigger and desired terminal outcome:
- People, steps, systems, and handoffs:
- Volume, queue time, handling time, error, rework, and cost:
- Known exceptions and recent failures:
- Evidence source and measurement window:

## 3. Users and decision-makers

- Primary operator:
- Person affected by the result:
- Data, security, and compliance owners:
- Who approves rollout, rollback, and expansion:

## 4. Production hypothesis

If we [bounded intervention], then [named users] will [changed behavior or
outcome], because [reason], demonstrated by [evidence].

## 5. Scope and non-goals

- Included users, cases, geography, systems, and time window:
- Explicitly excluded:
- Existing workflow retained as fallback:

## 6. Constraints and access

- Data sources, sensitivity, residency, retention, and tenant boundaries:
- Identity, permissions, APIs, infrastructure, and deployment policy:
- Legal, regulatory, procurement, or model-provider constraints:
- Missing access and owner/date to resolve it:

## 7. Narrow production slice

- User-visible path from trigger to terminal action:
- AI/model responsibilities:
- Deterministic software responsibilities:
- Human review and escalation:
- Versioned prompts, models, tools, and retrieval configuration:

## 8. Quality and evaluation contract

- Representative common, edge, known-failure, and adversarial cases:
- Task-specific pass criteria:
- Unacceptable failure classes:
- Human calibration and regression cadence:
- Evaluation owner and evidence location:

## 9. Authority, security, and failure

- System may read:
- System may propose:
- System may change automatically:
- Actions requiring human approval:
- Timeouts, retries, fallback, rate limits, audit trail, and kill switch:
- Threats and residual risks accepted by whom:

## 10. Success measures

- Workflow outcome:
- AI quality:
- Reliability and latency:
- Cost per completed outcome:
- Adoption, override, escalation, and safety:
- Pass, revise, stop, and scale thresholds:

## 11. Rollout and rollback

- Shadow or offline phase:
- Canary users/cases and duration:
- Monitoring and review cadence:
- Stop conditions and rollback owner/procedure:

## 12. Adoption, operations, and handoff

- Training and workflow change:
- Dashboard, alerts, runbook, support, and on-call owner:
- Customer team capability required before handoff:
- Artifacts delivered and handoff rehearsal date:

## 13. Productization and next decision

- Customer-specific work:
- Reusable configuration, tooling, documentation, or product primitive:
- Evidence that would change the roadmap:
- On the decision date, choose: scale | revise | stop.
- Decision log with dates, evidence, and owners: