Introduction

draft first cut, 2026-09-13.

The short version: attestation already has real infrastructure — Hypercerts for ecosystem contributions, Mira’s own attestation work — but none of it is interoperable with the others. Breadcrumbs is the framework that lets it be: two attestation types, badges (an authority attests to you) and crumbs (anyone attests anything for anybody else, no authority required), shaped so any project can adopt either without adopting breadcrumbs’ code or handing it their data. It complements Hypercerts and Mira rather than competing with them.

Peer review reduces a whole provenance trail — the observation, the evidence, the reasoning, the disagreement along the way — to a single opaque verdict: accepted or rejected. Everything that led there is usually invisible once the result is published. Breadcrumbs is infrastructure for making that trail legible again: from raw observation, through evidence and review, to attestation, retraceable the way a paper trail used to be — for any contribution. A finished paper is where this project started (it’s the case peer review itself was built around) and one real instance of it, not the unit everything else here is measured against.

It’s built on the AT Protocol (the network behind Bluesky): every claim, piece of evidence, or attestation is a signed record in its own author’s personal data repository, not a row in breadcrumbs’ own database. Nobody has to trust a central breadcrumbs server for the data to mean anything — that’s a design constraint, not a slogan; see The Attestation Layer.

Two things are deliberately both called “crumb” in this project:

• Badges — issuer.breadcrumbs.id attests to someone that they did something (attended an event, completed a station) — not “breadcrumbs” generically, that specific issuer identity. Authority- minted, needs an issuer identity.
• Crumbs — a person attests to their own trail: anyone can attest anything for anybody else, no issuer required. Self-minted — the record lands in the tapper’s own repository, never breadcrumbs’. The concrete, working version of this today is anchored to a physical object — an NFC tag or printed QR code on a card, a sticker, a pendant — but the mechanism itself isn’t physical-object-specific. See Physical Crumbs, which is also the part of this project you can actually go try right now.

How to read this

Each chapter stands on its own — if you got a link straight to one section, you don’t need to have read the others first. The Appendix has two different kinds of supporting material: Roots grounds the project’s vocabulary (trail, decay, attestation) in older, non-technical sources — a fairy tale and a folk tradition, not just protocol names. The Artifact Series links to the actual interactive design mockups referenced throughout — worth opening directly rather than taking the prose’s word for what they show.

Where this stands

The self-minted crumb flow (real OAuth login, physical NFC hardware, a live registry) works end to end today, hand-tested and covered by an automated regression suite. The badge system and the sensemaking/ front-door layers described in the next few chapters are architecture and active work, not yet live — each chapter says plainly which state its own subject is in, rather than presenting everything as equally finished.

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.

It isn’t the first attestation system, either — Hypercerts already attests ecosystem contributions, and Mira does something adjacent — but none of them are interoperable with each other. Breadcrumbs’ job is that missing interoperability: a shared badges/crumbs vocabulary (see Introduction) any of them can adopt at the lexicon level, without adopting breadcrumbs’ code or handing it their data. breadcrumbs.run is today’s concrete instance of that — the badge-issuing back office — while breadcrumbs.network is where the cross-project coordination itself happens.

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 registry verifying which DID is actually entitled to represent a given project (its own architecture cryptographically verifies who signed a record, not who a record is allowed to speak for). (Checked directly, not assumed: hypercerts.org‘s own, different, NSID schema authority is real — its _lexicon/_atproto DNS TXT records both name the same DID. That’s authority over the schema namespace, unrelated to the gap above.) 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.

Atmospheric Evidence Discovery — A Live Labeler

draft first cut, 2026-09-21.

A signed record on its own only answers “who said this, when.” It doesn’t answer whether an acknowledgement of a claim is a genuine attestation or a pro-forma “nice work” that never actually engaged with what it’s acknowledging. That second question needs judgement, not just signatures — and breadcrumbs now has a live, self-hosted service that makes exactly that judgement, publishes it as a real signed label, and is running today at labeler.breadcrumbs.run.

What’s actually making the judgement

TypeSafe’s Jev is a “System One” model: given some state and a question, it returns a typed judgment or probability — not generated text, not a chat reply. Two of its primitives do the work here:

