Provenance and receipts

Every invocation leaves a trail of signed objects. A provenance bundle collects them into one portable file that anyone can verify without trusting you, BNW, or the node that exported it:

bnw invoke provenance <INVOCATION_ID>          # writes <id>.provenance.json and prints the report
bnw invoke verify <BUNDLE.json>                # checks a bundle offline; exits with an error if invalid

• What a bundle holds. The bundle (bnw.provenance-bundle/1) holds the canonical signed bytes of:
  • the invocation, the capability manifest and its descriptor, and the offer and its price terms;
  • the encrypted input and output manifests (never their ciphertext or plaintext);
  • the progress chain, any cancellation, and the result;
  • the grants that authorized the result, and any revocations of them the exporter holds;
  • inference execution claims, the requester’s receipts, the operator’s approval behind an agent’s tool call, credit records including settlements and their witness attestations, and both participants’ profiles.
• How verification works. It loads every object into an empty temporary store, which checks sizes, hashes, and signatures as for network input. Then it checks each link:
  • the requester signed the invocation, against a matching offer that was valid at the time;
  • the input is sealed for the provider, and the output for the requester;
  • the progress chain is unbroken;
  • the provider signed the result;
  • its grant was issued by the provider, named the requester and this capability, and was valid and not revoked when the result was signed;
  • the requester signed each receipt, and each one cites the invocation’s result and an outcome that fits it.
• The verdict. It is verified, incomplete (evidence is missing but nothing contradicts the rest), or invalid.
• What it does not prove. That the output is correct, that a model ran as the provider claims (execution claims are the provider’s own report), that the requester’s receipt is fair (it is the requester’s own report), or that no revocation exists beyond those in the bundle. Timestamps are each author’s own.

Receipts

The requester’s node signs a receipt for every invocation it makes, in addition to the provider’s result. Receipts go only to the requester and the provider, and appear in provenance bundles.

• When one is signed. When the result arrives, the receipt records the outcome and how long the requester waited. When an invocation expires unanswered, it records no-response.

• Your own verdict:

  bnw invoke rate <INVOCATION_ID> --rating 4                  # 1 (worst) to 5 (best)
  bnw invoke rate <INVOCATION_ID> --outcome unusable          # completed, but not usable
  bnw invoke rate <INVOCATION_ID> --settlement <SETTLEMENT>   # cite a witnessed settlement
  bnw invoke status <INVOCATION_ID>                           # shows the current receipt

• Superseding. Each rating signs a new receipt that replaces the last one. A receipt is the requester’s statement, not proof.

• Publishing. Receipts stay with you and the provider unless you mark them public. Then anyone may publish them, together with the invocation (but never its input or output), to everyone who follows the capability:

  bnw receipts public on                            # your new receipts are public from now on
  bnw invoke rate <INVOCATION_ID> --public          # or one at a time (--private to withdraw)
  bnw receipts publishing <CAPABILITY_ID> on        # as a provider: publish requesters' public receipts
  bnw receipts publish <CAPABILITY_ID> [--provider <ID>]   # publish now, as provider or as requester
  bnw receipts summary <CAPABILITY_ID>              # what published receipts say, per provider

  • A provider can choose not to publish a bad receipt, but it cannot forge one, and the requester can publish its own.
  • Summaries count requesters’ statements without weighting them. Reputation weighted by who you trust is later work; see ROADMAP.md.
  • A published entry includes the provider’s signed result only when the result carries no free-text details.

• In the web client and the app.

  • Web client:
    • the invocation page has a Receipt card with a star rating, Usable / Not usable, and a share checkbox;
    • the dashboard sets whether new receipts are shared;
    • a capability’s Providers table shows each provider’s track record once you follow it;
    • your own capabilities have a publishing switch and Publish now.
  • iPhone app: rate an answer right after it arrives, see a followed service’s track record, and switch sharing in You. The phone rates only invocations it made itself.

The web client’s invocation page has a Provenance card that checks the evidence and downloads the bundle. The local API offers invocation-provenance. bnw mcp serve has a read-only get_provenance tool, so an assistant can confirm who answered it and under which grant.