Part 2 · Deep Reference
The Written Record
Record structure, a complete run-note template and truthful receipts.
Public teaching edition · 1 October 2026
The record structure
These are reusable file roles, not a requirement to clone a private repository. Use your existing record system and enforce its access boundary.
| File or record role | Contents |
|---|---|
| Start here | Purpose, read order, owners, boundaries and how to begin |
| Agent instructions | Current adopted operating rules and references |
| Coordination | Which surface carries each kind of work |
| Definition of done | Acceptance evidence and verification wording |
| Failure modes | Observable tells, checks and actual enforcement limits |
| Model routing | Task-based worker choice, budgets and fallback constraints |
| Job packet | Current ask, ownership, decisions, checkpoints and next click |
| Queue views | Claimed, open, waiting, review and complete views of the same task IDs |
| Agent notes | Restricted run records and lessons for the next worker |
| Schedule record | Prompt revision, cadence, dependencies, stop condition and receipts |
| Canonical index | Concept, source revision, public destination and derived views |
| Learning inbox | Proposed improvements with evidence and disposition |
| Access manifest | Approved routes and owners, without secret values |
Restrict client-specific records to their authorized audience. Generate summary views where practical instead of maintaining separate status facts by hand. A role or visibility field is only metadata until actual permissions enforce it.
A complete run note template
Use one run note per substantive execution. It can link to the packet rather than duplicate every checkpoint. Preserve the private record; prepare a separate audience-safe lesson if publication is useful.
Title: <short description of the job>
Date: <actual date>
Worker: <platform and model if known; UNKNOWN if not>
Runtime: <where the tools ran>
Task: <canonical task ID and revision>
Outcome: <shipped, partial or blocked>
What I was asked
<Exact request or authorized reference>
What I found
<Facts, source revisions, unknowns and contradictions>
What I changed
<Artifact, revision, destination and verification>
Collaboration review
<Reviewer, artifact opened, finding, evidence and disposition>
What I got wrong
<Corrections, or nothing surfaced; never omit the section>
Conflicting documentation
<Which source said what, and the supported resolution>
Blocked on
<Exact missing access, authority or evidence; owner and recheck>
Next action
<One bounded next click and accountable owner>
Verified
<What was opened, what was observed, when; or NO and the gap>
Write the note while evidence is fresh. Do not save passwords, tokens, unnecessary personal data or an unsupported human-review claim. Keep references accessible to the people who need them. Correct a mistaken record visibly; do not replace its history with a cleaner invented one.
Writing for a human
Lead with the result, decision or blocker in plain words. Put the consequential facts before technical detail. Give the reader enough context to understand the update without reconstructing internal threads.
Name what changed, where it can be opened, what remains uncertain and who owns the next step. If a decision is required, make the question bounded and include the useful options and evidence. Do not invent promises, sentiment or human approval.
A concise summary can link to a detailed receipt. It should not conceal a failed check or turn a partial result into completion. Match the agreed channel and audience; an internal audit note and a client update have different information boundaries.
Identity receipts
An internal identity receipt connects the action to the worker, evidence and correction path. Use the actual platform and model if known; otherwise write UNKNOWN. Record the exact action and truthful human-review state.
Template for internal QA surfaces:
Agent receipt: <platform and worker> [model if known]
action: <drafted, sent, posted, published or changed>
human review: <reviewed by named owner,
authorized but not separately reviewed,
or no human review recorded>
The source method keeps this operational receipt on internal notes and QA surfaces, rather than appending it to ordinary client or partner messages. Follow any applicable disclosure requirement and the agreed communication format. Do not falsely claim human authorship or review.
The receipt grants no permission and proves no quality by itself. Detailed traces can contain private prompts, client facts and recipients; keep them access-controlled. Share only audience-appropriate evidence.