• Noul — a bare probability that a condition holds, no separate confidence band. Used to ask: does this acknowledgement genuinely attest to the claim, or is it templated, bot-like, or not actually engaging with the specific thing being acknowledged?
• Score — a probability-weighted position on a small set of described levels. Used to judge an evaluation’s own justification text against the claim it evaluates, rather than trusting a bare pre-normalized number with no visibility into why it landed where it did.

Both replace a cheap, gameable proxy — a raw acknowledgement count, a bare numeric score — with a judgement of the evidence’s actual content. Neither generates anything; they only judge what’s already there.

Three ways evidence could reach it, one way it’s live today

The full design covers three discovery pipelines feeding one judgement call — see the diagram for the complete picture, including which are built and which are still gaps:

• Record track — a formal org.hypercerts.context.acknowledgement record on the acknowledging party’s own PDS. The shape breadcrumbs’ signal-reading logic already expects; real record parsing isn’t built yet.
• Outbound engagement — someone’s own Bluesky post naming a crumb. Needs real full-text Bluesky search to discover, which doesn’t exist yet — a known, named gap, not an oversight.
• Inbound reaction — likes, reposts, and replies landing on a trail record’s own AT-URI, discoverable via Constellation’s backlink index once trail records are themselves interactable content.

What’s live today is a fourth, more direct path that proves the judgement layer end to end rather than waiting on all three: a reply to one of breadcrumbs’ own Chatto-room confirmations (see Physical Crumbs for the badge-claiming flow this extends) gets judged by Jev, thresholded into one of two label values — genuine-acknowledgement or pro-forma-acknowledgement — and published as a real, signed com.atproto.label record. The raw probability stays visible in the reply for a human to see; it never becomes the label value itself. That distinction isn’t cosmetic: the AT Protocol label spec explicitly recommends against encoding scores or confidence values directly in a label, precisely because a label is meant to be drawn from a small, fixed, inspectable vocabulary — real deployments (Bluesky’s own Automod included) collapse continuous judgement down to a handful of named tokens before anything gets published, and labeler.breadcrumbs.run follows the same convention.

A real identity, not a bare API

Labels are signed, attributed records — src names the issuing DID, sig is a signature over the label, verifiable against that DID’s registered signing key. None of that works without a real, resolvable identity behind it, so labeler.breadcrumbs.run is exactly that: a real did:plc account, its handle verified, self-publishing its own app.bsky.labeler.service record the moment it starts up. Anyone — a Bluesky client, a future breadcrumbs viewer, anyone at all — can subscribe to it and independently verify what it says, the same way any other labeler on the network works. Building a bare, unsigned HTTP endpoint instead would have been less work and would have thrown away the actual point of using the label mechanism: native rendering in real atproto clients, and a verdict that isn’t just breadcrumbs’ own word for it.

What’s genuinely still open

• Outbound and inbound discovery (above) aren’t built. The judgement layer is proven against one real evidence source; the wider atmospheric-discovery breadth the diagram describes is still ahead.
• How a judged verdict becomes a trust score is deliberately unresolved, not quietly decided. Breadcrumbs’ trust bandit (arms.rs) picks a single winning signal per claim on purpose — never a blend — specifically so a later outcome can be attributed back to the one signal that was actually bet on. A verdict from this labeler can either strengthen that one signal directly, or become a separate, blended number shown alongside it (e.g. on a trail page) without ever feeding the bandit’s own reward calculation. Both are real options; neither is picked yet. The diagram marks this fork explicitly rather than presenting a settled answer.
• Which failure modes get their own label, not just a yes/no. A badge’s issuance context, for instance, has at least three real outcomes worth distinguishing — plausible, self-dealt, reciprocal exchange — currently collapsed into one bare probability. Worth a richer judgement later, not solved here.
• Is “genuine” even the right word for genuine-acknowledgement? Raised 2026-09-24: what Jev actually tests is specificity of engagement with the claim’s content, not sincerity — a heartfelt “Nice work!” is sincere but fails the test; a detailed-sounding templated reply could pass it. “Grounded,” “substantive,” or “engaged” (vs. “generic”/ “pro-forma”) may name the real axis better. Not decided — this is a small, already-shipped label vocabulary, so a rename is a real change, not a free edit. Full detail: breadcrumbs-2j46.

Why this is the concrete version of an accountability argument

