Separate proof artifacts

What you'll do

Distinguish a private local receipt, a signed value-free attestation and Hosted's separately signed acknowledgement. Rehearse a handoff using synthetic metadata. This is a reading and planning lab; no signing key creation, network push or real client disclosure is required.

Keep the three claims separate

A local receipt binds an observed producer result to evidence and dependencies. It may contain private values. An attestation is a closed signed projection of a selected local qualification claim. An ACK records Hosted's acceptance of that bound envelope under its own authority.

The exporter verifies the selected signed subject and supporting chain before projection. Hosted verifies the received claim's provenance, integrity, scope and freshness. Numerical comparison remains local against independent expectations. Do not call the ACK a second numerical audit.

Verify the exact selected subject

The brief's current workflow requires the retained project, exact signed gate subject, signed supporting receipts and independently selected public trust. Scoped runs carry their original context through verification and export. A program summary is not a substitute for the selected gate subject.

The installed route includes this signature check:

❯node .agent-skills/data/ledger/spine.mjs verify-signature --project <project> --gate <run> --subject <project-relative-gate-results> --trust-store <public-trust-file>

Add the original context selector for a scoped run as documented in the installed guide. This command does not create private custody or authorise sharing. Missing evidence, changed bytes, an unknown or revoked signer and an invalid signature remain stop conditions.

Review the projection and freshness

The attestation excludes actual and expected values, group labels, SQL/DAX, private paths, raw identities and business artifacts. Domain-separated keyed commitments preserve bounded bindings without publishing those private values. The disclosure key is separate from the signing key.

Expiry can be no more than 24 hours after observation. Exporting an old observation does not start a fresh 24-hour window. If the evidence is too old, obtain new observations through the owning workflow instead of editing dates. A valid failing gate can export a truthful failure attestation; signing does not turn failure into success.

Handoff questions:
Did the local gate establish the declared checks?
Does trusted signing authenticate this exact projection?
Has Hosted acknowledged this exact envelope?

These questions have separate answers. You can prepare and independently verify a local export while leaving the Hosted action explicitly unperformed.

Prepare a bounded handoff

After a permitted export, the brief documents independent attestation verification:

❯node .agent-skills/data/ledger/spine.mjs verify-attestation --attestation <new-attestation-file> --trust-store <public-trust-file>

Record scope, observation, expiry, verification and any evidence-completeness limitation. Keep raw receipts, renders and oracle files local. Never type a private key, passphrase or token into the worksheet or chat.

Hosted is a protected preview. An actual push requires explicit local consent, exact Hosted approvals, current device/producer authority and pinned ACK trust. Lost-response recovery must preserve the original acknowledgement bytes rather than invent another success. Your expected output is a synthetic handoff that clearly distinguishes verified, pending and unperformed actions. None of these artifacts supplies human business acceptance or an automatically issued certification.

Check your understanding

1. Which proof artifact can contain raw business values?
2. Why does an ACK not mean Hosted recalculated the source totals?
3. Why must attestation expiry be anchored to observation rather than export time?