Build and defend the capstone

Time plan: 20 minutes planning, 70 minutes building, 50 minutes testing, 25 minutes review and 15 minutes reflection. Prerequisite: all earlier module artifacts.

What you will be able to do

Deliver a coherent supervised assistant and workflow package, demonstrate a policy change without breaking unchanged behaviour, show safe recovery and make a release recommendation supported by evidence.

The project

Use practice/capstone-pack.txt. Your client is the fictional Harbor Equipment Desk. It wants reviewable drafts for equipment requests and a reliable way to keep track of them. It has not authorised automatic replies, reservations, purchases, real-account connections or use of personal information.

Your design must preserve request identity, select the effective approved policy, avoid guessing missing values, route exceptions and stop at a human review boundary. It must also handle replays and an uncertain queue write. A production-looking diagram without these behaviours is incomplete.

Choose and declare your route at the start. Design and rehearsal uses the supplied files and manual trace logs. Live prototype uses an existing permitted assistant or ordinary chat plus the optional no-code lab, with a declared manual bridge between them. The bridge means a person validates and transfers the record; it is not an automated integration. You may document a fuller future integration, but do not claim you built or tested it.

The deliverable bundle

Produce these eight items with matching version identifiers:

1. Service contract: purpose, user, inputs, outputs, authority, exclusions, owner and stop conditions.
2. Assistant configuration: stable instructions, output contract, conversation starters and a change log.
3. Knowledge pack and manifest: active sources, versions, dates, owners, audience and a clear supersession rule.
4. Workflow map: trigger, field mapping, validation, routes, review queue, duplicate control and technical hold. Mark every manual step.
5. Working materials: the configured synthetic prototype where available, or a complete rehearsal record. Include the route table and duplicate ledger.
6. Test evidence: all required cases, expected and actual results, original outputs or traces, failures, corrections and evidence labels.
7. Review and operating guide: reviewer state, stale-approval rule, recovery process, owner, monitoring, quota and retention decisions.
8. Release recommendation: what is proven, what remains untested, what must change before a real pilot and a self-score with mandatory gates.

The files should form one package. A source version written in the test log must exist in the manifest. A route mentioned in the workflow map must appear in the route table. A manual review step must have an owner and a clear queue record. Cross-file consistency is part of the assessment.

Run A

Before testing, read the ten required cases and write expected outcomes without opening the solutions. Use Pack A dated 14 October. Process in the given order so that the replay case has a previous result to find.

Inspect A1's projector boundary, A2's above-limit duration, A3's missing value, A4's guest status and A5's October webcam boundary. A6 tests duplicate handling. A7 tests the authority boundary against untrusted instructions. A8 tests the uncertain write outcome. A9 tests a fractional duration. A10 tests an equipment-damage exception without diagnosing or repairing equipment.

For each, record what happened at the assistant, validation, routing, queue and review steps. If the assistant gives a wrong response but the validator blocks it, record both the model failure and the successful containment. Do not replace the original answer with the corrected version and call the first attempt correct.

Run B

Move to 2 November and activate Pack B through your documented change process. Use new request IDs C301, C302 and C303. A five-day webcam now requires human review; a three-day webcam remains within the standard limit; a two-day projector is unchanged. The source references should change to P2 where applicable.

Then introduce C304's unresolved approved-source conflict in a separate test copy. The workflow must not invent which policy wins. Restore the verified manifest after the test and record that restoration. Retest at least one ordinary case to confirm the conflict test did not contaminate the active pack.

Do not reset a real duplicate ledger simply to make a replay pass. A deliberately isolated test environment may have a clean ledger, but its scope and starting state must be stated. History is part of the experiment.

A compact worked handoff

An acceptable handoff note could say: “Configuration 1.2 and workflow design 1.1 prepare synthetic draft records only. All 14 core cases plus a post-restoration regression execution were manually rehearsed; three routing cases were also observed in the no-code prototype. No live AI-to-workflow connection was built. The policy update changed the webcam route while preserving the projector route. The unknown-write case was simulated and reconciled to one queue record. A real pilot is blocked until destination uniqueness, authenticated approvals and access controls are tested.”

This note is illustrative, not a claim about your own work. Replace each statement with your evidence. A shorter honest prototype is stronger than an unverified claim of full automation.

Rubric

Score the following categories out of 100:

• Scope and authority, 10: bounded job, clear owner, no implied action permission.
• Reusable configuration, 15: coherent process, stable output contract, meaningful tests.
• Knowledge governance, 15: effective approved sources, source references, change and conflict handling.
• Data and routing, 20: correct field mapping, missing/invalid distinction, complete routes and explicit manual steps.
• Review and recovery, 15: pending review, stale-approval protection, replay handling and uncertain-write reconciliation.
• Test evidence, 15: all required cases, honest evidence labels, original failures and retests.
• Operating handoff, 10: monitoring, cost/quota, retention, limitations and justified release decision.

For each category, full marks require complete, consistent evidence; about half marks indicates a sound idea with missing or untested pieces; zero means absent, contradictory or materially unsafe. The solutions book provides category-specific anchors. Proposed pass threshold: at least 80 out of 100 plus every mandatory gate below.

Mandatory gates

G1 Privacy: all practice is synthetic and no unnecessary personal information or credentials were collected or transmitted.

G2 Authority: no sending, reservation, approval of a loan or permission change occurred or is falsely claimed. Any training approval is tied to the exact draft and next step.

G3 Evidence: no invented execution results; observed, rehearsed, simulated and expected-only evidence are distinguishable.

G4 Correctness: the changed webcam limit, missing/fractional duration, guest, bypass attempt and source conflict are handled safely in the final tested design.

G5 Recovery: replay produces no second intended queue effect, unknown write is reconciled or held, and no blind retry is presented as safe.

G6 Completeness: both source snapshots, all 14 core cases and at least one post-restoration regression execution are included. Any failed gate means revise and retest regardless of the numeric score.

Defend your design

Answer these questions in a short reflection: Which step gains the most from AI? Which step would you keep deterministic? What failure did your first version miss? Where can a person intervene? What evidence would you need before replacing the manual bridge? Which vendor-dependent feature is most likely to require a future recheck?

Keep the final bundle, score and release recommendation. Completion demonstrates a supervised design and the specific tests you performed. It does not certify an unattended production system or guarantee a model's future behaviour.