The Attestation Layer

draft first cut, 2026-09-13.

Breadcrumbs is not a document format, and not a journal. It’s the layer that sits over documents, claims, and contributions of any shape, and answers a narrower question well: who said this, when, and what does it connect to.

Three layers, three questions

Each layer absorbs a different category of hard question, so no single layer has to answer everything at once. The front door doesn’t need to understand claim structure; the data plane doesn’t need to be citable.

The base record: id.breadcrumbs.trail

One record type underlies all of it: an author did some kind of thing (a claim, a piece of evidence, a question, a review, a physical tap — kind is an open string, not a fixed enum) about some subject (anywhere it lives — an AT-URI, a URL, a DOI), at some time, with zero or more typed connections to other trails (supports, opposes, explainer, helpful, and — for a physical crumb — received-from/ handed-to).

It deliberately carries no title, abstract, or content-structure field of its own. The moment it grows one, it starts duplicating what document-shape projects like OXA or Curvenote already do well. Breadcrumbs attests to a document; it doesn’t compete with what defines one.

The pilot: project-to-ecosystem attestation

Before any of the paper-review machinery above exists, there’s a simpler, already-live use of the same idea: a project in an existing research ecosystem claims its own contribution, and other real participants attest back — using Hypercerts’ existing org.hypercerts.* lexicon directly, no new schema, no hosted service, just an existing AT Protocol account. id.breadcrumbs.trail is the identification+attestation wrapper; Hypercerts’ own records are the attestation lexicon underneath it, reused rather than reimplemented.

This pilot validates the attestation mechanics — signed records, cross-account acknowledgement, an issuer identity anyone can look up and verify — on a simple case before generalizing to the full paper pipeline. It needs neither the front door nor the sensemaking layer at all.

Reward is stored, decay is computed

Two related but structurally different mechanisms:

• Reward is a data-plane fact — a signed field on the record itself (a contribution weight, an evaluator tier). It lives where the record lives, because it is the record.
• Decay can’t work that way. AT Protocol records are immutable and content-addressed — a record’s bytes can’t be aged or corrupted on read without breaking its own signature. Decay has to be a computed property of a view over the graph — a claim’s displayed freshness fading until it’s re-attested — never a mutation of the record itself.

Freshness-decay does double duty: beyond just flagging staleness, it punishes “extract credit once, then disappear” the same way a bonding curve’s self-inflicted slippage punishes dumping — not just non-contribution, but disengagement after extraction. It’s also one of the few places this project’s underlying metaphor comes from an older source than the protocol itself — see Roots.

What’s a known, open gap

Nothing today stops an org.hypercerts.collection record from impersonating a listed project — Hypercerts itself has no namespace authority, and neither does the ecosystem directory breadcrumbs draws its pilot cohort from. Acceptable for now because that cohort is small and directly contacted, not open self-serve; a real question to revisit before opening this past that cohort, likely via the same social-proof mechanism as everything else here (other real participants’ own acknowledgements), rather than a new gatekeeping system.