Open Trust Commons · OTCS

How OTCS works

Five views of one process. Diagrams are drawn in plain HTML and CSS — no diagram runtime, no JavaScript, no external assets, the same rule that governs the relationship graph. The Mermaid source sits under each one if you want to render it elsewhere; docs/process.md in the repository is its source of truth.

1 · The system, end to end

A project describes itself, gets located in shared coordinates, accumulates evidence and relationships, and becomes findable by people who need what it does. Nothing is validated by the fact of being listed.

People and projects
Project registryotcs.yaml manifest — a public, attributable claim about itself
Coordinate mapactor · authority · action · environment · function · time · maturity
Evidence ledgerclaim by claim, never project by project
Relationship graphtyped edges, each carrying who asserted it and on what evidence
Coordinationoffers · needs · interfaces
Composition in the worldsignals → decisions → enforcement → receipts → repair
field evidence returns here — the only way maturity reaches the top of the scale
Mermaid source for this diagram
flowchart TD
    A["People and projects"] --> B["Project registry<br/>otcs.yaml manifest"]
    B --> C["Coordinate map<br/>actor · authority · action · environment<br/>function · time · maturity"]
    C --> D["Evidence ledger<br/>claim-by-claim states, maturity profile"]
    D --> E["Relationship graph<br/>typed edges, each with assertion status"]
    E --> F["Coordination<br/>offers · needs · interfaces"]
    F --> G["Composition in the world<br/>signals → decisions → enforcement → receipts → repair"]
    G -. "field evidence returns" .-> D

2 · Getting into the registry

Self-registration is the normal path. Two other doors exist, and both are visibly different from it — including the one where a project tells us not to create a page in its name (charter §10).

A project exists
who is writing the record?
The project itselfthe normal path
An OTCS maintainer, from public evidenceobserved — never presented as participation
Nobody — the project declinesDECLINE is honored; no page is created
Pull request adding registry/projects/<id>/
npm run validateschema · semantic rules · id consistency · dangling edges
fails → fix and resubmit, loop until clean
Maintainer merges
Ledger event: PROJECT_REGISTERED
Live record registeredexistence asserted — not endorsement, validation, interoperability, originality, or conformance
Mermaid source for this diagram
flowchart TD
    START(["A project exists"]) --> WHO{"Who is writing<br/>the record?"}

    WHO -- "the project itself" --> PR["Pull request adding<br/>registry/projects/&lt;id&gt;/otcs.yaml"]
    WHO -- "an OTCS maintainer,<br/>from public evidence" --> OBS["record_state: observed<br/>not project-controlled<br/>never shown as participation"]
    WHO -- "nobody — project declines" --> DECL["DECLINE honored<br/>no page is created"]

    PR --> VAL{"npm run validate"}
    VAL -- "schema error,<br/>semantic error,<br/>dangling edge" --> FIX["Fix and resubmit"]
    FIX --> VAL
    VAL -- "passes" --> MERGE["Maintainer merges"]
    MERGE --> EV["Ledger event:<br/>PROJECT_REGISTERED"]
    EV --> REG["record_state: registered<br/>maintainer-verified"]

    OBS --> EV
    REG --> LIVE(["Live record — a public,<br/>attributable claim about itself,<br/>and nothing more"])
    OBS --> LIVE

3 · How a claim earns its evidence state

Every claim moves on its own. A single project routinely holds claims in three different states at once; that is the expected condition, not an anomaly. Full rules: the evidence model.

SELF_ASSERTED DOCUMENTED REPRODUCIBLE independence test INDEPENDENTLY_TESTED FIELD_OBSERVED

Fail the independence test and the claim settles at DOCUMENTED rather than climbing. Any claim can move sideways to DISPUTED when a dispute record opens, or to RETRACTED when its claimant withdraws it — retraction removes the claim's force, never the record of it.

The independence test. An evaluator is not independent merely for being a separate legal entity. Any one of these and the evaluation lands at DOCUMENTED: shared founders · shared funders · advisory relationship · reciprocal review · employment · contractor status · code contribution · commercial dependency · substantial prior collaboration.

Mermaid source for this diagram
stateDiagram-v2
    [*] --> SELF_ASSERTED: project states it
    SELF_ASSERTED --> DOCUMENTED: a public artifact shows it
    DOCUMENTED --> REPRODUCIBLE: an outsider can re-derive it
    REPRODUCIBLE --> INDEPENDENTLY_TESTED: independence test passes
    INDEPENDENTLY_TESTED --> FIELD_OBSERVED: repeated real-world evidence

    REPRODUCIBLE --> DOCUMENTED: independence test FAILS
    SELF_ASSERTED --> DISPUTED: dispute record opened
    DOCUMENTED --> DISPUTED: dispute record opened
    REPRODUCIBLE --> DISPUTED: dispute record opened
    INDEPENDENTLY_TESTED --> DISPUTED: dispute record opened
    DISPUTED --> DOCUMENTED: resolved
    SELF_ASSERTED --> RETRACTED: withdrawn by claimant
    DOCUMENTED --> RETRACTED: withdrawn by claimant
    RETRACTED --> [*]

4 · How the shared system changes

Nothing changes by consensus, seniority, or volume. It changes by proposal, on a clock, through three separate questions — and then through a gate that asks whether the deliberation itself was real.

