A public, entirely synthetic working example for F02 meaning handoff and F06 package acceptance. Two input formats, four editorial answer fixtures, one separate wrong answer and four local probe groups make the process reproducible. No customer data or language model calls are involved.
Run
Extract the entire ZIP. Use Python 3.10 or later and its standard library; no extra packages, account or network access are needed. Run from the extracted folder:
python -B run_demo.py --check
A successful run prints PASS and the path work/run_<identifier>/report.json. Every run creates a new subfolder and preserves the input files. work/run_<identifier>/comparison.md is the readable comparison; comparison.json records field checks and evidence. prompts/ contains four complete input templates. F06 raw reports and altered copies are under f06/, with relative paths in the main report.
PASS means that observed local checks match expected.json. Expected failures for changed or missing files are part of a successful demonstration.
The case
Fictional document doc-synth-17, revision 2, is technically complete. Its named fictional reviewer approves external distribution at 09:00. This approval applies to the first case at 09:05. At 10:00 the same reviewer explicitly withdraws approval: hold revision 2 until renewed approval. The intended response to the second case at 10:05 is therefore hold. All times are invented. The program distributes and approves nothing.
The correction becomes a concrete handoff object: payload/instruction.json contains action: hold, external_distribution_allowed: false, and active event E2. The run checks these three fields against the correct F02 correction fixture. This instruction, a fictional text file and a review note form the F06 payload.
F02: prepare and inspect a comparison
The glossary and structured handoff contain the same six ordered facts, with identical IDs and text. Two cases supply identical events and questions to both conditions. The code checks the matching facts and generates complete input templates for each format.
The answer fixtures were written editorially and are deliberately identical within each case. The separate rubric defines expected action, distribution permission, active event, clarification and evidence IDs. The program compares those structured fields. Explanatory prose remains visible for human inspection and is not automatically evaluated for meaning.
All four good fixtures should match the rubric. A separate deliberately wrong answer ignores the withdrawal; it must be detected as a mismatch and is not counted as an output of either condition. This predetermined tie is not an empirical null result or a transfer measurement. The example does not execute the offered F02 pilot with twelve variants and 24 real recipient outputs.
For a later real comparison, the templates can be used in separate fresh contexts. Both conditions need the same factual information; record the environment, configuration, inputs and unchanged actual outputs. Free-form answers require subject-matter review. The download performs none of those model or customer steps.
F06: four local probe groups
| Group | Change in a separate copy | Expected observation |
|---|---|---|
| P1 | Unchanged payload against supplied reference | PASS |
| P2a | Replace exactly one "hold" with equally long "send" in instruction.json |
FAIL, digest mismatch |
| P2b | Remove instruction.json in a separate copy |
FAIL, missing file |
| P3 | Regenerate both changed file and manifest | PASS against new reference, FAIL against old reference; visible reference change |
| P4 | Cross-check a synthetic signature record against the existing policy | CROSSCHECK_ONLY, cryptographic_operations_performed: false |
P2 contains two distinct subcases. P3 retains the old reference and does not overwrite an original approval. The injected send action still deliberately contradicts the corrected instruction after a new manifest is created. The new PASS assesses matching file references, not substantive correctness. P4 uses a separate synthetic metadata record with a subject file; it signs neither that file nor the handoff package.
Eight existing ACT modules are included unchanged. This sample adds the missing EXIT_CHANGED import to manifest.py so that file or tree changes detected during manifest creation raise the intended verification error. The original hash and this single import fix are documented separately in the provenance record. The new demonstration driver creates copies and records results. The supplied manifest covers the three payload files; source_manifest.json additionally inventories package-file checksums. Both references travel in the same download and are not independent trust anchors. A byte check here demonstrates agreement with the chosen reference, not authenticated origin or authorization. The policy cross-check performs no cryptographic signature verification. PASS values for identity, revocation or role in the raw report only mean that synthetic metadata satisfies those rules; they do not confirm real identity, revocation status or authority. HTTP, JWS and an agent runtime are outside this example.
Provenance and use
source_provenance.json lists relative original source locations and hashes of included modules. Case text, fixtures, input templates and demonstration drivers were newly created for this example, with AI assistance and local verification. No private raw conversations or third-party model outputs are included. Publishing this working sample grants no new software license or broader rights in the full collection; existing source notices remain applicable. Local reproduction is the purpose of the package.