Download the complete part-09 practice pack (ZIP). Extract it and preserve its folders. All organizations, records, and results in this teaching pack are fictional.
These templates connect a business task to its sources, authority, execution, and recovery. Complete them for the actual system before adapting the local teaching example. Blank fields mean the necessary evidence or decision is not supplied.
One-page workflow definition
| Field | Entry to complete |
|---|---|
| Business job | One output and its intended use |
| Trigger | What begins the work and how its origin is established |
| Operation identity | How repeated delivery of the same intent is recognized |
| Input contract | Required fields, allowed values, and unsupported cases |
| Source authority | System, document owner, version, and permitted access |
| Model's role | The language or judgment task it proposes; exact rules handled elsewhere |
| Output contract | Required content, references, unknowns, and status |
| Permitted action | Exact operation, affected records, destination, and limits |
| Approval | Who reviews what and how changes invalidate the decision |
| Completion evidence | Result that establishes the action actually occurred |
| Failure route | Named reason, accountable owner, and next step |
| Fallback | How a person continues under the same business rules |
| Review date | When the owner assesses quality, effort, cost, and incidents |
A staged draft and a delivered message need different completion evidence. Do not combine them under one “done” state.
Permission and approval record
Verified actor and business scope:
Permitted action and affected record IDs:
Source versions and current record version:
Exact proposed content, amount, or other material arguments:
Destination and limits:
Proposal fingerprint:
Reviewer identity and authority:
Approval time, expiry, and revocation status:
Executor identity and current access:
Execution preconditions:
Operation ID and eventual result reference:
A fingerprint detects content mismatch when the underlying record and checks are trusted. It is not an identity signature, encryption, or proof of approval. Obtain identity and authority outside model-generated arguments.
Tool inventory
For each actual integration, record the provider, maintained version, supported protocol revision, function, read/write scope, input/output contracts, credentials mechanism, permission enforcement, and owner. Add its timeout, pagination, retry, duplicate, cancellation, and result-lookup behavior where relevant.
The practice pack implements ordinary Python functions. Names proposed in the manuscripts are design examples, not connected tools. Do not describe the pack as an MCP server or provider integration.
Context and memory map
| Record kind | Questions to answer |
|---|---|
| Working context | What is necessary for this step? What can be omitted? |
| Reference knowledge | Which version is authoritative and who maintains it? |
| Business state | Which system confirms the actual event or decision? |
| Model note or proposal | How is its tentative status preserved? |
| Retained preference | What explicit evidence establishes its scope and purpose? |
Record entity, permitted roles or relationships, source ID, version, status, purpose, and appropriate review or retention rules. Apply access before exposing content. A relevant search match is not evidence of permission, currency, or truth.
For any proposed memory write, show old value, new value, evidence, affected scope, and review requirements. Keep confirmed actions separate from requests and proposals. The supplied demonstration has no memory-write endpoint.
Recovery worksheet
Operation ID and intended action:
Attempt IDs and relevant times:
Known committed effects:
Evidence supporting that status:
Uncertain effects:
Provider lookup or reconciliation method:
Duplicate-prevention mechanism and retention limits:
Current approval and record state:
Containment or pause:
Manual fallback and owner:
Proposed recovery action and required authority:
Actual resolution and evidence, when available:
A timeout does not establish that no action happened. Investigate the existing result before repeating a side effect. Local rollback does not reverse an external action. A correction or compensating transaction is itself a new action requiring valid scope and authority.
Operating scorecard
Track eligible cases, accepted outputs, first-review acceptance, corrections, unresolved exceptions, queue age, and full effort. Include model/tool cost and source maintenance where applicable. State the denominator and period for each rate.
Keep rejected unauthorized requests separate from outages. Keep unique operations separate from attempts. Keep successful tool calls separate from customer outcomes. Do not present fixture pass counts as a measured production reliability percentage.
Proposed-change review
Identify what changed: model, prompt, source, access, tool, schema, or workflow. Select cases that address that change and the concrete remaining risks. Preserve the earlier baseline and explain differences in results.
Record what was tested locally, what needs provider or model evaluation, and what has not been exercised. Identify the person who can accept the change and the scope of that decision. Do not turn a local test result into deployment authorization.
Practice sequence
Read practice/README.md and inspect request.json alongside mesa-sources/SERVICE-01.md. Predict the draft and explain why Friday remains unconfirmed.
Run python3 practice/run_demo.py from Part 9. Inspect the exact preview and zero action counts. Then run python3 practice/verify_examples.py to exercise the simulated approvals and failures. Compare each named result with the behavior described in chapters 32, 33, and 36.
Read documents.json and memory-records.json. Explain why the current policy and reviewed request note are available while superseded, private, other-entity, and model-proposal records are not exposed by the permitted retrieval methods.
Inspect the separate model-evaluation-plan.csv. Its observed outputs and results remain blank because no language model was evaluated. The injection fixture verifies a deterministic permission boundary; it does not prove model-level resistance.
Finish by writing a proposed real-system boundary map. Identify the added identity system, storage, model, connector, or outbound action and what each addition would require. The demonstration's fixed actor registry, test clock, in-memory pause, and local fixtures should not be mistaken for production controls.