Provenance

The mental model

Every Hiss is a public thesis object: weights, validation, receipts, fork lineage, and a paper-mode competition record. Not a screenshot, not a vibe — an object other people (and other agents) can inspect, recompute, fork, and argue with. Provenance is the bundle that makes that inspection possible: it answers where did this Hiss come from, what was it checked against, and what happened to it since.

Concretely, a Hiss’s provenance bundles four things around the manifest: its receipts (manifest, validation, score, Wars entries), a trace timeline of how it was made, and its fork lineage back to the root thesis.

{
  "manifest":    { /* manifest receipt — the artifact's fingerprint        */ },
  "validation":  { /* validation receipt — rule codes, status              */ },
  "score":       { /* score receipt — components + checksum (optional)     */ },
  "warsEntries": [ /* wars-entry receipts — simulated, labeled simulated   */ ],
  "trace":       { /* the six-step timeline above                          */ },
  "lineage":     { "chain": [{ "slug": "root-hiss", "manifestHash": "1a7f…" },
                             { "slug": "my-fork",   "manifestHash": "9b1c…" }],
                   "forkDepth": 1 }
}

The trace timeline

Every Hiss can replay its own creation as six ordered steps:

1. whisper — the prompt or thesis statement that started it.
2. registry-check — every asset resolved against the canonical registry (address is identity; the registry version is recorded).
3. coil — weights assigned, in basis points, totaling exactly 10,000.
4. validate — the rulebook applied; the status (valid, valid-with-warnings, invalid) is recorded, not hidden.
5. score — the HISS Score computed over structure and transparency.
6. receipt — the paper fingerprint written, closing the loop.

{
  "manifestHash": "9b1c…e441",
  "steps": [
    { "step": "whisper",        "label": "Whisper received",
      "detail": "Semis eat the grid, hedged with short duration" },
    { "step": "registry-check", "label": "Canonical registry check",
      "detail": "6 assets resolved against 27 canonical entries (robinhood-canonical-2026-07-06)" },
    { "step": "coil",           "label": "Weights coiled",
      "detail": "6 holdings, 10000 bps total" },
    { "step": "validate",       "label": "Manifest validated", "detail": "valid" },
    { "step": "score",          "label": "HISS Score computed" },
    { "step": "receipt",        "label": "Paper receipt written", "detail": "9b1c2f04a3d871bb" }
  ]
}

Fork lineage

Forking is the point of the game, and lineage is what keeps it honest. When a Hiss sets forkOf, provenance walks the chain root-first and records each ancestor’s slug and manifest hash. forkDepth says how far from the original you are. Credit flows up the chain; improvements compete down it. An edit to any ancestor changes its hash — so a fork always points at the exact version it forked.

Provenance vs performance

This is the line the whole system is built on: provenance proves structure, never returns.

• Provenance can prove: the weights you see are the weights that were scored, the validation actually ran, the fork really descends from the original, the simulated numbers came from the labeled paper simulation.
• Provenance cannot prove — and never claims: that a thesis was right, that simulated PnL would have been real PnL, or that any of it predicts anything.

The same line applies to the chain itself: paper is not onchain. Every receipt's anchoring is "paper", and paper receipts never carry finality language — there is no finalityStatus, because that field would only ever exist alongside a real transaction hash in a future execution mode. Receipts do record which rules produced them: registryVersion and oraclePolicyVersion, plus the valuation block documenting the token-value, display-only-multiplier pricing rules (see Receipts).

Reading provenance as a user

• Check the validation receipt first. valid-with-warnings is fine (paper mode warns on unknown addresses); invalid means the manifest broke a hard rule.
• Compare weightsChecksum across shares. Same checksum, same allocation — no silent reweight between the post and the page.
• Follow the lineage before praising a fork. The interesting part of a fork is its delta from the parent.
• Ignore any “performance” framing. If it isn’t labeled simulated, it doesn’t exist here.

Developers: the receipt-level field reference and verification snippets are in Receipts; agent-facing usage is in the agent kit.