Follow a receipt graph

What you'll do

Trace a synthetic qualification backward through its local receipt graph. Identify input, output and upstream bindings, then explain what hashing and signatures establish. Use only approved local or synthetic artifacts. A receipt graph can contain private values and is not a public sharing format.

Follow dependencies, not reassuring labels

A receipt is a create-only ledger record binding a producer result to declared inputs, outputs and upstream evidence. The graph makes those dependencies navigable. Start with the selected gate subject and ask which observations support each required check. Then follow the exact receipts and retained artifacts it references.

A label such as Sales qualified is too broad by itself. Read the entry boundary, declared scenarios, asset context, observation time and supporting selection. A Gold-entry qualification does not prove an unobserved source-to-Gold path. Do not expand its claim merely because downstream nodes appear connected.

Reconstruct one chain

In a synthetic example, a report query result depends on a semantic definition and a named filter state. That semantic evidence depends on the selected Gold observation. Follow those references rather than choosing an unrelated successful query from another run.

Selected gate subject
  -> declared report query receipt
     -> retained query actual and report/model state
     -> selected semantic evidence
        -> selected Gold evidence

This is a teaching sketch, not a promise that every project uses an identical graph shape. The project and selected qualification scope determine which edges and checks are required. Record any unproved upstream boundary explicitly.

Verify retained bytes and trust

A digest can reveal that retained bytes changed. It does not establish that the original business rule was appropriate. An Ed25519 signature authenticates a particular claim under supplied public trust. It does not prove source truth, financial accuracy or human acceptance.

For an installed project using the current signed verification route, the brief documents:

❯node .agent-skills/data/ledger/spine.mjs verify --project <project> --evidence --strict --require-signatures --trust-store <public-trust-file>

Use independently selected public trust and the actual retained project. Carry the original context for a scoped run. This is not key creation or a network upload. Missing bindings, changed files and invalid or untrusted signatures are stop conditions, not invitations to recreate history.

Record the graph's limits

A graph can faithfully describe an incomplete proof. Check evidence completeness, signatures and freshness separately. Historical unsigned receipts do not become signed because the current runtime supports signatures. A selected signed subject needs the supporting chain required by that route.

For your exercise, mark each edge verified, absent, changed or outside scope using the actual findings. Recommend the owning observation that would close a gap. Do not suggest "run everything again" when only one dependency needs a fresh observation, and do not omit a downstream requalification that depends on that changed observation.

Your expected output is a short trace with the exact scope and open boundary. Share only a synthetic summary with the academy. Keep raw receipts, hashes tied to private identities and supporting business artifacts in approved customer-controlled custody. Hosted receives a separate value-free attestation, not this local graph.

Check your understanding

1. What does a matching digest establish, and what does it leave unproved?
2. Why must a scoped run retain its original context during verification?
3. What is the correct response when a historical evidence file has changed?