SEEDanyone, no standing required
DISCOVERYprior art, affected projects, risks, missing evidence
DRAFTconcrete change published — the clock starts here
DELIBERATIONobjections raised and answered, or carried as unresolved
TRIALimplementation or simulation; interfaces target two independent ones
Has the class minimum elapsed?no → wait. The clock binds the founder or it binds nobody.
Ballot A · Readinessspecified and evidenced enough to decide?
Ballot B · Ratificationshould this exact version pass?
Ballot C · Implementationwill your project actually implement it?
Process validity: A_g ≤ E_gthe vote count alone ratifies nothing
ALLOW → ratifythe environment supports the decision
SHAPE → revisescope or evidence too broad — back to deliberation
DEAUTOMATE → return to humansdeliberation was bypassed or overwhelmed
VETO → rejectcannot be legitimately supported
OPERATIONchange is active, ledger event recorded
REVIEWevery decision carries a review, expiry, or reaffirmation date → RENEWED or DEPRECATED

Clocks by consequence: typo 24–72h · registry update 3–7d · interface clarification 7–14d · new interface 21–30d · breaking change 30–45d · constitutional or model revision 45–90d · emergency immediate but auto-expiring in 7 days.

Why the gate matters. A proposal with 80% support is held, not ratified, if directly affected projects were absent, a serious objection went unanswered, notification failed, the fixed version changed mid-vote, or the participant set was organizationally concentrated. See it running: the proposals.

Mermaid source for this diagram
flowchart TD
    SEED["SEED — anyone, no standing required"] --> DISC["DISCOVERY — prior art, affected projects, risks"]
    DISC --> DRAFT["DRAFT — concrete change published<br/>⏱ clock starts here"]
    DRAFT --> DELIB["DELIBERATION — objections raised and answered"]
    DELIB --> TRIAL["TRIAL — implementation or simulation<br/>interfaces target two independent ones"]
    TRIAL --> CLOCK{"Has the class minimum<br/>elapsed?"}
    CLOCK -- "no" --> WAIT["Wait. The clock binds the founder<br/>or it binds nobody."]
    WAIT --> CLOCK
    CLOCK -- "yes" --> BALLOTS

    subgraph BALLOTS ["RATIFICATION — three ballots, not one"]
        BA["A · Readiness<br/>is it specified and evidenced enough to decide?"]
        BB["B · Ratification<br/>should this exact version pass?"]
        BC["C · Implementation<br/>will your project actually implement it?"]
    end

    BALLOTS --> GATE{"Process validity<br/>A_g ≤ E_g"}
    GATE -- "environment supports it" --> ALLOW["ALLOW — ratify"]
    GATE -- "scope or evidence too broad" --> SHAPE["SHAPE — revise"]
    GATE -- "deliberation bypassed or overwhelmed" --> DEAUT["DEAUTOMATE — back to human deliberation"]
    GATE -- "cannot be legitimately supported" --> VETO["VETO — reject"]

    SHAPE --> DELIB
    DEAUT --> DELIB
    ALLOW --> OP["OPERATION — change is active,<br/>ledger event recorded"]
    OP --> REV["REVIEW — every decision carries<br/>a review, expiry, or reaffirmation date"]
    REV --> RENEW["RENEWED"]
    REV --> DEP["DEPRECATED"]

5 · Declared facts vs computed interpretations

The separation that keeps a score from turning into a reputation.

Declaredmanifests · relationships · claims · ballots · receipts — authoritative, human-written, PR-reviewed
Generatorsrelationship graph · capability matrix · overlap O and complementarity Γ — deterministic
computed/every artifact stamped with algorithm version, input hashes, weights, timestamp — interpretation, never attribute

Both lanes render to the site; computed pages are labeled as interpretation. Every declared change emits an event into the append-only, hash-chained governance ledger.

Overlap says two projects occupy similar positions. It says nothing about copying — derivation needs chronology, documented access, distinctive terminology, structural correspondence, citations, and transmission paths. High overlap with no transmission evidence is independent convergence, which strengthens both records rather than diminishing either.

And the ledger's honest limit, stated wherever it appears: this is tamper-evident sequence integrity, not immutable evidence. The chain proves the committed records form a consistent sequence. It cannot prove that omitted events never existed, that timestamps are true, that the author held authority, or that any event's content is factually correct.

Mermaid source for this diagram
flowchart LR
    subgraph DECLARED ["Declared — authoritative, human-written, PR-reviewed"]
        M["manifests"]
        R["relationships"]
        C["claims"]
        B["ballots and receipts"]
    end

    subgraph GEN ["Generators — deterministic"]
        G1["relationship graph"]
        G2["capability matrix"]
        G3["overlap O · complementarity Γ"]
    end

    subgraph COMPUTED ["computed/ — interpretation, never attribute"]
        S["every artifact stamped:<br/>algorithm version · input hashes<br/>weights · timestamp"]
    end

    DECLARED --> GEN --> COMPUTED
    COMPUTED --> SITE["Site pages, labeled<br/>'computed interpretation, not fact'"]
    DECLARED --> SITE

    LEDGER[/"governance ledger<br/>append-only, hash-chained"/]
    DECLARED -. "every change emits an event" .-> LEDGER

A system that cannot show its own weakness in the same format it demands of everyone else is not a registry. It is a brochure.

Which is why KTP is registered as project #1 with a zero in its validation column, why OTCS scores itself on its own scale, why the unreachable rung is named on the capability matrix, and why the proposal adopting this registry is sitting unfinished with its clock still running.