SOURCED Badge
sourced.network — the proof surface

Don’t trust it. Check it.

Sourced’s honesty is not a promise. It is (a) an adversarial test suite you can execute against the live engine right now, and (b) a hash-chained verdict history whose integrity you can verify yourself. Both live on this page, with their full semantics documented below.

1The yardstick — run it live

@sourcedhq/conformance encodes the honesty guarantees (spec §6) as executable, adversarial cases. The button below runs the full suite server-side against the live engine, fresh on every click — no cached results. The same suite runs in CI on every commit; the same suite can be pointed at any engine claiming to count sources.

2What the suite attacks

AttackGuaranteeExpected behavior
coincidental overlapG1Two short titles sharing 2 tokens by chance (Jaccard 0.67) must NOT corroborate each other — the shared-token floor blocks the merge.
event hijackingG1/§7A keyword-stuffed title sharing 3 real tokens buried in noise fails the similarity gate and stays a bare single-origin claim.
syndication floodG3Ten copies from ONE origin → corroboration 1, unlabeled. Duplicate origins inside a provided cluster also collapse.
receipts integrityG4A corroborated verdict names the other origins — never its own — capped at the display limit; the count itself is never capped.
single-source decorationG5One origin → no signal, no receipts, no badge. Ever.
fake urgencyG6An OLD story newly corroborated reads “developing”, never “breaking” — urgency rides the upstream publish clock only.
dead storage / garbage inputG7A store that throws on load AND save, or unparseable claims: verdicts still come back (or null), the stream never breaks.
memory honesty§4first-seen timestamps stay stable across runs; corroboration accumulates through the store; expired events retire into the archive, not into deletion.

Sanity cases run alongside the attacks (e.g. four genuinely identical reports from distinct origins must reach “confirmed”) so the suite cannot be passed by an engine that simply never merges anything.

3Verify a transparency chain

Paste a chain below — JSONL, one record per line, the exact format the sourced-anchor CLI writes. Every record hash, back-link and sequence number is recomputed in your browser (WebCrypto) — this server is deliberately not part of the trust path. You get the receipts, not a flag: per-record checkmarks and the computed head. (POST /api/verify exists for programmatic use, §6.)

4Log specification

A Sourced transparency log is an append-only chain of records, one per verdict batch. Its purpose: make the claim “this history was never rewritten” checkable by anyone, using nothing but the records themselves and one published head hash.

Record format

FieldTypeSemantics
seqnumber0-based position in the chain. Must be contiguous — a gap is a verification failure.
tsnumber (epoch ms)When the record was appended.
payloadHashstring (hex)SHA-256 of the canonicalized payload: JSON with all object keys sorted recursively, so the same payload always hashes identically regardless of construction order.
prevHashstring (hex)The previous record’s hash; empty string for the genesis record. This is the link that makes rewriting detectable.
hashstring (hex)SHA-256(seq + "|" + ts + "|" + payloadHash + "|" + prevHash) — commits to the position, the time, the content, and the entire history before it.

Verification semantics

  1. For every record i: recompute hash from its fields — mismatch means the record was altered.
  2. Check prevHash equals record i−1’s hash (or "" at genesis) — a break means history was rewritten or spliced at this point.
  3. Check seq = i — a gap means records were removed.

An attacker who rewrites record k and recomputes its hash still fails: record k+1 points at the original hash. To forge a history they must rewrite every subsequent record — which changes the head hash, which is the one value published where they cannot touch it.

Inclusion proofs

Given a verified chain and a payload, checking payloadHash(seq) = SHA-256(canonicalize(payload)) proves that exact payload was committed at that position when the head was anchored — e.g. “this verdict, with these receipts, existed unmodified on this date.”

5Anchoring in practice

The chain head is one 64-hex-character value. Publishing it anywhere you cannot silently edit — a git commit, OpenTimestamps, even a dated post — anchors the entire history up to that point. The reference tooling:

# append verdict batches to a chain file (JSONL), then:
npx sourced-anchor chain.jsonl --anchors anchors.log
# → VERIFIED 1042 records
# → 2026-07-11T09:00:00.000Z seq=1041 head=ed2a7dba…c416e80
# commit anchors.log — the git history becomes the anchor trail

6API reference

GET /api/conformance

Runs the full suite server-side against the live engine. Response: { ranAt, engine, passed, failed, results: [{ id, guarantee, title, pass, detail }] }. No parameters, no caching, CORS open.

POST /api/verify

FieldTypeSemantics
chain eitherLogRecord[]The chain as a JSON array…
jsonl orstring…or as raw JSONL text (one record per line).
payload optionalanyWith seq: also check an inclusion proof for this payload at that position.
seq optionalnumberPosition for the inclusion check.

Response, valid: { ok: true, length, head, payloadIncluded? } · broken: { ok: false, badIndex, reason } where reason is "hash mismatch", "broken link" or "sequence gap". Limits: 2 MB body, 100 000 records hosted (the CLI has no limit).

7Anchor registry

LOADING
Reading the Tickwire production chain…

Tickwire’s production deployment chains every verdict batch; the head is served publicly at app.tickwire.news/api/sourced, and once a day the head is anchored into public git historyanchors/tickwire.log, whose commit timestamps not even we can backdate. Everything you need to verify is public: the chain, the math, the anchors — and a browser.

Check a hash

Got a head hash — from an anchor line, a screenshot, an old tweet? Paste it. Your browser recomputes the public chain and the anchor log and tells you exactly where it fits — or proves that history was rewritten.

8The ✓ Sourced mark

The mark asserts one checkable fact: the corroboration engine behind this product passes the Sourced conformance suite — unmodified, current version. Not “we count sources somehow”; the yardstick on this page, passed in full.

SOURCED Badge

How to earn it

  1. Run runConformance(yourAssess) from @sourcedhq/conformance in your CI, on every release of your engine.
  2. Keep the passing run publicly reachable (a CI log or the published JSON report).
  3. Display the badge — linked, with attribution (below).

Self-serve by design: the suite is the authority, not a committee. False claims are trademark violations (see the policy) and get named publicly — the same undercount principle that governs the engine governs the mark.

Attribution — the price of the mark

Using the mark (or the claim “Sourced-conformant” / “Built on Sourced”) requires visible attribution: the badge or claim must link to https://sourced.network, and the product’s documentation must state what the verdicts mean — corroborated, never “true.” The code is MIT and free forever; the mark is earned, linked, and honest — or not used at all.

Embed

<a href="https://sourced.network">
  <img src="https://sourced.network/mark/sourced-mark-badge.svg"
       width="190" height="52" alt="✓ SOURCED — conformant corroboration engine">
</a>

Full terms: TRADEMARK-POLICY.md.