Why This Fits AI for Science & Safety argues that as AI systems increasingly participate in research, the attestation layer has to identify and hold what made a claim accountable, not only verify humans. This labeler is that argument made real rather than aspirational: an AI judgement, individually attributable to a real signed identity, independently verifiable by anyone, publishing a narrow, inspectable vocabulary instead of an opaque internal score. The same discipline this project already applies to human claims and evidence, applied to what an AI system itself asserts.

Why This Fits AI for Science & Safety

draft first cut, 2026-09-13.

Foresight’s “AI for Science & Safety Nodes” call doesn’t treat AI-for- science and AI-safety as separate asks — it frames them as one transition: use advancing AI capability to unlock scientific breakthroughs while keeping that transition decentralized rather than concentrating compute and power in a few hands. It names three funding layers, and breadcrumbs has a concrete answer for each.

Local compute — community-owned, not rented

co/core is a member-owned cooperative pooling compute people already own to run open models for each other, instead of renting from large clouds — today specifically Apple Silicon Macs (its confidential-computing story is built on Apple’s Secure Enclave), worth naming as the current reality rather than a ceiling: the cooperative model generalizes to other hardware as the network grows. It’s OpenAI-API-compatible, so classification and judging work in breadcrumbs’ sensemaking layer can route through it by default rather than a corporate API. Every job produces a cryptographically signed receipt — the same attestation instinct breadcrumbs already applies to claims and evidence, applied here to compute provenance instead. This is genuinely convergent, not just adjacent: co/core’s own AppView exposes receipts, jobs, and providers as signed public records over XRPC — the same data-plane shape as everything else in this stack, so a compute receipt could plausibly become part of an Evidence node’s own provenance rather than a separate system to bridge.

Decentralized alignment, by architecture

Every claim, evidence node, and attestation lives in its own author’s personal data repository — there is no central database to capture, and federation means any community can run its own trust view over the same shared graph. The anti-concentration property this RFP asks for isn’t a safety story bolted onto breadcrumbs after the fact; it’s what the data plane already is by construction.

Accountability for AI-authored contributions

The part institutional peer review has no answer for yet: as AI systems increasingly participate in research — not hypothetically, but already documented (autonomous editing agents quietly turning read-only web access into write access on public infrastructure, research agents now running multiple research-days per human day while the monitoring meant to catch problems weakens) — the attestation layer has to identify and hold accountable what made a claim, not only verify humans. Breadcrumbs’ Claim/Evidence structure is exactly the audit trail that failure mode needs: an agent’s claim is a record, individually attributable, versioned, and subject to the same tiered verification as a human’s — not exempt from it by default. This is no longer just the architecture’s intent: Atmospheric Evidence Discovery documents a real, self-hosted labeler making exactly this kind of AI judgement today, itself identified by a real signed identity rather than an opaque internal score.

Supercollaboration, not headcount

The core diagnosis breadcrumbs is built against — first-author pipelines strangling grassroots collaboration — is the same problem this RFP names when it asks for smart allocation of compute and workflow automation instead of large teams. The build plan (one person, forking existing production infrastructure rather than starting cold) is already shaped that way, not scaled up to it after funding arrives.

AI-first science, concretely

A modular, continuously-published document model — decomposing a paper into reusable, individually-verifiable claims — is the actual mechanism for unlocking breakthroughs at the pace AI-accelerated research already moves, without losing the ability to check any one step of it.

The accountability point is the one specific to this RFP, not a generic “open science is good” pitch — and it’s grounded in something already happening, not a hypothetical risk.

Physical Crumbs — Attestation You Can Tap

draft first cut, 2026-09-13.

Everything else in this book is architecture. This chapter is a thing that works today: tap a physical object, log in with your own handle, and it joins your own trail.

Get early access

This is genuinely pre-alpha — built over one weekend, and one real crumb has been anchored with it end to end. That’s exactly why the facilitator tooling (the print-sheet generator, the single-anchor tool) isn’t linked here: it’s not ready to hand to strangers yet. Leave a handle or email at breadcrumbs.run/interest and we’ll reach out directly as it matures, rather than leave working- but-unpolished tools open to anyone who finds the link. When someone does tap a real crumb, the flow itself is real: a QR code points at /anchor/<id>, and logging in is your own AT Protocol handle (Bluesky, a self-hosted PDS, whatever account you already have) — no breadcrumbs-owned identity, no password, approve the login on your own server, done.

Two things share the name “crumb,” on purpose

