The reference manual: the openly published document that says exactly what a Common Credo record contains, how it is laid out, and how it is read. The most important artefact of the project, deliberately readable by anyone. A record that follows this document is a valid CC record; one that doesn't, isn't.
Status: v0.3 — all eight foundation design decisions (D1–D8) resolved jointly, plus three ratifications (R1–R3), 15 July 2026. Next step: rebuild the demo toolkit and visual against this spec, then warm-seed community review, then v1.0.
The system is designed so that abusing it is most likely to harm the abuser.
A holder who files false disputes marks their own record permanently. An issuer who cancels maliciously poisons its own public track record. A coordinated mob triggers a visible anomaly that throws suspicion on everyone involved, attackers included. The system does not need to catch everyone; it needs to make honesty the rational, cheaper path for every participant. Every mechanism below — stakes, visible reasons, dispute flags, track records, anomaly detection — is an application of this one principle. (Sometimes called mutual destruction: any attempt to damage another participant credibly risks damaging yourself, most likely more.)
CC itself enforces nothing. It makes behaviour visible, permanent, and priced — and lets the market do the rest.
This standard defines exactly three things:
It deliberately does not define: who may lend, how to score, what a "good" standing is, or who counts as a valid issuer in any region. Those live in the add-on layer, set by those who build on CC. Structure is mandatory; tuning is flexible.
A scope test used throughout: CC never does anything with data — it only defines the shape of a valid record. Every mandatory field below is a box the standard defines, an issuer fills, and a verifier reads. CC itself verifies no identity, holds no data, runs no register, and adjudicates no dispute.
Every record involves exactly three roles (the driver's-licence pattern):
(CC's users are the missing middle: small business owners, traders, co-ops, community business organisations, MFIs, chambers, supplier networks — organisations and businesspeople with ledgers and ordinary connectivity.)
A record is not a valid CC record unless it contains ALL of the following:
1. Named issuer, with declared issuer identity anchor. (Extended: D7) Who vouched, identified unambiguously — name, organisation type, location, public verification key, and the issuer's own identity anchor: the external, publicly checkable identifier that establishes the issuer is a real, accountable organisation. No anonymous issuers, ever. See Part II-A for the anchor ladder.
2. The subject reference, with declared identity anchor. (Resolved: D1) Who the record is about — a pointer to an identity established elsewhere. CC does not verify identity. Every record must declare what identity anchor the issuer used — national ID, company registration, phone number, community register — so the verifier sees the binding strength at a glance and prices it. A record anchored to a company registration outweighs one anchored to a phone number, visibly. Nothing hidden, nobody excluded; fraud is priced, not pretended away.
3. The claim. (Resolved: D2) What is being vouched, in structured form: claim type, amount (if applicable), period, outcome. Claim types come from a short fixed core list that every implementation must understand — the working set (to be finalised with the warm-seed community): loan repaid; loan defaulted; trade credit honoured; trade credit defaulted; supplier payments record; savings record; membership in good standing; registration/licence fact; character vouch. Plus a marked regional-extension slot for local claim types, which distant verifiers may ignore. Thin core, open edges — the accordion. Extensions never replace core types; a claim expressible in a core type must use it.
4. The vouch type. The format mandatorily distinguishes a "saw the money move" vouch (issuer witnessed the transactions directly — including as trading counterparty) from a "knows their character" vouch (issuer attests to conduct). Every record declares which it is.
5. Recorded skin-in-the-game. (Resolved: D3) The issuer's stake — what the issuer stands to lose if the vouch proves false — is part of the record. The presence of the field is mandatory; amount and form are regional tuning. Stake may be financial or reputational (the issuer's own track record of accurate vouching is recognised stake).
Zero stake is permitted only under a declared profile: the issuer declares its type, and the claim is a factual attestation (membership, registration, tenure) rather than a credit judgement. This accommodates NGOs, chambers, and registries that legitimately cannot stake. A credit-judgement claim carrying zero stake remains valid but flagged — verifiers see a credit vouch nobody backed and price it accordingly, near zero. Zero-stake drift dies economically, not by prohibition.
6. The seal, and the record's identity. (Extended: R1) The issuer's digital signature over the whole record. Tamper-evident: change one character and the seal breaks. The tally stick's two matching halves, rebuilt.
The record's ID is the cryptographic fingerprint of its own contents (SHA-256 content hash). Not a serial number; not chosen by the issuer or anyone. Three consequences: nobody assigns IDs so nobody can manipulate them; tampering is self-evident because a changed record no longer matches its own ID; and cancellation lists become unambiguous — a listed fingerprint can refer to exactly one document in the universe. Corrections happen by visible cancel-and-reissue (cancellation reason: "superseded — corrected reissue"), never by editing. History is never silently rewritten.
7. Dates, and the memory rule. (Resolved: D4; extended: R3 seasoning) When issued, always prominent. Records are then treated asymmetrically, mirroring mature real-world credit systems:
8. The revocation pointer. The address, inside the record itself, where the issuer's cancellation list is published (Part III). The holder carries, within every record, the pointer to the noticeboard that could condemn it; removing the pointer breaks the seal.
A standing is built from many records from many issuers. The format is designed for bundles, not single certificates. No single issuer's vouch is meant to be sufficient; anti-fakery comes from plurality — a collusion ring must corrupt many named, staked, tracked issuers, not one.
The question: a verifier has never heard of "Riverside Traders Co-op." The seal is genuine — but what stops anyone inventing an issuer, signing their own records, and handing them out?
The answer: CC builds no issuer registry and appoints no gatekeeper. Instead, every issuer must declare an external identity anchor — an identifier issued by infrastructure that already exists in almost every jurisdiction — and the verifier checks it against that jurisdiction's own public system. The countries maintain their own registries; CC just points to them.
The anchor ladder (in approximate order of binding strength — a working set, to be tuned with the warm-seed community):
How verification works: the record declares the issuer's country and anchor. The verifier's software checks it against that jurisdiction's public lookup (ABN Lookup, GSTIN verification, and equivalents — already public, online, and free in most jurisdictions). Where no online lookup exists, the check is manual. Either way, CC is never in the loop.
Rules:
The principle at work: CC invents nothing. Business registries, tax systems, bank KYC, and mobile-money onboarding have already done the work of establishing that organisations exist and are accountable. CC borrows that existing infrastructure — the same pattern as holder identity (D1), sealing mathematics (R1), and wallets.
A verifier performs exactly two checks, automatically, in about a second:
Check 1 — Is it genuine? Verify the seal against the issuer's public key. Answered from the record itself, like a watermark. No phone call, no central query; no record contents leave the holder's device. (With R1, this check also confirms the record matches its own fingerprint ID.)
Check 2 — Is it still valid? (Resolved: D6 — the signed published list; extended: R2 freshness) The verifier's software reads the revocation pointer out of the record itself and checks the issuer's cancellation list: a small signed file, published at the issuer's own address, containing only record IDs and cancellation status — no personal data, no claim contents.
Properties of the cancellation list:
Continuous watching for ongoing reliance. (R3) Verification is a moment in time, but reliance often isn't. A verifier who extends a credit line, instalment terms, or repeat trade on the strength of a record should re-check the issuer's cancellation list at intervals matching their exposure — the lists are public precisely so this continuous watching is free and permissionless. The verifier's own software simply re-reads the public noticeboard on a schedule and alerts if a relied-upon record appears on it. This is not the issuer notifying the verifier (the issuer doesn't know the verifier exists) and not CC pushing anything (there is no centre) — it is the verifier's own tool re-reading a public file. Honest residue: post-cancellation alerts protect ongoing reliance; they cannot un-ship goods in a completed one-off transaction. That residual gap exists in every credit system on earth, and this standard does not pretend to abolish it. For one-shot decisions the protections are upstream: the freshness stamp, checking at the moment of decision, seasoning, and the issuer's track record.
Scope of Check 2 (what the list is and isn't): the cancellation list answers one narrow question — is this specific record still valid. It is not a news feed. New conduct, good or bad, enters the system as new records in the bundle, not as edits to old ones.
Why the answer cannot live on the holder's device: the record belongs to the person, on their device, and no one — issuer, CC, anyone — can write to it. The unavoidable flip side: a cancelled record still sits on a fraudster's phone looking perfect, its seal genuine (it genuinely was issued, like a cancelled passport still looks like a passport). Therefore the "still valid?" answer must live somewhere the holder does not control. That is the entire reason the cancellation list exists.
Degraded-check rules (honest edges, named not hidden):
Who may cancel a record: the issuer, or the holder. No one else.
Every cancellation is visible, reasoned, and windowed. CC has no silent deletions and no instant condemnations:
Anomaly detection and the yellow light. (D8) The mirror threat to a malicious issuer is a malicious mob: coordinated actors filing false disputes to destroy a legitimate issuer. Defences, in order:
Malice, priced not prevented (named honestly): no rule of this standard can stop a spiteful issuer cancelling a truthful vouch, or a determined mob attempting a coordinated attack. The defences are structural: reasons are permanent, disputes are holder-controlled and visible, abuse marks the abuser, patterns are detectable in public data, and plurality dilutes all damage — one spiteful cancellation dents a standing built on many records; it cannot erase it. The residue: a holder or issuer in their first year, with few records, is most exposed. This is the Maghribi trade-off accepted knowingly — the network self-polices because the network remembers.
Cross-issuer tampering is impossible by construction: an issuer can only sign — and therefore only cancel — its own records. No community can touch another's.
An implementation "supports Common Credo" only if it:
| # | Question | Resolution |
|---|---|---|
| D1 | Identity binding (holder) | Every record declares its identity anchor; verifiers price binding strength. Inclusion preserved, fraud priced. |
| D2 | Claim vocabulary | Short fixed core list all implementations must understand + marked regional extensions. The accordion. |
| D3 | Zero stake | Permitted only for declared issuer types making factual attestations; credit-judgement claims with zero stake are valid but flagged and priced near zero. |
| D4 | Memory | Positive records permanent; negative records lapse (5–7 yrs, regional) and are hidden, never deleted. CC never erases history — it dates, hides, and prices it. |
| D5 | Cancellation rights | Issuer or holder only. All cancellations visible, reasoned, disputable; they count against the issuer's own track record. Malice is priced and diluted, not prevented. |
| D6 | Where "still valid?" lives | Each issuer publishes its own small signed cancellation list at its own address; the record carries the pointer. No CC register, no centre, nothing to capture. Hosting delegable; signing never. |
| D7 | Issuer legitimacy | Issuers declare an existing external identity anchor (business registration, tax ID, co-op certificate, bank/mobile-money account, verified address — the anchor ladder), checked against each jurisdiction's own public registry. No CC registry, no gatekeeper. Informal issuers included at lower rungs, declared openly; verifiers set their own bar. New issuers build weight through public track record. |
| D8 | Disputes and holder protection | Dispute flag lives at an address only the holder controls — never on the issuer's list. 72-hour notification window before cancellations become visible. Structured public dispute reasons. Abuse marks the abuser, both directions (mutual destruction, Part 0). Continuous public-data anomaly detection (AI-assisted) with a yellow-light pause above threshold: pattern surfaced, never adjudicated. CC never judges. |
| R1 | Record identity | A record's ID is the SHA-256 content hash of its own contents. No assigned or serial IDs. Corrections by visible cancel-and-reissue, never by editing. |
| R2 | List from day one | Key generation and empty-list publication are one act; no list, no valid records. Lists carry a freshness stamp and are re-signed at least every 90 days; staleness is itself a signal. Silence and "all clear" mean different things. |
| R3 | Ongoing reliance and seasoning | Verifiers with ongoing exposure re-check cancellation lists at intervals matching that exposure (lists are public precisely to make watching free). Record age is a declared trust signal — fresh records carry higher residual cancellation risk; seasoned records have been tested by time. Verifiers set their own seasoning thresholds; the standard mandates no waiting period. |
v0.3 — 15 July 2026. Supersedes v0.2 (4 July 2026, retained). Companion to: Non-Technical Brief v2, Session Notes and Addendum, Foundations & Lineage, What We're Actually Building.
Common Credo · this page is generated from its Markdown source in the project by build-site.js.