Curriculum · Provable claims

The Verifiable Record

5 lessons · For: Anyone who has to trust, audit, or publish cross-organization work

Every organization publishes numbers about itself. This track is about the small set of them that a stranger can check without taking your word for it — and how the estate is built so those are the ones on the page.

The through-line is a single test you can apply to any claim: could the party making it raise it just by talking more about itself? If yes, it is a gate, not a proof.

Five lessons. No code, though every mechanism here has an open, offline verifier behind it.

Lessons

Two tenses, shaped differently on purpose

You should be able to: Explain why the future-tense and past-tense records are not symmetric.

The estate keeps two records of work. The future tense is the backlog: what an organization intends to do. It decays if nothing happens, and it is never sealed. The past tense is the shipped record: one sealed entry per thing that actually shipped, which never decays.

The asymmetry is deliberate. An intention that stayed fresh forever would let an organization look busy without doing anything; a shipped record that decayed would let real work disappear. Making the two symmetric breaks one of them.

When you read either, read the tense. A roadmap is a promise with a shelf life; a shipped entry is a fact with a seal. Treating a promise as a fact is the oldest way to be misled by an honest-looking page.

The transparency log reveals that, not what

You should be able to: Describe a content-free log entry and why it can be public without leaking anything.

The estate runs an append-only transparency log that many organizations fold their sealed outcomes into. The trick is that each entry is content-free: it reveals that an outcome of a certain kind was sealed at a certain time, and nothing about who or what.

A leaf is a hash over a non-identifying projection — an opaque digest, a kind, a timestamp — reproducible by anyone without ever seeing the underlying record. That is what lets the log be fully public: there is nothing in it to protect.

This is why an identifier is never hashed into a leaf if it comes from a small, guessable space — a hash of one of those is reversible. The log’s whole value is that publishing it costs no privacy, and one identifying leaf would end that.

Source: Flashy Network — the public face of the mesh

Countersignature: the other side signs

You should be able to: Explain why a claim the counterparty signs is worth more than one you assert.

A countersignature is a claim about a relationship that the other organization signs. “We work with them” is an assertion; “they signed that they work with us” is a witness. The estate publishes the second kind because the first is free to make.

The reason to prefer it is the test from the intro: you can raise your own assertions at will, and you cannot raise the count of claims someone else has signed about you. That is exactly why it is the number worth putting on a page.

A witness only counts when its basis is independent. Two organizations restating the same underlying evidence are one source counted twice, not corroboration — so the estate treats byte-identical bases as a copy, never a second witness.

Verify it yourself, offline

You should be able to: Know that the estate’s claims ship with an open verifier, and what that guarantees.

Every sealed thing the estate publishes — settlements, receipts, the shipped record — hashes through one shared canonicalization, and there is an open verifier that runs in your own shell or browser. You do not have to trust the publisher’s copy; you can re-run the hash.

This is the difference between a claim and a proof. A settlement page that says “verified” is worth exactly as much as your ability to check it, and the estate’s answer is to hand you the checker rather than the conclusion.

The habit worth building: when a record matters, verify it rather than read it. An open verifier that nobody runs is decoration; the point is that you can, and occasionally do.

Source: Flashy OS — verify

A number you can raise at will is a gate

You should be able to: Apply the one test that separates a published proof from an internal metric.

The estate’s sharpest rule about measurement: any figure you can raise just by doing more of your own activity is an engineering gate, useful internally, and must not be published as evidence. The figures that go on a page are the ones you cannot move by talking about yourself.

This is why the estate will publish an honest zero — a count of cross-owner sealed outcomes that reads zero — rather than a flattering number it controls both ends of. A zero you cannot inflate is more trustworthy than a large number you can.

Carry the test out of here and apply it to everyone’s numbers, including your own. If the person reporting a figure can raise it unilaterally, it is telling you about their effort, not their results.

Source: Flashy Academy — Running a Joint Initiative

Frequently asked

Why publish a number that reads zero?

Because it is a number the estate cannot raise at will — a count of sealed work across a real ownership boundary. An honest zero you cannot inflate is stronger evidence than a large number you control both ends of.

Does the transparency log expose who did what?

No. Each entry is content-free: it shows that an outcome of some kind was sealed at some time, reproducible by anyone, with nothing about who or what. That is what lets it be fully public.

How do I check a settlement is real?

Run the open verifier yourself, offline. Everything sealed hashes through one shared canonicalization, so you re-run the hash rather than trust the publisher’s copy.