A fictional team ingests data, builds a model, reviews it, approves it and publishes a report. Toggle the selected events and inspect the missing prerequisites.
The log and times are synthetic. Rules test event presence and a chosen role, not event chronology, real identities, reviewer independence or an external execution.
How the example works and where it came from
The event display always follows the same illustrative order. The scenario identifier is a simple non-cryptographic label; it is not a tamper-proof receipt. Sharing preserves selected events, role and seed in the URL fragment. No events are sent to a workflow system.
Adapted from Governance Trio at source revision 9d9c253, reviewed 2 October 2026. The original idea of generating replay records, rule receipts and lineage from real workflow evidence remains a future integration proposal.
What would a real assurance record need?
The earlier Assurance Bundle sketch proposed three linked records. This example illustrates their questions; it does not collect evidence from a real workflow.
Replay record: captured inputs, configuration and software/environment versions; stored external responses or nondeterministic choices; original and replay output hashes. Matching bytes test reproduction, not whether the result was right.
Rule receipt: rule ID and version, evaluation context, pass/fail/not-applicable result, rationale, time and the responsible policy. A tick cannot show that an untested rule was satisfied.
Lineage: run, step and attempt IDs, actor and approval references, input/output artefact references and typed links. Each event needs its own ID, type, timestamp and payload. An approval reference must lead to evidence; it is not created by drawing an arrow.
Keep failures and retries alongside successful attempts. A real variant comparison would count paths from an actual event log and state its population and time window. The old mock-up’s percentages and success claims were placeholders, so they are not carried forward as results.
These are design considerations recovered from an earlier sketch, not a delivery plan or implemented controls.
Scenario: Workflow Events
Rulebook (human‑readable)
pass
fail
v0.1 demo
R1 — Two‑person review: Approval needs both named reviews; their independence is assumed.
R2 — Traceable output: Publication needs both ingest and build in this scenario.
R3 — Approval prerequisite: Approval requires a selected build. Chronology is not checked.
R4 — Authority scope: Only selected roles {Lead, QA} may approve.
R5 — Upstream prerequisites: A build needs ingest; a review needs a build.
Scenario Log (deterministic log)
Deterministic seed:—
Rule Receipts (machine‑checkable)
Rule
Status
Explanation
Lineage Map (who/what produced what)
Selected relationships
Relationships and missing prerequisites
What survives a project handover?
A fictional refuge team hands over a concept record, two declared reviews and two evidence files. Check whether the package is complete enough for this toy rule and whether its evidence still matches the recorded bytes. Then break one thing at a time.
These checks concern a package, not acceptance of the refuge. The reviewers, site and documents are invented. No engineering assessment was performed. Signatures, identity and real provenance are unverified.
1 · RecordAre the fields usable?
2 · Declared policyDo the stated roles and names meet the toy rule?
3 · Evidence bytesDo current files match declared hashes?
4 · AcceptanceStill unknown: truth, authority and engineering.
Editing text changes its UTF-8 bytes. The declared hashes stay fixed, so an edit invalidates the previous result. Inputs stay in this page; they are not added to the workflow sharing link. Reloading, restoring or choosing another example discards your edits. Download current inputs first if you want to keep them.
Check receipts
Loading the fictional package…
Inspect the record, flat digest map and toy policy
The structure check asks whether fields are usable. The policy separately asks for two distinct declared signer names in the two required roles. Neither authenticates those people. A hash compares exact bytes against a declared baseline; the person who changes a file can also replace its digest.
Take the package away and check it again
Download and unzip the sample pack. With Node 22 or later, run node check.cjs inside its folder. It reads the current files and recomputes their hashes on every run. No package installation is needed. The included schema, policy, checker and workflow example explain the boundary.
To check your edited browser inputs, save the JSON alongside the unpacked checker and run node check.cjs handover-inputs.json. The download contains inputs, not a trusted receipt. Hashing unavailable in this browser can still work locally.
If your browser blocks the download, select the JSON below, copy it and paste it into a plain-text editor. Save it as handover-inputs.json using UTF-8, then check it with the unpacked checker as described above. This text is the same input snapshot requested for download; it contains no claimed result.
Further edits, restoring or changing examples remove this snapshot and save link. Request a new export after making changes. Reloading also clears them.
Source and corrected failure modes
Adapted from the mountain-refuge handover prototype, historical repository lawrencerowland/more-project-apps, revision f7f084a. Its useful idea was to join responsibility, review declarations and evidence in a stage handover. The maintained provenance receipt records its source and corrections.
The original pipeline could hide a failed policy command, reuse stale results, and look for digests at the wrong level. Its purported PDF was text, its scan had no assessment, and its separate attestation check did not bind the package to a trusted project. This exercise uses explicit results and fresh byte checks, replaces those artifacts with clearly unassessed examples, and claims no verified attestation.