• Badges — issuer.breadcrumbs.id attests to someone that they did something (attended an event, completed a station) — not “breadcrumbs” generically, that specific issuer identity. Authority- minted: needs breadcrumbs’ own issuer identity, and is still being built out.
• Crumbs — a participant attests to their own trail, anchored to a physical object. Self-minted: the record lives in the tapper’s own repository, never breadcrumbs’. This is the part that’s live — chosen specifically because it needs no issuer at all, so it didn’t have to wait on any authority/identity decision to ship.

The shape of a trail

One physical object anchors a star: every person who taps it before it’s handed off connects back to the same anchor id. A handoff is a leap — a received-from / handed-to connection to the previous holder’s own trail record, the same shape other AT Protocol “met-in-person” projects (like youandme.at) already proved out for a single fixed subject, generalized here to any physical object someone hands to someone else.

Decay depends on what it’s made of

Different materials carry a different “how likely is this actually still around and cared for” prior — a peeled-off sticker decays faster than a pendant worn as a keepsake. The decay math itself doesn’t change; each medium just gets its own window multiplier:

Real login, not a password stopgap

The first version of this asked for an AT Protocol “app password” — a concept almost nobody outside this ecosystem has heard of, and the actual first real person to try it got stuck on exactly that. It’s since been replaced with real OAuth: type a handle, a live typeahead finds it, and you’re redirected straight to your own server to approve — breadcrumbs never sees a password, or anything else about your account beyond the one record it asks permission to write.

Decoupled from the physical object itself

Printing or writing a tag doesn’t activate anything by default — a facilitator flips an anchor “live” as a separate step, so a whole sheet of QR codes or a box of NFC cards can be produced ahead of time and switched on individually, exactly when and where each one is actually placed.

Design Language & Vocabulary

draft first cut, 2026-09-13.

The core metaphor: the trail

This ecosystem already shares one vocabulary — “the Atmosphere,” AtmosphereConf, atmospheric.reviews, AT Protocol Spaces described by its own author as “a deeply social & atmospheric primitive.” Breadcrumbs’ own contribution on top of that shared metaphor is the trail: a claim is legible only if you can retrace the crumbs behind it — back through its evidence, to whoever attested it, to the identity that vouched for them. The name is literal, not decorative: the project exists because that trail is currently invisible in institutional peer review, and the whole point is to leave one where none exists today.

Reused terms, not renamed

• Claim, Evidence, Question, Project — Discourse Graphs’ own node types, used as-is.
• Anchor + Sidecar — a public record paired with a gated companion record in an AT Protocol Space. Used with exactly these words so they read as the same primitive everywhere they appear.
• Sensor — a saved link that keeps listening, surfacing what the network later learns about it back to whoever saved it. Sharper than “bookmark” for what a claim’s provenance record actually does over time.
• Connection — a typed relation between two records (supports, opposes, explainer, helpful) — the same shape as an Anchor/Evidence edge, named the way the ecosystem it sits in already names it.
• Trail — breadcrumbs’ own addition: the retraceable path from a claim back through its evidence to its attestation. Also the name of the base record itself (id.breadcrumbs.trail) — one attested contribution, not the whole path; a deliberate overload of the same term, not an inconsistency.
• Front door — the citable, ISSN/DOI-eligible journal layer, atmospheric.reviews.

Trail, not pheromone trail

It’s tempting to describe shared attention as “attention traces” that recycle like an ant colony’s pheromone trail — a real and useful observation about how aggregate attention propagates through a network. But breadcrumbs’ own trail is not that: every crumb is a specific, attributed connection someone made on purpose — a claim, an evidence link, an attestation — not an anonymous emergent residue anyone can follow without knowing who left it or why. Human coordination doesn’t run on stigmergy the way an ant colony does; it runs on people making legible, accountable claims about each other’s work. Keep trail. Drop pheromone.

Visual register: inherit, don’t redesign

The front door (atmospheric.reviews) already committed to its own visual identity — carry that forward rather than introducing a second one for the same surface. Legibility should decrease deliberately as you move deeper into the stack: the front door reads as a calm, institutional journal; the sensemaking and data-plane tooling underneath can be more visibly experimental and atproto-native, matching the actual trust and audience gradient between the layers instead of pretending the whole stack is equally finished.

Domains & Lexicon Authority

draft first cut, 2026-09-13.

Four domains, each scoped to exactly one role rather than one domain trying to cover all of them:

