Handoff
From Scattered Information to a Reviewed Handoff

The simulated client is a B2B implementation consultancy. Its request is simple to state: "Sales hands us a kickoff form, email excerpts, and account notes. They don't always agree. We need to see what's missing, decide whether we can schedule kickoff, and create a handoff without retyping everything. We also need to know why a request was marked ready."

The hard part is not extraction. It is deciding what counts as confirmed when sources disagree, and keeping that uncertainty visible until a person resolves it.

These are starting hypotheses to test in discovery, not a completed specification:

The first experience stays small: a queue, a review workspace, and handoff history, with keyboard support and clear loading, empty, validation, and failure states.

The review challenge: which date is confirmed? What is the agreed initial scope? Is Jordan a scheduling contact or a technical owner? The workspace has to preserve that uncertainty until it is resolved.

The learning goal is to own a feature from an unclear request through verified delivery. AI may generate substantial implementation code. I own the decisions, the review, the debugging, and the evidence.

• •Define "ready," the person who decides, and the questions that block handoff
• •Choose how conflicting sources are handled and when a reviewer must intervene
• •Decide where state, validation, authorization, and persistence belong
• •Explain how source changes affect suggestions and existing approvals
• •Define proof of delivery and retry behavior that avoids duplicate projects
• •Choose the smallest useful release and justify AI against a manual baseline

AI shows up twice. During development, I delegate bounded changes with observable acceptance criteria, inspect the relevant changes, and investigate unexpected behavior. Inside the product, model suggestions stay separate from confirmed values, and a reviewer decides readiness and approves delivery.

Acceptance thresholds are chosen before measuring. The plan starts with about 30 synthetic cases: 20 for development and 10 held out for an evaluation checkpoint, including complete packets, missing fields, conflicting sources, later edits, and irrelevant instructions embedded in source text. Expected answers stay out of model inputs.

• •Extraction and grounding: compare fields with explicit expectations, count unsupported claims, and verify that cited passages support the suggestions
• •Uncertainty: detect missing information and conflicts without treating guesses or customer requests as confirmed facts
• •Workflow correctness: edits persist, approval covers the reviewed version, relevant later edits require renewed approval, and unapproved handoffs are not sent
• •Integration reliability: failures are visible and understandable, and a repeated delivery or retry does not create a duplicate downstream project
• •Reviewer effort: compare time and corrections needed for a correct decision in manual and assisted practice sessions
• •Operation: record observed latency and estimated model cost for the tested cases, with the model and configuration used

A defensible release decision means showing the complete path from source packet to reviewed, approved, delivered handoff, demonstrating one delivery failure and a successful recovery without duplication, and explaining a model failure, its consequences, and the chosen correction or limitation. Narrowing or removing an unhelpful AI feature is a valid outcome.

The first version covers one workflow, one reviewer persona, text and JSON inputs, and one integration. It defers OCR, inbox sync, CRM sync, billing, multi-organization administration, real signatures, and autonomous approval, and adds an agent framework only if a demonstrated need warrants it.

Claims stay proportional to the evidence. Results will be reported with their denominators and limitations. A small synthetic set does not establish production accuracy or customer savings, and solo timings are practice results.