# FDE field workbook: from evidence to ownership

Use this workbook with one customer workflow throughout the [learning path](../index.html#learn). The prompts and Northstar examples below are original teaching exercises, not claims about a real deployment. Copy a template into your project, replace the example, and attach evidence before marking it complete.

The accompanying [source guide](source-methods.md) explains the contributions and limits of Richard Buehling's *Forward Deployed* (Benmore, February 2026) and Panaversity's *AI Agent Factory*. This workbook adapts their emphasis on discovery, explicit intent, governed knowledge, and operational ownership. It does not reproduce either book or prescribe one vendor's stack.

## 1. Discovery evidence ledger

**Decision:** Is there a worthwhile and feasible problem here?

| Claim | Evidence and date | Status | Decision owner | Next check |
| --- | --- | --- | --- | --- |
| Eligibility lookup is the main delay | Five synthetic request replays | Hypothesis; small sample | Dispatch lead | Include urgent and out-of-hours jobs |
| We may update assignments | No permission record yet | Unverified | Scheduling owner | Confirm permitted fields and identities |
| A faster suggestion saves operator time | No timed comparison yet | Unverified | Operations sponsor | Measure review plus correction time |

Use observed, reported, inferred, or unverified as separate evidence labels. Record conflicting claims explicitly. An AI-generated summary is a pointer back to the underlying evidence, not a new interview.

Name the sponsor, daily operator, domain reviewer, system owner, and person who accepts the result. For each, record their desired outcome, constraint, and decision authority. Ask what happens if this project does not proceed. A firm deadline may reflect an external dependency; it may also be negotiable.

**Exit check:** The largest unresolved assumption has an owner and a validation action. If it controls feasibility, resolve it before making an unconditional delivery promise.

## 2. One-page delivery specification

**Decision:** What exactly will this release do?

- **User and trigger:** A dispatcher receives a repair request.
- **Current baseline:** Measure median routing time, tail latency, rework, and eligibility errors on an agreed sample. Mark all exercise values as synthetic.
- **First outcome:** Suggest an eligible technician with supporting records, then let the dispatcher decide.
- **Inputs:** Request ID, region, job type, technician availability, eligibility policy version, and caller identity.
- **Output:** Recommendation, evidence IDs, unresolved questions, and review status.
- **Authority:** The worker may read permitted records and save a draft. Assignment requires a dispatcher action enforced by the write endpoint.
- **Non-goals:** No automatic urgent-job assignment, no policy editing, and no expansion to a second region in this pilot.
- **Failure behavior:** Stale eligibility, missing authority, unavailable dependencies, and ambiguous requests create a review item. They do not produce a guessed assignment.
- **Limits:** Agree a runtime limit, retry budget, cost per completed task, and maximum acceptable queue delay with the operator.
- **Acceptance owner:** Name one person who can accept the evidence or refuse the release.
- **Dependencies:** List access, test data, integration availability, and dates that affect delivery.

| Requirement ID | Given / when | Required observation | Evidence |
| --- | --- | --- | --- |
| ROUTE-01 | Valid request and current eligibility | Suggest only an eligible technician and cite the record version | Test result and resulting draft |
| AUTH-01 | Caller lacks region access | Return a denial with no restricted content and no write | Endpoint response and state check |
| REPLAY-01 | Same event delivered twice | At most one draft for that request and event version | Stored record count |
| REVIEW-01 | Worker attempts assignment directly | Endpoint rejects the action | Denied call and unchanged assignment |

An acceptance example should distinguish passing behavior from a plausible-looking failure. Review requirements and checks together when intent changes.

## 3. Workflow redesign record

**Decision:** Which steps still serve the outcome?

For each existing step, write: purpose, required control, supporting evidence, owner, proposed change, and verification. Use keep, change, or remove as recommendations, not automatic decisions.

Example: copying a technician ID between tools may be removable, while checking that technician's eligibility remains necessary. A consolidated lookup can reduce retyping only if it preserves current data, access restrictions, and exception handling. Do not remove a control because nobody in the first meeting knows why it exists. Assign that question to someone who can establish its purpose.

**Exit check:** The revised workflow preserves each required obligation and has a test for what changed. Measure the entire task, including review and correction effort.

## 4. Knowledge and procedure register

**Decision:** What may the workflow treat as authoritative?

Record source ID, title, version, effective date, owner, reviewer, approval status, review date, permitted readers, usage rights, and any superseded version. Keep the durable business record distinct from a search index that can be rebuilt.

Use one synthetic eligibility procedure with these parts: trigger, required evidence, full ordered steps, checks that cannot be skipped, permitted actions, stop conditions, escalation owner, and output schema. Maintain a short index telling the worker when that procedure is required.

Test four conditions: a superseded policy still ranks highly in search; the current source is unavailable; a reader loses access; and a search excerpt omits a required step. Preserve the rejection or escalation evidence. A good citation identifies the version actually used, not just the document title.

## 5. Worker operating contract

**Decision:** Can this task run beyond a single supervised session?

| Field | Fill in for your workflow |
| --- | --- |
| Owner and backup | Who can pause work and resolve failures? |
| Trigger and deduplication key | What starts a job, and what makes a repeated event the same job? |
| Persisted state | How are queued, running, awaiting-review, completed, and failed jobs represented? |
| Allowed tools and data | Which actions and records are authorized for this caller? |
| Review boundary | What concrete proposed operation does the reviewer inspect? |
| Limits | Runtime, retries, concurrency, tool calls, and spend |
| Recovery | How does the system determine what happened before interruption? |
| Escalation | Where does blocked work go, and who watches that queue? |
| Audit | Which event, policy version, decision, and resulting state can be reconstructed? |

Demonstrate a restart after saving a draft but before acknowledging the event. Recovery must inspect durable state. A prompt asking the model to avoid duplicates does not create an idempotency guarantee.

## 6. Evaluation and pilot decision

**Decision:** What evidence justifies exposing users to this version?

Begin with representative cases and expected outcomes reviewed by a domain peer. Separate development examples from held-out cases. Include common requests, ambiguity, urgent jobs, stale policy, denied access, duplicate delivery, and dependency failure. A small exercise set helps find mistakes; it does not estimate rare production failure rates reliably.

Record baseline result, candidate result, severity, resulting system state, latency, cost, and reviewer disagreement for every case. Compare versions on the same frozen inputs. Keep severe mistakes visible even when the overall average improves. If a model judges quality, compare its decisions with human judgments before relying on its score.

Before running the pilot, fill in: cohort, supported tasks, exclusions, baseline period, success measure, unacceptable failures, alert owner, rollback action, and review date. Agree the criteria before inspecting results. Launch decisions are expand, revise, pause, or stop; a demo is not a fifth option.

## 7. Prototype-to-release gap register

**Decision:** Which shortcuts prevent the demonstrated workflow from becoming a supported one?

| Requirement | Prototype shortcut | Consequence | Needed evidence | Owner / state |
| --- | --- | --- | --- | --- |
| Current eligibility | Hard-coded fixture | Ineligible recommendation | Version-aware integration test | Integration owner / open |
| Review authority | Disabled button only | Direct API bypass | Denied write at endpoint | Service owner / open |
| Recovery | In-memory job status | Duplicate or lost work | Restart and reconciliation drill | Service owner / open |

Track the prototype against the full approved specification. Keep requirements small enough to review and connect every closed gap to evidence. Build tests and permission checks alongside the feature; a later production review checks the assembled system rather than postponing all assurance until the end.

## 8. Handoff and support agreement

**Decision:** Can someone else operate and change the system?

Prepare three connected documents: an operational runbook for incidents and recovery; a system overview explaining boundaries and design decisions; and a maintained requirements tree showing expected behavior and acceptance evidence. This adapts Buehling's handoff structure (Chapter 13, printed pp. 77–81).

Witness the receiver deploy a known version, diagnose a seeded failure, roll back safely, and implement a small requirement change. Record the outcome, any coaching required, and corrections to the documents. A meeting attendance list is not completion evidence.

Write down the service owner and backup, access transfer, coverage hours, incident severity and response expectations, dependency maintenance, model or policy update reviews, change-request process, excluded work, unresolved risks, and support review or exit date. Decide who handles a defect and who authorizes a new capability. Set commercial terms for the actual responsibility; do not copy a book's percentage as a market rate.

## 9. Delivery evidence and reuse

Package the observed problem, your contribution, alternatives considered, requirements, evaluation failures, operating drill, and remaining limits. Keep synthetic outcomes separate from customer measurements. An honest unsuccessful pilot can demonstrate better judgment than an unsupported success story.

Identify one generic improvement worth proposing for reuse, such as an adapter contract or recovery check. Explain where it belongs, its owner, evidence of repeated need, maintenance cost, and removal of customer data and confidential rules. Reuse is a review decision, not permission to move a client's material into a shared library.

**Completion:** Another person can trace the problem to the specification, the specification to evidence, and the evidence to an explicit operating decision.