• breadcrumbs.id — NSID authority for the base Trail record itself (id.breadcrumbs.trail), and breadcrumbs’ own real issuer identity: issuer.breadcrumbs.id, a live, permanent, self-hosted AT Protocol server. It’s also published as a did:webvh identity — a self-certifying identity log anyone can independently verify without trusting a directory operator, directly on-thesis for an attestation-layer project. /whois lets anyone see who has publicly vouched for it. Now actually published, not just asserted. The same real mechanism hypercerts.org and smokesignal.events use: a _lexicon.breadcrumbs.id DNS TXT record naming the controlling DID, and an actual com.atproto.lexicon.schema record written into that DID’s own repo (at://did:plc:x44m.../com.atproto.lexicon.schema/id.breadcrumbs.trail, fetchable by anyone, no auth). This closed a gap this chapter originally disclosed rather than hid — the authority was previously asserted by convention (owning the domain, running the server) with nothing a third party could independently check; now the schema itself is checkable the same way /whois already lets someone check the issuer’s own vouching.
• breadcrumbs.network — the wider-ecosystem interop point: compliant with other projects’ lexicons for interop’s sake, not just hosting breadcrumbs’ own schema. Live as of 2026-09-19, a real deploy rather than an empty registered name: breadcrumbs.network, with a cross-linked German version at /de/, hand-authored static HTML on the same VPS and Caddy instance as breadcrumbs.run. Its first tenant is CoCore Attractor, a separate physical compute/attestation-node project for field robots and tractors (at.tractor NSID authority; its own tractor.at domain stays lexicon-authority-only until a real Austria partner exists), shown through its own design language, Cab & Hitch. The page was also pitched to Ronen Tamari the same day as a candidate partner project inside MOSAIC (his own R&D program spanning ATScience, Cosmik/Semble, MIRA, Discourse Graphs, eLife Pathways, Catalyze) — sent, no reply yet, genuinely open either way, not something this page claims one way or the other.
• breadcrumbs.run — the execution/plumbing layer: labeler, inference endpoints, and the services mostly invisible on the traditional web. This compendium’s own home (docs.breadcrumbs.run) sits alongside it.
• breadcrumbs.chat — a shared space where humans and agents socialize together around contributions.

Co-evolving, not competing

OXA already defines a pub.oxa.* lexicon for publishing scientific documents on AT Protocol — documents live in any personal server, user-owned, portable, discoverable. breadcrumbs.network’s own schema should co-evolve with pub.oxa.* rather than compete with it as a second, incompatible document lexicon.

Breadcrumbs is the attestation layer, not a competing document format. The ambition is to eventually cover what OXA, Curvenote, and Discourse Graphs each already do well in their own domain — document representation, continuous/modular authoring, and claim/evidence structuring — through integration points with each, not by reimplementing any of them. A trail record’s subject field references an artifact wherever it actually lives and however it’s represented (an OXA document, a Curvenote manuscript, a Discourse Graphs node, a plain PDF) — deliberately addressing-scheme-agnostic, which is also why the base record doesn’t need a title, abstract, or content-structure field of its own.

Deliberately postponed, not decided: whether every contribution ends up with its own decentralized identity, versus an AT-URI record inside the author’s existing repository — the author field works either way; this gets revisited once co-evolution with OXA’s own document-identity model clarifies it, not decided in isolation.

Co-evolution isn’t only a publishing-side argument — see Dogfooding: Margin as the First Experiment for a live example already in progress, from the consuming side instead.

Dogfooding: Margin as the First Experiment

draft first cut, 2026-09-13.

This compendium is now being reviewed with a tool breadcrumbs had no part in building, no partnership with, and no advance knowledge of — and it took zero integration work to make that possible.

What margin.at actually is

Margin is a real Chrome/Firefox extension: install it, and it lets you highlight or comment on any web page, writing what you write as a real record in your own AT Protocol personal data server — not to margin.at’s own database. Its lexicon (at.margin.*) defines at.margin.note, a W3C Web Annotation Data Model-compliant record with a motivation (commenting, questioning, assessing, highlighting, and others), a target (the URL being annotated, plus a W3C selector — an exact text quote, a character range, or a CSS/XPath/fragment locator pinning down where on the page), and a body carrying the actual comment. Replies thread via a sibling at.margin.reply record. Like every other record this project deals in, it is signed, portable, and lives wherever its author’s own identity lives — not in margin.at’s infrastructure.

Why it worked immediately

Torsten installed the extension and asked whether it could double as a review tool for this compendium. It already can, and needed nothing built to prove that much: an at.margin.note’s target.source field is just a URL, and Constellation — the same network-wide backlink index this compendium’s own /whois page already uses to find who has acknowledged the issuer — indexes it automatically, the same way it indexes anything else on the network:

getBacklinks?subject=https://docs.breadcrumbs.run/<chapter>.html
             &source=at.margin.note:target.source

That query works today, verified live. No API key exchanged with margin.at, no schema registered anywhere, no conversation between the two projects’ authors. A facilitator-only view in trail-of-crumbs (/workbench/annotations) surfaces exactly that query per compendium page, and a local script (compendium/scripts/pull-annotations.mjs) turns a found annotation into a suggested <mark>-wrapped prose change, feeding straight into REVIEW.md’s own draft → mark → review → finalize cycle — the same reading-pass discipline every other chapter in this book already goes through.

The point worth making explicit

Domains & Lexicon Authority argues breadcrumbs should co-evolve with other projects’ schemas rather than compete with them, and that a real, DNS-verifiable NSID authority makes a schema independently checkable by anyone, with nobody’s permission required. Margin is that same thesis seen from the other side — not breadcrumbs publishing something others can build on, but breadcrumbs consuming someone else’s public schema without asking. Two independent projects, each just writing plain, well-formed, public AT Protocol records over a shared open network, compose for free. Coopetition isn’t a hoped-for future benefit here; it’s already load-bearing for how this very compendium gets reviewed.

There’s a second, more literal kind of dogfooding underneath that: breadcrumbs exists to make provenance — who said what, when, attested by whom — legible instead of collapsed into an opaque verdict. The review process for the document making that argument is now itself a set of small, individually attested, PDS-anchored comments. The mechanism and the subject are the same shape.

One honest limitation

A margin.at annotation anchors to an exact span of text via its TextQuoteSelector. This compendium’s own mark → finalize cycle rewrites or strips exactly that text as a chapter matures — so an annotation left during a draft or pending read can go stale once the prose underneath it changes; the selector has no way to relocate itself. The page-level URL anchor doesn’t have this problem — “what has anyone said about this page” always resolves — but a specific in-paragraph position can drift out from under a comment. This isn’t a gap specific to this integration: any web-annotation tool anchored to a living document has the identical fragility (Hypothesis included). Worth living with, not solving structurally.

A second limitation, more fundamental than the first: at.margin.note has no privacy field at all. Every annotation is public, forever, tied to the commenter’s real identity — fine for a settled opinion, a real ask for a half-formed reaction to a draft. AT Protocol Spaces (gated records, already scoped for this project’s own future paper- review pipeline — breadcrumbs-dotv) could eventually solve this for reviewers who’d rather comment privately, but not automatically: margin.at itself would need to support writing into a gated Space, or this compendium would need its own separate, Spaces-based comment mechanism instead. Captured as breadcrumbs-p3xq, not built.

Roots

draft first cut, 2026-09-13.

Design Language & Vocabulary grounds breadcrumbs’ vocabulary in its living technical ecosystem — Discourse Graphs, Curvenote, Semble, Cosmik Labs. This chapter grounds it a level deeper, in older, human sources: a fairy tale everyone already knows, and a regional ritual few outside it do.

Hansel and Gretel — where decay was always in the name

Before breadcrumbs was an attestation layer, it was already a story about a trail that fails. In the Grimm tale, the children mark their way home through the forest with a trail of breadcrumbs — and the birds eat them. The trail doesn’t just sit there waiting to be retraced; it is eaten, silently, by something with no stake in whether the children find their way back. By the time Hansel and Gretel turn to follow it home, there is nothing left to follow.

This matters for more than the name. It means decay was never a borrowed concept — not something reached for from a bonding curve’s anti-dump mechanic and grafted onto breadcrumbs from outside. A breadcrumb trail, in the story that gives this project its name, was always a perishable marker, not a permanent one. Freshness fading until re-attested isn’t an import into the metaphor — it’s the metaphor’s own original failure mode, arrived at independently and only recognized afterward.

Worth sitting with, not resolving: in the story, decay is what causes the children to get lost — an unambiguous bad outcome. In breadcrumbs, decay is deliberately protective — it’s what stops cheap, one-time attestation from coasting on stale credit forever. Same mechanism, opposite valence. That tension is honest, not a flaw in the metaphor — it’s exactly the difference between a trail nobody is tending and a trail whose tending is the whole point.

Worth naming directly, since it’s the hinge into what follows: a tale like this one was never a children’s bedtime story to begin with, and never a solitary one either. Grown-ups told it to each other, most often in a Spinnstube — a shared room where women worked through the dark months and traded stories as they went. The idea that children need their own separate, shielded literature is a nineteenth-century invention; before that, “Hansel and Gretel” was an adult, communal practice, retold across exactly the long, liminal winter nights Rauhnächte still marks below. That’s the same shape twice, before either the Grimms or this project touched it: a plural, oral tradition, tended collectively, through a liminal seasonal window. Canonization is what happened when that got frozen into a single authored text — the second failure this project’s name inherited, taken up next.

What happened to the story itself

Before Grimm, a fairy tale wasn’t one thing. It was told and retold across villages and generations, each telling its own variant, with no single authoritative version — closer to a plural, unattested graph of independent tellings than a canonical text. That plurality is exactly what the Brothers Grimm’s own project ended.

Kinder- und Hausmärchen went through seven editions between 1812 and 1857 (86 tales growing past 200), and Wilhelm Grimm, its principal reviser, reworked the prose every time — more literary, more dramatic, more sentimental with each pass, moving steadily away from the oral register it started in. The edits weren’t only stylistic: in both “Hansel and Gretel” and “Snow White,” the murderous mother of the first edition becomes a stepmother by the final one — a deliberate moral edit, made silently, leaving no trace in the “official” text of what the earlier version actually said.

The sourcing was reshaped to match. Dorothea Viehmann, one of the Grimms’ most-cited informants, was presented in their foreword as an authentic Hessian peasant woman carrying pure oral tradition — she was in fact a literate tailor’s wife of French Huguenot descent from urban Kassel. That framing wasn’t an error; it served the collection’s own Romantic-nationalist project of building a shared cultural identity out of “authentic” folk material. Whether a source was really “pure Volk” mattered to that argument more than whether it was true.

So: a plural, orally-attested tradition got frozen into a single canonical text, revised repeatedly according to an undisclosed agenda, its provenance presented as more authentic than it actually was — with no legible trail back to what changed, when, by whom, or why. That is not adjacent to a single opaque verdict replacing a legible trail — it is the identical failure, in folklore, a century before the questions this project answers today. The story that gave breadcrumbs its name was itself subjected to exactly the problem the project exists to prevent.

Rauhnächte — the twelve nights between the years

Rauhnächte — the “rough nights” / holy nights, the twelve-night span between December 25 and January 6 observed in German- and Alpine-region folk tradition. Not a universal reference like Grimm — a tradition local to where this project’s own roots are, brought in deliberately for that reason: a time held between conscious retrospection and orientation toward what’s coming, made legible through a sequence of small, attributed acts across twelve nights, each carrying its own significance.

What resonates, concretely:

• A liminal, otherwise-untracked passage made legible through a sequence of small, attributed acts. Twelve nights, each doing something specific, together forming a path from one year into the next — a trail’s actual shape, not a metaphor stretched to fit a structure that already existed.
• Protection that must be actively renewed, not sealed once. Warding isn’t a one-time act here; it’s upheld by repetition. This is freshness-decay again, from a second, independent direction — standing doesn’t persist on its own merit, it’s tended.
• Reading the future from ambient signs, not from an authority’s pronouncement. Using atmospheric signals instead of an external expert-defined ground truth is a much older instinct than any protocol: let the world’s own incidental signals tell you what an authority can’t.
• Warding off what doesn’t belong, without a central gate. A boundary enforced by practice, not by a locked door — echoes an open question breadcrumbs hasn’t fully answered either (see The Attestation Layer’s note on impersonation), not a new shape of problem.

Three groundings, doing different work. Grimm’s story is universal and literary, and it’s why decay was never optional. What Grimm’s own hand did to that story is why canonization without a trail was never a hypothetical risk to guard against — it’s documented history, and it happened to this exact material. Rauhnächte is regional and lived, and it’s why tending, not just marking, was always going to be the actual practice underneath the trail.

Appendix: The Artifact Series

draft first cut, 2026-09-13.

Five design and proposal artifacts, originally published as private Claude Artifacts during the sessions that shaped this project; reproduced here verbatim as static pages under this domain instead, so anyone can actually open them without needing sharing access granted — same content, one fewer moving part.

• Atmospheric Evidence Trail v2 — the full three-pipeline discovery diagram behind Atmospheric Evidence Discovery: which of the three evidence sources are real today, which actor (watchtower / bot / labeler) owns each one, and the deliberately open fork over how a judged verdict becomes a trust score.
• Trailview v1 — the phase-0 pilot’s design-review surface: a static mockup of how reward (a fixed attester-tier stamp) and decay (a fading-ink freshness bar, restorable by re-attesting) render side by side, grounded in the same paper-trail material metaphor as the rest of this project rather than a generic dashboard fade. Invented sample data — reads no live server.
• Magnet or Manifest v1 — a proposal written for an external collaborator working on torrent-like dataset addressing, sketching whether and how a breadcrumbs trail record should attest to a magnet-URI-addressed dataset directly, versus attesting to a stable manifest record that itself references the magnet link. A real tradeoff to react to, not a decided design.
• Crumb Icon Gallery v1 — the first showcase of the deterministic, seeded “star and sticks” visual identity every physical crumb renders as, across a range of connection counts and freshness levels.
• Rose Curve Prototype v1 — an earlier visual-language exploration for the same crumb-icon system, plus parameter-sweep grids used to tune it before settling on the version actually shipped.

These are snapshots of a point in time, not living code. The actual, current crumb-icon generator is part of trail-of-crumbs, the live SvelteKit app behind Physical Crumbs — these pages are the design record of how it got there, not the thing itself.

IOSP Talk: Speaker Notes

draft speaker notes for practice, 2026-10-11.

Five minutes: about 489 spoken words at 130 words per minute, roughly four minutes, so about a minute for questions. Seven slides. The closing line is meant to be remembered:

Don’t trust the person. Don’t trust the number. Read the trail, and judge for yourself.

Slide 1: Intro: computational trust

Computational trust: how can a person, a community or a machine tell whether to believe something? I drew it as a graph twice. The first time I drew the wrong thing: people as the nodes, a wallet at the centre, the token balance as credibility. A token does not remove the gatekeeper, it moves the gate to whoever decides who holds tokens. So here is my question: what if the nodes were claims, and the edges human-made connections between them? Could we then compute trust from atmospheric evidence, meaning social data from the ATmosphere?

Slide 2: Attempt 2: nodes are claims

Breadcrumbs flips it. A node is a claim: a signed record that says this happened, here is the evidence. An edge is a typed connection a person signs: supports, opposes, evidence. Identity is demoted to who signed it, and it lives in their own repository. Subsume, don’t replace: badges and affiliations stay as the base layer and claim nodes go on top, so nobody needs permission to add one. Metrics are graph math over the claims.

Slide 3: The station: add locality, and the ask

This is how claim nodes get made. At our station you do something real: stream a sensor reading, play a synth note. The signed record streams live, and a badge can validate that you did it. But a record alone does not prove you were there. So we add a tap: an NFC tag or QR code on an object, self-minted as a claim in your own repository, attesting one thing, that you were there.

Slide 3b: Locality first: a crumb at the station

These are the objects: the two station magnets, an NFC keyring you can take home, wood disks, and glass cabochons with a QR code inside. The cabochons are a live test. When you finish a station, the box at the end of its worksheet section has a QR code: scan it, log in with your own handle, and the station joins your own trail.

Slide 4: Then you build the evidence

After this talk you go to the stations and make atmospheric evidence yourselves. Play a note on a Wemos synth: it is a signed record. A Wemos with a sensor streams live readings. An airglow automation relays events onward. The toon board is where they all arrive as one fabric. Your records are the real data.

Slide 5: What counts as credible?

What counts as credible depends on the metric you choose and the graph you compute it on. With wallets, the human judges a person. With claims, the human judges a claim, and sees what connects to it and who signed each link. Metrics can describe a claim’s place in the graph, but only a human can judge what that position means. Our bet: claims support human judgement better, because the math is the same but the links are readable, typed and signed. My aim is a model of human judgement, not a replacement. So, can we compute trust from atmospheric evidence? We find out at the stations.

Slide 7: Closing mantra

Don’t trust the person. Don’t trust the number. Read the trail, and judge for yourself. Then questions.