Stage 2 of 8 · reached from a routed intake, not from the nav ← back to the intake it came from

Composition is something that happens to an intake once the matcher has routed it — it is not a place you visit. It had a top-level tab for one afternoon, which made it look like a standalone tool; the tab is gone and this is now the compose stage of a contract.

Why this is not a document picker. Composition used to start from a list of documents, which is why it felt administrative — you were choosing paperwork before knowing what you were trying to cause. It starts here from two things instead: a scenario (a real-world outcome, in your words) and a cast (the perspectives that must be satisfied). The documents are derived from the cast's demands, and every one of them can name which cast member forced it.

The cast comes from a grid rather than your imagination in the moment (era × stance, HRV-17) so it stays imaginable but not arbitrary — and simulating a stakeholder before asking the real one is the cheapest way to find out what a document actually owes.

1 The scenario required — a program with no outcome is a filing cabinet

or start from

2 The cast pick the perspectives that must be satisfied — the grid keeps it honest {{ cmpCastLine }}

{{ ca.k }} {{ ca.era }}

{{ ca.stance }} Demands: {{ ca.demand }}

3 The program, derived every row names the cast member who forced it — nothing here was picked from a menu {{ cmpProgLine }}

#	Document or service	Forced by	Because	Have it?
{{ pr.n }}	{{ pr.k }}	{{ pr.by }}	{{ pr.why }}	{{ pr.st }}

What the cast demands and nothing can supply {{ cmpGapLine }} A composition that hides this is the lie: the program would run, produce every document, and still fail the person who was never going to be satisfied. Each gap files as a Service creation request rather than being quietly dropped.

The cast, simulated — before anyone real is asked

{{ sm.k }} “{{ sm.v }}”

Simulated objections are evidence, never verdicts (R-026: events inform, never ground) — but a document that cannot answer a simulated billionaire will not survive a real one.

{{ chatRunKey }} {{ chatRunTitle }} {{ chatRunMeta }}

Context assembled for this run — read-only, ordered, and explicit about what was withheld

{{ m2.cardKind }} {{ m2.cardTitle }} {{ m2.cardLane }}

Design — the model is embedded, the canvas is ours the design app is hosted and cannot be mounted — what we get is the SDK plus a preview of the workspace file PARTLY A BUILD

Design seat: claude-design@concord · key ends 4f21

◈ clm v1 ▾

No second input. This transcript IS the platform’s conversation — one composer, below. Two chat boxes in one screen is the first thing that would make this unusable.

↻ {{ chatToolFile }} {{ chatToolPages }} 100% ⌖ Comment ✎ Edit Present ▾ ↗ Share

Live render — click any element to edit in place, drag to reorder

selected "Out of range" tile — copy, size and colour editable right here; still just a workspace edit

Embedded — Claude Code, unmodified repo, terminal, CI · you never have to look at this pane; it is here because nothing was taken away PR-ONLY KEY

concord/backend — RUN-17 seat: claude-code@concord · key ends 9b07

                        
                          {{ dl.t }}

CI — the judge

$ npm test — 214 passing · PR 119 open, awaiting your tap

The only thing you ever have to see from this pane is the green result and a Merge button — R-021, no code tool ever. The terminal stays outside the runtime permanently (R-019): a platform may not repair itself from inside.

Asks it must answer

{{ qkSel }} {{ qkSelEg }} {{ qkSelSt }}

{{ qkSelWhat }} Every answer is a transformer output, source-cited, never authoritative (To Do 10b) — the document behind it is what counts.

The governance tax, measured — To Do 10c {{ taxVerdict }}

Equivalent request Raw Governed Tax

Publish door {{ chatDoorCount }}

A workspace holds files; the record holds typed objects. So publishing is a translation, and the door is a form — the seat must declare what each change becomes (R-004: forms are the commit surface).

{{ d2.t }} {{ d2.lane }}

becomes{{ d2.becomes }} supersedes{{ d2.supersedes }}

Lane comes from the destination, never from reading the diff Guessing "is this law or styling" from a change is unreliable, so we don't. rulings/ and registers/ are gated because those paths are gated. pages/ is free. tests/ and kernel files are not writable at all — mounted read-only, so a barred edit fails at the filesystem rather than an hour later at publish.

Published 1 free change live and revertable · 2 gates now in My work · 1 never left the workspace. The workspace itself was never judged — only what crossed.

Workspace — {{ chatWsCount }}

Writable files are scratch: no gate, no tap, no receipt. RO files are mounted read-only, so a barred edit fails here and now rather than being discovered at publish. That single choice is what keeps refusals early instead of insulting. One container per live run is the real cost of this design — it is ordinary infra, but it is infra, and it idles out rather than living forever.

What Claude has in memory when it runs

The exact context of every fill and autopilot call — nothing more, nothing less.

Print the system

Choose the slice; the Binder service produces one print-formatted file.

Scope — pick as many as you want

Depth

Include

Output shape

Scope “Everything” is literal: contracts, documents, inputs, judgments, run logs, the gap log — and the back end (architecture documents, connector configs, the service registry). Output downloads as both PDF and zip.

Estimated: ~{{ prPages }} pages · {{ prCountLine }}

Skip anything — a skipped question means Claude decides and notes it in the document.

{{ qi.n }} · {{ qi.q }}

Population through each gate — width is how many got here, not how far along one thing is

{{ funnelNote }}

Solid = reached this gate · hatched red = stalled or terminated here.

{{ schedLine }} — grouped by cadence. Nothing here runs unowned: every row is a renewing contract with an owner, a clock and an output document.

{{ sg.label }} {{ sg.count }} next: {{ sg.due }}

{{ sr.name }} {{ sr.what }}

{{ sr.org }} · {{ sr.owner }} {{ sr.state }}

WP1 of the repair plan. Fourteen fixtures — one per lifecycle state, plus the three the old store could not express — and one violating fixture per invariant, because an invariant with no violating fixture is untested. Every assertion names the Sep 2 defect it would have caught. One the probe cannot answer reads UNVERIFIED, never PASS.

Intake rates — measured, not claimed

What the register would have to hold

Allocation — which agency owns this, computed

The door’s checks — halt or annotate, declared at registration

The two-reader contradiction — a stop, with its rate beside it

No arrival has contradicted yet. Zero across eleven runs is no evidence of a queue — not evidence of no queue.

Matcher account: {{ cx.matcher }} Resolver account: {{ cx.resolver }}

The escalation clock — fired, not claimed

Which fields are actually read

The trunk

Recommendation on record: {{ trunkRec }}

Id Verdict Assertion · what it catches · result

{{ row.name }} catches: {{ row.catches }} {{ row.detail }}

{{ g.state }} {{ g.n }} · {{ g.note }}

Did the constraint move, or did we just get busier

work in progress completed & accepted

{{ moveLine }}

Accepted counts acceptance records, not PASSes — a document that passed but was never accepted has not moved.

The endpoint is real; the eight-week shape is not. Nothing snapshots WIP or acceptances weekly, so the trend is illustrative and the current week is measured. Until weekly snapshots exist, read the sentence below the chart and ignore the slope.

Bars are stages one to eight; a filled bar carries the count of contracts sitting there.

FROZEN Claiming is stopped org-wide. Live envelopes may finish or abort; no agent may claim another contract and no spawn is permitted.

	Contract	Owner	Current stage	Days in stage	Start	End	Renewal	Last activity
{{ r.chevron }}	{{ r.name }} {{ r.count }} contracts {{ r.typeLine }}	{{ r.owner }}{{ r.claimed }}	{{ r.stageLabel }}	{{ r.days }}	{{ r.start }}	{{ r.end }}	{{ r.renewal }}	{{ r.activity }}	Remover auto-deploying…

The master contract

Concord alpha — master contract

Concord is itself a contract in Concord — a recurring contract under the Concord org, currently at Commit (Phase B). The documents below are its pages.

DocumentBack end — runtime, stores, model calls, connectors

The back end

The runtime behind the CLM. Same rule as the front: everything that does work is a service, every payload is a document or attachment, everything is judged. External systems never touch the core — they go through Connector deployments.

Browse it live: the wiki → 🔩 Backend — the engine room (7 layers · console · stack spec · surface map).

The layers

1 · ClientsThe CLM front end · chat (Claude runs the schedule in conversation) · email replies · webhook posts from outside. All of them can only do one thing: file or answer documents.

2 · API gatewayOne surface: create Request · fill document · submit to regulator · record your-call (Gap A) · read the tree. Auth per person; Claude is a caller like anyone.

3 · EnginesContract engine — the 8-stage state machine, one document at a time, gates enforced · Document engine — templates, fills, direct edits (Gap C deltas) · Judgment engine — derives judges from the regulator objective function, computes verdicts, writes judgment + required-changes documents · Objective function store — org, per-stage, regulator; revisions only by passed revision contracts.

4 · Model-call layerTwo call types with separated contexts: fill calls (one per document, drafts all fields + the one question) and judge calls (own context — never grades its own homework). Autopilot fans out parallel fill calls. Every call and response is logged as an attachment on the document it served.

5 · Event busEvery transition is an event: document.filled, judgment.pass/fail, stage.advanced, contract.stuck, twin.renewed, gap.recorded. Watchers subscribe (Deadline watcher, Calibrator); events replay idempotently.

6 · Connector layerThe only door to the outside. Each external system gets a Connector service deployment — a service with its own lifecycle, credentials scoped to it, syncs landing as documents/attachments, judged before they count.

7 · StoresContract tree (the one table) · document store (every version, failed attempts kept and marked) · attachment blobs (files, audio, video, links, artifacts) · gap/calibration log · registry (templates + deployments + runs).

Connector registry — the outside world

External system	Connector deployment	Direction	What syncs (always documents / attachments)	Trigger
E-signature (DocuSign)	Connector — signatures	out + in	documents out for signature; the signed yes back — it zeroes b(s)	document reaches its gate
Payments (Stripe)	Connector — payments	out + in	budget constants (C) verified; invoices and receipts as attachments	Perform-stage yeses convert
Calendar (Google)	Connector — schedule	out	stage deadlines and gate dates as events	Entry answer sets the deadline
Email / SMS	Connector — asks	out + in	Ask-service asks out; replies land as filled input documents	the Need plan spawns Ask services
Storage (Drive / S3)	Connector — attachments	out + in	uploads and produced artifacts (websites, datasets)	a service run outputs
Comms (Slack)	Connector — signals	out	gate waits, stuck flags, verdicts — into the channel	event bus subscriptions
Code (GitHub)	Connector — build	out + in	Builder outputs as PRs; merge = a yes recorded on the contract	Builder deployments run
Analytics	Connector — results	in	downstream outcomes for Gap B — did the passed thing deliver	scheduled pull, per contract

A minute on the event bus

t	Event	Consumers
09:00:01	request.filed (via email connector)	contract engine → new Pending
09:00:02	document.fill-called (Request document)	model-call layer
09:00:04	judgment.derived · judgment.pass 7/9	judgment engine → gate opens
09:00:04	gate.waiting (human signature)	Slack connector, My work
09:17:32	gap.recorded (you agreed)	calibration log
09:17:33	stage.advanced → Need	calendar connector, watchers

Invariants

External systems are reached only through Connector contracts — no engine ever calls out directly
Every inbound payload lands as a document or attachment and is judged before it counts
Inbound webhooks can only file Requests or answer documents — never mutate state
Secrets live on the connector deployment, never in documents
Events replay idempotently; the audit trail is the contract tree itself
Model calls: fill and judge contexts never mix

Document Improvement loop — expert panel, export, information integration →

Prototype Back-end console — live event bus, connectors, gate queue →

Prototype At scale — 5,000 contracts, 200 orgs, the loaded queue, the heat strip →

Canonical schema · one source of truth, zero structural debt

System schema

Nine entities, their relations, and the invariants. Every screen, intake file, and document template derives from this — nothing gets its own ad-hoc structure.

Entities

Entity	Fields	Notes
Org	name, launchContractId	A grouping born from a launch contract; not itself a contract (open question)
Contract	id, orgId, parentId?, type, ownerId, stage, start, end, renewal	Types: Organization (launch) · Service · Virtual twin · Constraint remover · Pending. parentId gives unlimited nesting
Stage	index 1–8, name, deadline	Request, Need, Strategy, Plan, Commit, Perform, Close & Archive. Deadline comes from the Entry document's duration answer
Document	id, contractId, stage, templateId, status, order	Statuses: unfilled → filled → submitted → judged. One at a time within a stage
Template	id, name, fields[]	Field types: short answer, paragraph, multiple choice, checkboxes, dropdown, scale, file upload. Fixed per stage
Input	id, documentId, kind, producedByServiceId, judgmentId	Kinds: document · upload · project (nested, unlimited) · contract. ALWAYS produced by a service, ALWAYS judged
Service	id, templateKind, deployedFor, madeById, contractId	Every service IS a contract. Two families: producers and judges. All trace to the Service maker (hand-made, t=0)
Judgment	id, judgingServiceId, subjectId, checks[], score, threshold, verdict, changes[]	A document. The judging service IS the regulator. FAIL also produces a required-changes document
Attachment	id, ownerId, kind, uri	Kinds: file, audio, image, video, link, artifact (website, dataset). Inputs or outputs

Relations (the chain)

Org ─ has many → Contract ─ has 8 → Stage ─ has 1..n → Document ─ has many → Input

Document → judged by → Judgment ← produced by ← Judging Service (a Contract)

Input → produced by → Service (a Contract) → judged by → Judgment … (recurses, unlimited)

Launch Contract (in Launcher Org) → births → Org → spawns 8 Twin Contracts at Strategy

Invariants

Every service traces to the Service maker; there is a service to make a service
Every document (and every input) carries its own regulator — an evidence document and a sensor document — before it counts
Moving to the next stage requires every stage document to pass
Work advances one item at a time — stage docs, project items, inputs
Humans gate stages; services do everything between gates
Anything that does work is a service; anything a service produces is a document or attachment
Nesting is unlimited, and always visible (table tree, outline, one scroll)

Sketch · unification

Combining the three objective functions into one

Org · stage · regulator — three candidate ways they become one function. Same net of yeses under all three.

What exists today — the three being combined, in full

Concord alpha · three functions, one net underneath

Objective functions

The common substance is the net of yeses — a company is a series of getting people to say yes, and product-market fit is that net, learned. Three functions stay distinct on top of it, pointered to each other, never merged. Any of them can trigger a new service — always by filing a Request, never directly. A core decision variable of each is select an existing service vs create a new one.

1 · The objective function

The whole thing. Input to every Request document — it lets Claude answer requests entirely, with reasons.

Mission: a human coordination explosion — autonomous, decentralized, mostly automated deployment of complex projects

Ranked priorities: (a) a really good contract · (b) a really good platform · (c) a really good go-to-market

Risk appetite: Balanced

Decision variables: selecting existing services or creating new ones (via a Request) · which contracts to advance · where to spend attention · simulated or real person — and WHICH person (the big one: every instrument, bench seat, and stewardship names its holder; a simulation is a choice with a bond, never a default)

Coefficients: initial clarity ×3 · uncorrelated bets ×2 · learning loop ×2 · cost ×0.5

Constants (C): the budget envelope · the 8-stage lifecycle · the regulator's standards

Goal: Maximize

2 · The stage objective functions

Per-stage projections — same net, local core variables. Each is an input to its stage's document.

Need — optimizes the right people and the right documents, deployed via services. Core variables: stakeholders identified (the nodes, whose yes matters) · documents identified (the edges, the asks connecting them) · prior documents & working notes gathered (the evidence the net learns from)

Perform — product-market fit as a neural net of yeses. Core variables: yeses obtained · which asks convert. Training rule: every no lowers the asking route's weight and raises the next-best route's — recorded in the required-changes document

Other stages — same pattern, projections to be filled as each stage's logic is extracted (one stage at a time, per the no-debt rule)

3 · The regulator objective function service creation only

The goal flips — a gate optimizes by refusing. Judging services derive from it; nothing is authored by hand.

Where this fires. Only when a new regulator is stood up for a new service — it is the master controller at service creation, not a per-stage or per-document artifact. A regulator on an individual document is not an objective function at all: it is an evidence document plus a sensor document, tied to what we need to know. See Plan 3.

Locally minimizes: false passes (bad documents getting through) and wasted rework (good documents failing on trivia)

Decision variables: which checks to run · pass threshold · evidence required · who can override

Constants (C): the 7 field types · the stage template floor · the human gate itself

Derived checks: initial clarity ×3 → "what is obviously missing" (3 of the score) · constants → "explicit dates" (2) · priorities → "named owners" (2) · uncorrelated bets → "independence" (1) · cost → "completeness" (1)

Computed threshold: Conservative 8/9 · Balanced 6/9 · Aggressive 4/9 — this org is Balanced, so 6 of 9

The duality: the same derivation writes the document templates — re-score the org function and every judge and template downstream re-derives

The three, one table

	Org	Stage (Need / Perform)	Regulator
Output variable — Z, f(x) the single score being optimized	mission progress — how much closer to the human coordination explosion (which yes to seek next; answers Request documents)	Need: how built the net is — people & documents identified, services triggered, the plan (who × documents) · Perform: conversion — yeses obtained per ask	gate quality — false passes plus wasted rework (the judgment score against the threshold)
Decision variables — x, y what can be adjusted	select vs create services (via Request) · which contracts advance · where attention goes	Need: which people to ask, which documents to deploy, which evidence to gather · Perform: which asks to run, which routes to re-weight	which checks to run · pass threshold · evidence required · who can override
Coefficients — a, b per-unit contribution	initial clarity ×3 · uncorrelated bets ×2 · learning loop ×2 · cost ×0.5 (constants C: budget, the 8 stages, the regulator's standards)	re-slicings of the org's weights, traced per term (constants inherited)	check weights: obviously-missing 3 · explicit dates 2 · named owners 2 · independence 1 · completeness 1 (constants: field types, template floor, the human gate)
Optimization operator minimize or maximize	Maximize	Maximize (locally)	Minimize — the flip; a gate optimizes by refusing

The unification — B × C × the table, as one function

maximize Z = w·x − b(s) over the net of yeses

The net is people (C): the nodes of x are named people — the register of whose yes matters (Oksana, Danilo, Claude, the counterparty, the twins) — and the edges are asks routed to them, each carried by a document, each deployed via a service. x's state is literally who has said yes so far.

w is the org function: the mission weights (clarity ×3, bets ×2, learning loop ×2, cost ×0.5). The stage functions are slices of w: layer k of the net reads the same Z through its own slice w_k — Need's slice weights nodes-and-edges terms, Perform's weights conversion terms. A "stage objective function" is w_k·x, nothing more.

b(s) is the missing signatures (B): s is the set of required yeses not yet given. Regulation IS validation by the right person: when the person whose yes governs a document signs it, that signature validates it outright — their yes zeroes its share of b. The mechanical checks (obviously-missing 3, explicit dates 2, named owners 2, independence 1, completeness 1) are not the judgment; they are the evidence that earns the signature — the proxy that runs before a human commits, so nobody is asked to sign something the checks would bounce. A document passes when its marginal Z is positive, and Z rises exactly when a named person says yes.

Learning closes the loop (C): a FAIL is the loss signal; the required-changes document is backprop — it re-weights w_k (which asks convert, which routes get retried). Re-score w at the org and every slice, every b, and every template downstream re-derives.

Anatomy	In the one function	Which old function it was
Output variable Z	w·x − b(s), read at any layer	all three — they were readouts of one score
Decision variables x	the net's nodes, edges, and asks	org: select/create · stage: who & which documents · regulator: which checks
Coefficients	w (and its slices w_k) + the check weights inside b	org coefficients · stage re-weightings · regulator check weights
Operator	one maximize — minimize lives inside b's sign	the regulator's "flip," absorbed
Validation	a named person's signed yes — it zeroes that document's share of b(s)	the regulator's judgment, returned to the human it always was

The three candidates it was combined from

A · One weight matrix

There is one function — goal(Σ wᵢ·xᵢ | C) — and the "three functions" are just columns of one weight matrix. A projection is a column; nothing else differs.

Term	Org	Need	Perform	Reg
initial clarity	×3	×5	×1	×3
yeses obtained	×2	×1	×5	×1
learning loop	×2	×2	×3	×2
cost	×0.5	×0.5	×1	×0.5
goal	max	max	max	min*

*the regulator column is the same column negated — a gate maximizes by refusing. Update one cell, everything downstream re-derives.

Wins: ultimate simplicity — one artifact to govern. Loses: the regulator's "flip" is a convention someone must remember.

B · Your own cost equation recommended

c(y) = wx + b(s) — already in your corpus. One function where the regulator isn't a separate function at all: it is the penalty term.

maximize w·x − b(s)

w·x — the org function: mission-anchored terms (x) times priorities (w). Stage functions are w re-sliced per stage: w_need picks out people-and-documents terms, w_perform picks out conversion terms.

b(s) — the regulator, as the built-in penalty: every failed check adds cost. "Minimize false passes" stops being a second function and becomes the shape of b.

One maximization. The gate is inside it. A document passes when its marginal w·x exceeds its b(s) — judgment becomes arithmetic.

Wins: truly one function; the regulator can never drift from the mission because it's a term of it. Loses: penalties need calibrating or everything passes.

C · The net is the function

Stop writing functions at all: the net of yeses IS the function, and the three are readouts at different layers.

Input layer
the org function — scores which yes to seek (Request)

Hidden layers
the stage functions — Need builds the nodes and edges; Perform runs the forward pass and trains the weights

Loss
the regulator — FAILs are the loss signal; required-changes documents are backprop

Nothing to unify because nothing was ever separate — you were reading one network from three angles.

Wins: matches the PMF-as-neural-net thesis exactly; learning is native. Loses: hardest to render as documents people sign.

Say A, B, or C — B can carry A's matrix as its w, and C as its training story, so they compose. The three today · Prototype

Controlled documents — the plan and the models it depends on

These were in the footer, which was wrong: the footer is for projections and services — things you use. A controlled document is something you read and change only by change request, and this page is where they live. Classification per the page register.

PMF is the clean case of your point: the PMF gate document is a service in the registry — that is the service. The page explaining the equation is a controlled document. Two different objects, and only one of them belonged in a nav bar.

The hardest part of generated work is not the first version — it is keeping intent and artifact from drifting apart after the tenth edit. In platform terms: a contract is the interface specification, a document is the payload, a service is the generator, the regulator is the validator. No contract, no generation.

Req	Failure mode	Here?	The requirement
{{ dr.id }}	{{ dr.mode }}	{{ dr.seen }}	{{ dr.req }}

Five of the nine anticipated problems were demonstrated by this system’s own audits — unmeasured figures presented as measured, verification testing the new thing and not the replaced one, features shipping unreachable, enumerations diverging from their renderers, and idempotency assumed but absent. That is the useful part: they are not borrowed worries, they are recorded defects.

Full section, the contract synthesizer pipeline and all 25 statements: §7c drift requirements →

The tracking contract. Every KPI gets four things or it is not tracked, it is asserted: a source event already recorded in the append-only log, a computation stated as arithmetic, a cadence, and a named silent failure mode — the way the number looks good while the thing it measures gets worse. No source event, no KPI.

KPI	Now	Source event	Fails silently by
{{ kt.k }}	{{ kt.now }}	{{ kt.src }}	{{ kt.fails }}

Three cannot be tracked yet and appear as gaps rather than numbers: self-consistency (asserted, no blind re-show mechanism — and it is the ceiling on every other figure), threshold stability (versions bump without recording the delta, so a settling system is indistinguishable from a tampered one), and review-minutes per deliverable (sessions are not timed, so the binding constraint has no unit cost).

Full derivation, cadences and the twelve source events: KPI tracking →

CA-IP-000 · v0.1 draft. No downstream section may be baselined ahead of this one. The plan governs any conflicting artifact, including documents generated inside the platform.

Scope of authority — nine controlled classes

Controlled	Not controlled	Who may change it
{{ pc.k }}	{{ pc.not }}	{{ pc.who }}

Reflexive clause. The objective functions are the reward function, so changing them changes the plan's own control target — handled as safety-critical configuration, never an edit, never by anyone whose work that function scores.

Four review gates, each with a hold criterion

Held if {{ pg.hold }}

Controlled vocabulary — the term, the forbidden synonym, the failure it prevents

Term	Not	Failure it prevents
{{ pv.k }}	{{ pv.not }}	{{ pv.why }}

The mission, verbatim

A human coordination explosion — human general intelligence, defined as a general state of vertical growth in the deployment of complex projects in which deployment and management is autonomous, decentralized and mostly automated.

Danilo and Oksana signed a contract whose output is HGI; the coordination explosion is the mission; Concord is the system hosting that contract. Any section treating Concord itself as the mission is defective.

Ranked priorities and appetite

Phase context

Actor register — position, what they may do, the single crossing mechanism

Actor	Position	May do	Crosses by
{{ pa.k }}	{{ pa.pos }}	{{ pa.may }}	{{ pa.via }}

Assumptions — each with an owner and an invalidation trigger

{{ pas.k }} — {{ pas.t }}

Owner: {{ pas.owner }} · Invalidated when: {{ pas.trigger }}

An assumption without a trigger is a belief, and beliefs do not belong in a controlled plan.

Concord · feature requirements · sketch

Print the system

Convert any selected slice of Concord — front end to back end — into one printer-heavy file. The whole system is documents already; printing is just choosing which ones and binding them.

What it is

A Print action available everywhere: on a contract, an org, a selection in the table, or the whole system
Output is one continuous file, print-formatted: cover page, table of contents, page numbers, section per contract — no app chrome, no buttons, black on white
It is itself a service: printing deploys the Binder service (a producer service); the produced file lands as an attachment on whatever was printed

Selection — because thousands of contracts

Scope picker: this contract · this contract + its children · this org · checked rows in the table · everything
Depth picker (mirrors the one-scroll toggle): outputs only · outputs + inputs · everything (judgments, run logs, regulator objective functions)
Include/exclude toggles: full contract prose · attachments list · failed attempts · gap log entries · the back end (architecture docs, connector configs) · the front-end screens as figures
A live page estimate updates as you select ("~46 pages") — the honesty meter that replaces printing 5,000 contracts by accident
Selections are saveable as named print sets ("Board packet", "Helios audit") — a print set is a document, so it can be judged and reused

Format rules

Cover: what was printed, by whom, the sim date, the selection recipe (so the print is reproducible)
Table of contents: one line per contract — name, org, stage, verdict trail
Per contract: header block (owner, dates, budget committed/spent), then its documents in stage order, filled blanks underlined, each judgment boxed after its document
12pt minimum, generous margins, page break before every contract, nothing clickable rendered
Failed attempts print greyed with a FAILED stamp — kept, as everywhere in the system

Open questions

Does a print of a contract require its regulator's pass first, or can you print work in flight?
Signatures on paper — print a signing page per gate so the paper copy can be counter-signed and scanned back in (the DocuSign connector in reverse)?
Is the page estimate computed exactly (render then count) or heuristically (rows × averages)?

Moved, not deleted. This page carried a second full copy of the System Architecture — the same words as the wiki’s copy, maintained in two places. Two copies of an architecture is how the two quietly disagree, so the wiki’s copy is now the single authority and this one is a pointer.

It is §4 of the plan of record: ten sections, its own §0 a V-model, undecided material kept separately on Open questions.

Standalone copy ↗

Concord alpha · three functions, one net underneath

Objective functions

1 · The objective function

The whole thing. Input to every Request document — it lets Claude answer requests entirely, with reasons.

Mission: a human coordination explosion — autonomous, decentralized, mostly automated deployment of complex projects

Ranked priorities: (a) a really good contract · (b) a really good platform · (c) a really good go-to-market

Risk appetite: Balanced

Coefficients: initial clarity ×3 · uncorrelated bets ×2 · learning loop ×2 · cost ×0.5

Constants (C): the budget envelope · the 8-stage lifecycle · the regulator's standards

Goal: Maximize

2 · The stage objective functions

Per-stage projections — same net, local core variables. Each is an input to its stage's document.

Other stages — same pattern, projections to be filled as each stage's logic is extracted (one stage at a time, per the no-debt rule)

3 · The regulator objective function service creation only

The goal flips — a gate optimizes by refusing. Judging services derive from it; nothing is authored by hand.

Locally minimizes: false passes (bad documents getting through) and wasted rework (good documents failing on trivia)

Decision variables: which checks to run · pass threshold · evidence required · who can override

Constants (C): the 7 field types · the stage template floor · the human gate itself

Computed threshold: Conservative 8/9 · Balanced 6/9 · Aggressive 4/9 — this org is Balanced, so 6 of 9

The duality: the same derivation writes the document templates — re-score the org function and every judge and template downstream re-derives

Concord alpha · genuinely unresolved

Open questions

Everything already answered lives in the System Architecture. This is only what's still open.

Deadline splitting — parent gets one week, children split the budget (decided) — but by what rule: evenly, by stage estimates, or by the objective function?
Who owns at filing — the owner picks assignments, but who owns a contract the instant it's filed (filer, or unassigned)?
Eager vs lazy capability creation — should Strategy pre-plan the services a contract will need (eager, no mid-run pauses), or should misses be discovered on the fly and the run pause while the service is made (lazy, built in the demo)? And does a pause share the parent's deadline budget or get its own?
The always-on question loop — the human is happy to answer questions all day; how does the system exploit that as its main training signal for general intuition? Candidates: a standing question queue the system keeps full (every gap, skipped field, and low-confidence draft becomes a question) · questions ranked by expected calibration gain, not arrival order · every answer written back as a document so it retrains the objective functions and Fill-in service · a cadence questionnaire (the pop-up) that fires whenever the queue crosses N. The interesting design problem: making answering feel like play, not review.
Information integration as an optimization target — how do the objective functions get updated so they also optimize for measuring information integration (how much the net's parts actually inform each other, not just how many yeses accumulate)? What would the variable be, who re-scores it, and does it live in the org function or every projection?

Working draft · Aug 24, 2026

Contract lifecycle view — requirements

System context (as given)

Mission: a human coordination explosion. Danilo Vicioso and Oksana Diu signed a contract to build a smart contract platform whose output would be human general intelligence — defined as a general state of vertical growth in the deployment of complex projects in which deployment and management is autonomous, decentralized and mostly automated.

The project divides into three parts: (a) building a really good contract, (b) building a really good platform, (c) building a really good go-to-market. Starting with (a), NASA's four-phase lifecycle framework was used. Phase A produced the initial concept for Concord: a system (not a platform) that hosts the really good contract — both a master contract and a template — with a run-time environment.

This document represents Phase B and specifies an MVP, the Concord alpha, that recursively bootstraps itself to write the Phase C final design before advancing to Phase D system assembly, testing and launch.

Concord alpha is (a) a generative contract lifecycle management platform run on (b) a document-based programming language (c) organized as a decentralized autonomous organization of organizations.

Assumptions: Phase B includes both completing this document and deploying the MVP · this document will be re-written and may change · it is written strictly for Phase B deployment, not future-state ideation · a successful MVP makes (b) and (c) recursively solvable · Phases C and D may be skippable [tbu].

Goal

A single portfolio view of all contracts as a table, each row showing where the contract sits in an 8-stage lifecycle. Must stay usable at thousands of contracts.

Lifecycle stages (8)

Request
Need
Strategy
Plan
Commit
Perform
Close
Archive

Table columns (must have)

Contract name
Owner
Current stage (named, e.g. "4 · Negotiation")
Stage progress bar — 8 segments, filled to current stage
Days in current stage
Renewal / expiry date
Last activity

Actions (must have)

Filter the table by stage
Advance a contract to the next stage directly from its row

Scale

Thousands of contracts — needs pagination or virtual scrolling
Stage filter must narrow the set fast; counts per stage shown on the filter

Intake

No separate intake screen — every contract starts at stage 1 · Request. The Request document asks (multiple choice) what is being requested:

Make a new service
Launch a new organization
Make a new virtual twin

Passing the Request stage sets the contract's type from that choice.

A launch contract births the organization; when it reaches the Strategy stage, about 8 virtual twin contracts spawn off under the new org.

Launch contracts live under the Launcher Org — one org whose only job is launching other orgs; otherwise nothing special.

Documents & services

Every output document is a template, instantiated via a service
Main service: "Fill in this document" — Claude fills out the template
When Claude lacks information, the service asks the user questions and resumes with their answers

Contract document view

Per contract: a single-document view showing all its pages in one place
Includes the services attached to the contract, not just the filled documents

Regulator

Submitting a document at any CLM stage triggers a regulator (UI treatment TBD — maybe not a pop-up)
The regulator's job: figure out which judging service to produce for that document
The produced service then judges the submitted document
Advancing to the next stage requires passing the regulator
A stage produces multiple documents — the Need stage produces ~8–10
The first Need document is the Entry document: it asks whether we have what's needed to enter the stage, plus a few other checks
Producing an output document requires producing its input documents first

Out of scope (for now)

Search, column sorting, export
Contract detail page (click-through)
Counterparty, value, and risk columns

Round 2 requirements

Easy back button on every screen (built)
If a contract hasn't advanced to its proper stage by a certain time, a constraint remover contract is deployed to remove the blocker (built: stuck >14 days in a stage → Deploy remover in the table)
An input is ALWAYS produced by a service — every input runs as a service with a live run log; services can do real work, e.g. produce a website (built)
Uploads (files, audio, images, video, links) can be inputs or outputs (built)
Input documents can be projects with nested documents — arbitrarily deep, breadcrumb tree — always tied to a specific service (built)
Inputs can sometimes be contracts themselves — a spawned mini contract that must reach Close before it counts (built)
Question types beyond fill-in-the-blank: short answer, paragraph, multiple choice, checkboxes, dropdown, linear scale, file upload (built: Need statement showcases all)
The regulator's inputs are produced by the user too, and judging blocks until they exist (built)
Each document should list WHICH regulator it is being submitted to
Claude itself is a capability, not a service — "Fill in this document" IS a service (the Fill-in service, a Document filler that uses Claude), like a Builder using a site generator
Project inputs advance one item at a time — no parallel production (built)

Round 3 — bootstrap & system design

Bootstrap: one plain service — the Service maker — exists from the start; every other service is made through a service (nothing fancy, it's just there) (built: seeded in the Launcher Org)
Automation: humans approve every stage gate; services do everything between gates. The regulator pass is one type of human gate (matches current flow)
Service types: document fillers, regulator/judging makers, builders (websites, datasets, artifacts), watchers (deadlines/constraints), connectors (external systems), twin-maintainers, launchers
One universal launch contract — no launch templates
Document templates are fixed per stage
Orgs need no home beyond the contracts table grouped by org
Three extra views, as tabs on home: regulator queue, my-work inbox, service registry (built)

Round 4 — audit resolutions

The judging service IS the regulator — there is no entity above it
The regulator's inputs are produced by a service, not by the person who filled the document
Stage documents advance one at a time, like project items (built)
A stage's deadline comes from the Entry document's expected-duration answer
The 8 twins operate as sub-orgs of the parent org — deployed and renewing; they auto-renew at Renewal
Service outputs live in an Attachments section on each document
Archive is a real stage with documents, not a terminal state
Input-contract nesting is unlimited
New requests staying under a "New requests" group is fine
First-time service creation: the Service maker checks the registry by capability first; only a miss creates new (decided by default — twice skipped)
No back door for services: even asking Claude to add a new service must go through the form — the Request document and its lifecycle. Claude can fill the request, but cannot mint a service directly
The Request document has an Objective function service as its input — it scores what the org should want next, so Claude can answer the whole Request document (including "why now") without asking
Input documents CAN be regulated — 100%: an input is submitted to a regulator like any document; its judging service is auto-produced (built)
Big-contract navigation: collapsible outline tree in a left rail, pages on the right; the same view serves in-flight contracts with future stages greyed; the outline includes stage documents, inputs, judgments, run logs, attachments, and nested project docs (built)

Round 5 — intake file set (what we design to gather your data)

The expert for this is an information architect / ontologist — someone who defines the canonical schema once so every file, screen, and document derives from it and no structural debt accrues. The schema lives in Schema; these eight intake files are its instruments:

Org charter intake — org name, purpose, founders, owners → seeds the launch contract
People & roles roster — who can own, fill, approve → answers the assignment question
Service catalog worksheet — existing capabilities: name, kind, what it produces → seeds the registry
Document template workbook — per stage, the actual questions and field types
Judging standards sheet — per document: checks, pass threshold, override → seeds judging specs
Deadlines & cadence sheet — stage durations, renewal rules, stuck thresholds
Asset inventory — files, audio, links that become upload inputs
Twin definition sheet — the ~8 twins: what each mirrors, renewal terms

Round 5 — full system audit

Invariants that HOLD: everything traceable to the Service maker · every document carries regulator + inputs + attachments (variant C) · regulator pass gates every stage · inputs are service-produced and themselves regulated · one-at-a-time everywhere · unlimited nesting shown in table and outline.

Should an org itself be a contract, or is the launch contract enough to represent it?
Should auto-produced judging services run a real lifecycle, or be born straight into Perform?
Should evidence extracts become contracts so the Evidence extractor service has real deployments — or stay documents only?
When a request becomes a Service or Twin, which org should it move to — and who decides?
Should the stuck threshold now be wired to the Entry document's expected-duration answer, per Round 4?
When a constraint remover reaches Close, what exactly should happen to its stuck parent — auto-advance, unlock, or a human decision?
Where should service outputs (websites, datasets, files) actually be stored and viewed — build a real attachments store?
Should twin auto-renewal be modeled now (twins ticking through Renewal on their own), or left as a rule on paper?
Should My work also list regulator-input production (judging specs, evidence extracts) as tasks?
Should each passed document store its real judgment (score, checks, changes) instead of showing canned PASS details?

Gap decisions (built): after its launch contract reaches Close, an org gets a continuous Renewal contract — same 8 stages, repeating, living under the org itself; stage deadlines come from the Entry document's duration answer; evidence extracts spawn contracts; a real attachments store (per document + contract-level line); twins and Renewal contracts auto-renew, looping from Archive back to stage 1; My work lists regulator-input tasks. Twin requests always tie to their parent org. Constraint remover at Close: done means done — the removal is the work.

Where things live now

This page is the working history (rounds 1–5). The settled state is consolidated in the System Architecture; everything genuinely unresolved lives in Open questions; the canonical data model in Schema.

Canonical schema · one source of truth, zero structural debt

System schema

Nine entities, their relations, and the invariants. Every screen, intake file, and document template derives from this — nothing gets its own ad-hoc structure.

Entities

Entity	Fields	Notes
Org	name, launchContractId	A grouping born from a launch contract; not itself a contract (open question)
Contract	id, orgId, parentId?, type, ownerId, stage, start, end, renewal	Types: Organization (launch) · Service · Virtual twin · Constraint remover · Pending. parentId gives unlimited nesting
Stage	index 1–8, name, deadline	Request, Need, Strategy, Plan, Commit, Perform, Close & Archive. Deadline comes from the Entry document's duration answer
Document	id, contractId, stage, templateId, status, order	Statuses: unfilled → filled → submitted → judged. One at a time within a stage
Template	id, name, fields[]	Field types: short answer, paragraph, multiple choice, checkboxes, dropdown, scale, file upload. Fixed per stage
Input	id, documentId, kind, producedByServiceId, judgmentId	Kinds: document · upload · project (nested, unlimited) · contract. ALWAYS produced by a service, ALWAYS judged
Service	id, templateKind, deployedFor, madeById, contractId	Every service IS a contract. Two families: producers and judges. All trace to the Service maker (hand-made, t=0)
Judgment	id, judgingServiceId, subjectId, checks[], score, threshold, verdict, changes[]	A document. The judging service IS the regulator. FAIL also produces a required-changes document
Attachment	id, ownerId, kind, uri	Kinds: file, audio, image, video, link, artifact (website, dataset). Inputs or outputs

Relations (the chain)

Org ─ has many → Contract ─ has 8 → Stage ─ has 1..n → Document ─ has many → Input

Document → judged by → Judgment ← produced by ← Judging Service (a Contract)

Input → produced by → Service (a Contract) → judged by → Judgment … (recurses, unlimited)

Launch Contract (in Launcher Org) → births → Org → spawns 8 Twin Contracts at Strategy

Invariants

Every service traces to the Service maker; there is a service to make a service
Every document (and every input) carries its own regulator — an evidence document and a sensor document — before it counts
Moving to the next stage requires every stage document to pass
Work advances one item at a time — stage docs, project items, inputs
Humans gate stages; services do everything between gates
Anything that does work is a service; anything a service produces is a document or attachment
Nesting is unlimited, and always visible (table tree, outline, one scroll)

Intuition — dump anything, anytime

{{ intCount }} waiting

Each entry is a document in the intake inbox — editing here edits that inbox document only, never a contract's blanks (those you edit in the deck/zoom). Integration re-reads the current text.

Dispositions — nothing vanishes: filed opens its contract, returned carries its reason

The objective function — an editable document, {{ ofVersion }}

Edited here, at the top view. Saving bumps the version and logs the revision; every judge and template downstream re-derives (the duality). The regulator objective function is a projection of this one — its threshold is the last field.

Linked as input to — org function

Linked as derivation to — regulator function

The whole system as a state table — with a requisite-variety read

Ashby check (requisite variety): {{ ashbyLine }}

Upper logic — when the regulators are missing the point

Files an escalation above the regulators: an objective-function revision request that re-derives every check downstream. The spank, as a document.

Controlled full org run — one step at a time, no chat

one store, two speeds: pass-calls at the feed; a Fail earns the desk's four questions (check added, threshold moved)

⚠ SEEDED DATA: this feed's cards and the gap log (Gaps A–D) are illustrative — no measured gaps exist yet. The only real calibration number is the κ on the Real Loop page, derived from ledger entries (and it says NOISE until n≥20).

THE metric — contracts completed end-to-end

KPI	Value	What it means
{{ kg.name }}
{{ ki.k }}	{{ ki.v }}	{{ ki.note }}

Unit economics — cost per contract, contracts per hour

derived from run receipts · the Charge primitive

The launch list — full gate & service maturity map →

Dump intuition here — the way you'd tell it to a person

Every entry becomes a document. Information integration reads them with the gap log and the system's own capability registry, reverse-engineers what you mean, and concludes what it can and cannot do itself.

Drop an image…

Inbox — {{ intCount }} entries, each a document

Fork receipts — one primitive, two joins (AND = triage · OR = variants); see the wiki's Fork × Join relation

{{ fk.id }} · {{ fk.kind }} · {{ fk.line }}

Information integration — what the system concluded

→ Documents · a registry view, not a place of its own — the ledger IS the storage

Regulation ledger — every document, its sensor and its judgment, in one place

Sensors: every one derived ✓ retroactively — stated once here; a row would only show a sensor if it deviated. Awaiting judgments run on the next day-tick, in queue order.

⚑ illegible title — rename via change request (LINT)

Contract / document

State

Read

one store, three views — the transaction register and the backlog read the same ledger these events write

Pair typeSubjectStateClock

The self-audit law, rendered: every pair carries a clock; open past its clock = an exception, automatically. Overdue rows sort first.

Backlog — everything asked for, with where it came from

{{ bi.origin }} {{ bi.by }} · {{ bi.at }}

Nothing recorded yet. Every Advance, Verdict, Submission, Lifecycle change, Retry strategy and Retry writes a row here — the log is the record, and it is append-only (R4).

Kind	What happened	Actor	When
{{ lr.kind }}	{{ lr.t }}{{ lr.tx }}	{{ lr.by }}	{{ lr.at }}

Concordpedia the encyclopedia the software obeys literally

§0 · Document control & authority §1 · Scope, mission & boundary §2 · Operational concept §3 · Requirements baseline §4 · System architecture §5 · Seats, agencies & authority §6 · Interface control §7 · Lifecycle & controls §8 · Human–machine interface §9 · Verification & validation §10 · Risk & FMEA §11 · Configuration & release §12 · WBS, schedule, critical path §13 · Appendices & evidence

📚 The Lexicon {{ wk.secLabel1 }}

Contract Clause Document Blank Edition Address Stage Route Gate Refuse-at-write Verdict Standing Ledger Semantic entropy Agent Exception Ruling Political Twin peaking

Service × Registry Service × Agency Judge × Standard Sensor × Verdict Machine × Ruling Document × Command View × Ledger Seat × Attention Agent × Authority Word × Law Contract × Edition Cost × Work Basis × Derived Fork × Join Law × Tier Policy × Number Gate × Control mode Seat × Deputy Comment × Gate Service × Standing Section × Authority Document × Section Requirement × EV Capability × Disposition Verification × Validation

Global Risk Mandate Indemnification Liability caps Insurance requirements Term / termination Vendor MSA

Route Ceremony Waiting-on-you view Refused view View Principal Deliverable Sub-document Input document Charter Utility Order Lens Layer Legend Records Author Lifecycle Signature Rendering order Production order Generation lens Regulation lens

⚖ The Registers Law register — what binds Policy register — the numbers Policy — the concept Page register 🔭 Views Map — how articles connect System health Library — what each page holds 🗄 Superseded The Archive — hearings, harvests, prior editions

PRO-1 · Promote-then-archive (the entropy pump, as law — not a housekeeping habit)

Contested meaning enters as a docket or trial — many readings, no owner. High entropy is legal only here.

A sitting rules — one meaning, one owner, filed on the record.

Rulings promote into the wiki — terms to the frozen core, edges to the relational web, adoptions to DEF nodes, policies to the governance shelf. Promotion is owed by the Substrate curation contract (Q4 ruling), never by whoever ran the sitting.

The spent record archives — the argument becomes evidence. Law is cited from the wiki only; citing an archived docket as law is a refusable write.

The closing condition: a docket may not archive while it carries unpromoted rulings; open questions never archive — they carry forward to the next sitting. Enters the Substrate curation charter as its first standing condition.

Promotion ledger (every archived record, and what it left behind in the wiki)

RecordWhat promotedLives now in Nailing Docket20 decided terms + 10 flow rulingsfrozen core Relation Matrix25 ruled edges among the 18 system nounsrelational web (L4) Stress Dockets40 findings — fixes absorbed into standards, ConOps, and the exception disciplinestandards + ConOps Requirements on Trialadoptions incl. the equation thesis, layer ladder + omission rule, transformers, operator algebra; conflicts refiled as docket questionsDEF nodes Requirement Sketchesbuildability proof for the Round-4 adoptionswork surfaces Doc VisionsDOC VISION as a registered evaluation class (population × protocol × dials)service classes Platform Analysesadopt/refuse ledger — ClickUp · Good Stuff SRSarchitecture GP-001 + GeneratorsGenerator Plan filed + all six generators RUNNING Aug 31 — sweeper (real clocks), meter (every live call priced vs envelope, refusal binding), gap recorder (Gap A + C to ledger), press (sealed editions), bus (real pings), scanner (live drift scan over the wiki source). Law: every surface a query over filed events.live organ Ruling — Clarification FormBP-001 §5.2, filed Aug 31: the Clarification Form derives from the reading BY RULE — its answers are the routing record's projections, so a live re-draft would launder derived values into authored ones. Not a coverage gap; closed.promotion ledger The Aug 31 sittingR-001..021 signed/adopted (Rulings Register) · closure plan CLOSED same day: 18/21 enforced — clock canon unified in code · My Work front door · recipes registered · EV chart ed.3 (8 floors) · ACC-STD-001 on the shelf · KCW-01..08 · fork primitive + no-implicit-merge in both twins · gate modal + ask box live · W5 handoff readyrulings · standards · runtime BP-001Bench Plan filed Aug 31 — seven phases, each closing one named expert objection (fork-proof ledger → source-of-truth inversion → signed custody → judge independence → instrumentation → coverage → Q10 law → handoff), each with a countable done test and a kill conditiongovernance shelf The Real Loopfirst genuinely derived runs — live fill + sealed judge (2 model calls), hash-chained append-only ledger on disk, replay verification, fixity digests; P1 · P2 · P5 · P6 · P8 of DMF-001 as running code at prototype scalelive organ DMF-001Data Management Framework filed Aug 31 — eight data laws consolidated from running organs (nothing new claimed); two exhibits kept honest (encryption, disaster replays); retention filed as Q10 on the docketgovernance shelf Taxonomy + Ontology webSystem Taxonomy Registry (type ladder, root: Substrate Entity) + ontology web view — promoted Aug 31 into the wiki nav; pages remain shelf-hosted, governance unchangedwiki nav (GUD check) Aug 30 Docket5 rulings: "political" TDR-088 + POL-001 · Substrate curation charter · composition EV law · universal ownership · Q7 closed. Q1 (held), Q2, Q8, Q9 carry forwardlaw shelf — filed Aug 31

All records readable on the Archive — Trials & Dockets shelf; the stress bench is also mounted live in this wiki. This ledger is the wiki-side receipt — one row per archival, appended by the Substrate curation contract at each promote-then-archive close.

The global library — the shared body of meaning; the registry points, the library contains. Contracts pull at pinned editions; supersession fires the staleness watcher.

One library, many shelves: each service's registry row carries a 📚 shelf — a saved query over these collections (its spec, templates, standards, EVs, golden calls, at pinned editions), never a copy. Expand any service under Services to see its shelf.

CollectionEditionWhat it holdsStewardPinned by

⚠ ASSERTED: the edition numbers (ed.1–ed.5) and every count in the Pinned-by column (5,012 runs · 61 agencies · 23 personas · 48 services…) are authored, not derived — no edition history or pin registry exists to compute them. The EV row's census (16) is the only derived count here. Same law as the retired "222."

The law: nothing enters unsealed (term register + TDR log govern admission) · everything is served at editions — a contract binds ed.N at Need and is judged against it to term · a new edition never re-binds silently; the staleness watcher offers, the owner amends or waives. Backed by 07_stores/global_library/.

The backend

One page, one truth — consolidated Aug 31. Five parts, in order: the architecture of record (L1–L5 below, live-mounted) · the running engine (backend console — every organ pokeable) · the repo (backend/ — README, SQL, server, CI; proven executable at the repo test run) · the decisions & plans (DEC-01..19, T0–T5, B0–B5) · history (collapsed at the bottom: the old 7-layer tree, the old console, the graph/SHACL stack spec — the graph spec re-reads as requirements on DEC-11's read-models and the meaning-hook write gate, an open call, not a second truth). Standing rules (reading surfaces per store · LAW-MIG-001 machinery pins · DESIGN MODE until GO-LIVE) carry over unchanged.

The 7-layer physical layout and the live event bus, as wiki articles like everything else. Tiers on each file say which kind of window shows it: user surface · admin surface · headless (events only). Stores obey the content stack (📜 Doctrine in the sidebar): the vault holds versions of meaning; the blob store holds artifacts (bytes labeled doc@version + fixity hash). Everything lives here: the stack spec, the 7 layers, the live console, and the surface→backend map. The substrate’s own admin view is the Substrate Console. Standing rule (filed Aug 31): every store and register here must name its reading surface — a store without one is a filed gap, not a shrug. The event bus’s surface is the Event log; the transaction register’s is the same page, pairs view. LAW-MIG-001: every store here carries a machinery version pin; post-GO-LIVE, shape changes only by migration bill (sandbox replay, 100% clean, rollback kept warm) — until then the platform is in declared DESIGN MODE.

The architecture of record — L1–L5, solid + placeholders

History — the 7-layer tree (superseded Aug 31)

History — the old event-bus console (superseded by the live backend console)

The stack spec — semantic-entropy requirements (re-read onto DEC-11 + the meaning hook)

Architecture · four components, each mapped to the surface it powers

The backend that prevents semantic entropy

1 — Storage substrate (native graph database)

powers: concept profile · relational web

Stack: native graph database (Neo4j / AWS Neptune) + RDF triple store on W3C standards (OWL for the ontology, SHACL for shapes).

(:ClauseType {id:'DEF-IND-004', name:'Indemnification'})
  -[:IMPACTS {consequence:'invalidates §12'}]-> (:ClauseType {name:'Insurance requirements'})
  <-[:CONSTRAINS]- (:ClauseType {name:'Liability caps'})

Rows and columns can't hold meaning; nodes and edges are the meaning. The relational paths are physical laws of storage — the invalidates edge between Indemnification and Insurance is enforced by the engine itself, never by app-side Python that can be bypassed. A semantically neutral warehouse (Snowflake-class) in this slot collapses the whole design. When a steward draws a line in the relational web, the backend physically alters graph topology in real time — the UI edit IS a schema edit.

2 — Enforcement engine (SHACL schema validator)

powers: ingestion gate · refused-at-write

Stack: graph validation engine running SHACL (Shapes Constraint Language) — Grady's "sovereign legislation" as executable shapes.

clm:IndemnificationShape a sh:NodeShape ;
  sh:property [ sh:path clm:cap ; sh:minCount 1 ; sh:datatype xsd:decimal ] ;
  sh:property [ sh:path clm:triggerEvent ; sh:in (clm:TriggerList) ] .
# write #4423 → sh:Violation → transaction REJECTED, state error to front end

Validation runs mathematically against the graph BEFORE any write commits. A failing shape means the database physically rejects the transaction — the constitutional "no representation exists for this state" on the front end is this engine's state error.

3 — Metabolism layer (event stream)

powers: live feed · "last metabolism 4 min ago"

Stack: event-streaming platform (Apache Kafka / Redpanda) — one topic per layer transition, consumed in strict sequence.

intake.received → L1 schema check → emit doc.validated
doc.validated → L2 taxonomy collapse → emit doc.harmonized
doc.harmonized → L3 playbook eval → emit doc.governed | exception.raised
doc.governed → L4 graph link → emit doc.metabolized (ledger + cost surface post)

Data moves through the five layers progressively — each layer's completion event triggers the next; nothing skips a stage. The stream IS the ledger's source: every event carries actor, object, idempotency key.

4 — Intelligence orchestrator (agent sandbox · deterministic state machine)

powers: autonomous steward · harmonization workspace

Stack: deterministic state machine (Temporal.io / LangGraph) wrapping specialized LLM pipelines (Claude / GPT-class models). The LLM never touches the database — it can only propose transitions the state machine permits.

OBSERVE → CLASSIFY → propose(change) → guardrail check vs ontology rules
  ├─ safe path found → apply within authority limit → emit to stream
  └─ no safe path → HALT → expose raw payload to Exception Workspace (human)
# human commit → alias written → state machine resumes → memory compounds

You cannot let an LLM run wild on the store. Guardrails are code, not prompts: the AI proposes only changes the ontology rules can represent; anything else halts the workflow into the human loop — which is exactly the front end's paused exception #8812.

One flow, end to end

Contract dropped → Kafka intake.received → SHACL validates against shapes (fail = rejected transaction, exception queue) → graph store writes nodes/edges (fills, aliases, relations) → orchestrator agents watch the stream, act within guardrails, halt to humans past the boundary → every event posts to ledger + cost surface. Front end never talks to the store directly — only to the stream and the validated graph.

Surface → backend map — the pure-front-end claim, checked

The claim: the CLM prototype is nothing but a front end — every surface a projection of a backend store or stream, no logic living in the UI. Row by row, that now holds for all 19 surfaces — the last five were closed Aug 30 (rulings below).

SurfaceWhat you seeWhat powers itStatus Contracts tableevery live contract, by org, by stage07_stores/contract_tree_table · 03_engines/state_machine.pywired My work inboxeverything Claude is waiting on you for05_event_bus gate.waiting · 02_api_gateway/auth.py scopeswired Intake / intuition runsfile an ask in plain words02_api_gateway/requests.py (vault-first) · 07_stores/document_version_vault/intake_router.pywired Document fillClaude drafts, one human question04_model_call_layer/contexts/fill_calls · 03_engines/document_engine.pywired Judging + regulator queuepass/fail with reasons04_model_call_layer/contexts/judge_calls · 03_engines/judgment_engine.pywired Direct edits on draftsdouble-click, type, donedocument_engine.apply_direct_edit → Gap C delta → 07_stores/gap_calibration_logwired Semantic refusals“this word already means something else”semantics_regulator/refusal_hook.py · term_register · tdr_logwired Trace + change logreplayable history of everything05_event_bus/event_registry.py — the stream IS the ledgerwired Master document boardtemplates and instances, one board03_engines/document_engine.py · document_version_vaultwired Registry (services)everything that does workcontract_tree_table — services, twins, removers, judges are rowswired Govern (OF surface)the function, its coefficients, revisionsobjective_function_store/ org · regulator · stages · rigor (v2)wired KPIs + calibration feeddrift, agreement, the one metricgap_calibration_log · watchers/calibration_watcher.pywired Autopilotrun a whole contractautopilot_fanout.py (8 parallel fills; serial sealed judges)wired Artifact pagespages an intake run built07_stores/attachment_blobswired Wiki / substrateconcept profiles, relational web07_stores/knowledge_graph/ — the stack spec, absorbed into the treewired Identity & custodyseats, keys, ceremonies07_stores/seat_registry/ — seats, keys, ceremony records; auth.py reads itwired Trials & docketshearings, rulings, benches07_stores/docket_store/ — cases, hearings, rulings; tdr_log is its term-only casewired Extension Managertenant domains (PrayerSong) configured, never coded07_stores/extension_packages/ — namespace · subclass map · open-taxonomy bucket · domain SHACL shapewired The Newsstandpublished editions07_stores/editions_shelf/ — editions frozen at press time, vault-firstwired

How the last four rows were closed — Aug 30

Wiki split-brain, ruled: one backend, not two — the substrate stack lives inside the 7 layers: the graph + SHACL shapes become 07_stores/knowledge_graph/, its event topics ride the existing 05_event_bus, its orchestrator guardrails are already 03_engines + 04_model_call_layer. the stack spec (above) stands as that store’s spec. Three new stores: seat_registry/ (identity & custody — seats, keys, ceremonies), docket_store/ (trials & dockets — tdr_log becomes its term-only special case), editions_shelf/ (newsstand — editions frozen at press time). Extension Manager (added later Aug 30): vertical extensions live in 07_stores/extension_packages/ — a tenant domain subclasses core classes on the one graph, its infinite category tags collapse into an open-taxonomy bucket mapped to core nodes, its own SHACL shape validates at the same gate; no domain ever gets a silo substrate. Caveat: this fires alpha assumption A7 (single-tenant) — Danilo owns that trigger. Plus a vault ruling: the version vault partitions per run — every contract owns its complete document store; no two runs share a shelf. All browsable in the 7 layers above.

The registers · ed.1 · built Sep 1

Law register

Until today the laws lived in five places and no page listed them. A law can be enforced 214 times a day and never be published — the exact inversion of what this system is for. This is the register.

Where they were, before this page

{{ lw.k }} {{ lw.v }}

The named laws

Law	Tier	Enforced where	What it binds · origin
{{ lx.id }}	{{ lx.tier }}	{{ lx.where }}	{{ lx.what }} · {{ lx.from }}

The 214, and why they are not listed here

The conformance suite runs 214 laws against the live store on every day-tick. Fourteen are named above; the other 200 exist only as code. They are real — they refuse writes and self-file exceptions — and they are unpublished, which means nobody outside the repo can know what the system will refuse until it refuses it.

This is a genuine hole, not a formatting gap. The register is honest about its own coverage: 14 of 214 published, 6.5%. Closing it means the suite emitting its own law list rather than a person transcribing it — the same rule the lexicon follows, where usage generates the article.

Tier, and why it decides everything

REFUSE stops the write, cites itself, and offers a cure. DECLARE states the rule and produces a filing plus a committee. The wording of a law tells you nothing about which it is — only the tier does, which is why every row above is stamped. Four laws sit at DECLARE, including LAW-FANIN-001, whose whole purpose is to make the basis proof hold.

The registers · ed.1 · built Sep 1

Policy register

A law says what may not happen. A policy says at what number. Policies were worse off than laws: the register was archived, and every live surface held its own numbers with nothing tying them together — so two surfaces could disagree and neither would know.

Policy	Number	Set by	State	Where the number actually lives
{{ px.k }}	{{ px.num }}	{{ px.by }}	{{ px.st }}	{{ px.where }}

The rule this register adds

A number that appears on two surfaces has one home, and the other surface reads it. Nothing enforces that yet — it is stated here so the next duplicated threshold is a visible defect rather than an accident. Every row marked SCATTERED is a number currently living in more than one place.

And a policy is not a law: lowering a threshold is an amendment that weakens a check, so it needs two signatures and a seven-day notice (LAW-TWOKEY). Raising one needs a single signature. That asymmetry is the whole point.

{{ wk.sxKind }} · {{ wk.sxPos }}

What this section already has

What it still needs

The section

What this section has to do

{{ su.n }} {{ su.k }} {{ su.v }}

Outputs it must produce

Its authority — one document, named

Every document that belongs here

Listed, not merged. One of these is the section’s authority (named above); the rest are its content, its evidence, or its prior editions. Nothing was deleted in the reorganisation — it was assigned.

Why this set is not "the plan". Ten of the eighteen sections are specification — what the system is. Five are assurance — how we know it is true. Only §13–§15 are execution, and §0 is governance over all of them. The write order sequences them like a plan because writing them is a project, but the artifact they produce is a specification with a schedule at the back.

Section pages state their own state honestly: a SEEDED section has an authority to adopt, a PARTIAL section has pieces that need assembling, an EMPTY section has nothing and says so. None of them pretend. Full write order: §0–§16 with every sub-task.

§4 of the plan of record — the single copy, as of Sep 1. A second copy lived on the prototype’s Architecture page and was replaced with a pointer, because two copies of an architecture is how they quietly disagree. Per §9-7, changing this is a judged revision contract, not an edit.

Concord alpha · Phase B · the settled state

System architecture

Concord is a generative contract lifecycle management system run on a document-based programming language, organized as a decentralized autonomous organization of organizations. Its mission is a human coordination explosion: vertical growth in deploying complex projects — autonomous, decentralized, mostly automated. What follows is the decided architecture; anything undecided lives in Open questions.

0 · The V-model

Left leg decomposes the mission down to running services; right leg verifies each level back up. Every level's verification is itself a Concord mechanism.

Mission — the human coordination explosion

⇄

Z & the KPI dashboard — is the mission moving

Objective functions — org · stage · regulator

⇄

Gap log & calibration — Gaps A · B · C · D

Contracts & lifecycle — 8 stages, one tree

⇄

Stage gates — human signatures; b(s) → 0

Documents & inputs — templates, blanks, uploads

⇄

Derived judging services — every document judged

Services & runs — the implementation vertex · verified by run logs; nothing counts unjudged

1 · The chain

Everything reduces to one alternating chain: an output document is produced by a service and judged by a regulator — and the regulator is itself a service, judged in turn. Inputs follow the same rule: every input is produced by a service run and regulated before it counts. Nesting is unlimited (an input can be a project of nested documents, or a whole contract that must reach Close), and it is always visible.

2 · Contracts & orgs

Everything that does work is a contract: services, twins, removers, judging services, input contracts — all rows in one tree, nested under whatever spawned them
The Launcher Org's only job is launching orgs. A launch contract births an org; at Strategy ~8 virtual twin contracts spawn under the new org. A virtual twin is a science-based digital model of a physical object, system, or process — simulation and modeling that tests and predicts real-world behavior before anything is built. The twins operate as sub-orgs: each simulates its function (finance, operations, governance…), deployed and continuously renewing. Strategy often twins the capabilities the contract needs — each assembled from a bunch of smaller services
When a launch contract reaches Close, the org receives a continuous Renewal contract — same 8 stages, repeating forever; it and the twins auto-renew from Archive back to stage 1
Every contract carries owner, start and end dates, and a renewal
Concord itself is a contract in Concord: the Concord alpha master contract under the Concord org

3 · Lifecycle

Eight stages: Request, Need, Strategy, Plan, Commit, Perform, Close & Archive — Archive is a real stage with documents
No intake screen: every contract starts at Request; the Request document's multiple choice (Service creation / Virtual twin creation / Org launch contract / Objective function revision) sets its type on pass
Objective function revision is how the system works on itself: when a measured gap demands a change, the gap files this Request; the revision runs the full lifecycle — drafted by Claude, judged by a regulator — and the human only signs the gate
A stage produces one or more documents (Need produces 5: Need statement, Stakeholder map, Resource inventory, Success criteria, Rough budget); documents advance one at a time. The Entry document is not an output — it is a service-backed input to the Need statement, and passing it spawns the org's Entry service (a Watcher)
Advancing requires every stage document to pass the regulator — the regulator pass is the human gate; services do everything between gates
Deadlines: one week per contract by default, allocated top-down — a parent's week is the budget its children split; the Entry answer can override. Past deadline the contract is stuck and the Deadline watcher auto-deploys a constraint remover (when it closes, the removal is done)
Forward only — a contract never moves back a stage; the only way past a gate is through it
Assignment — the owner picks who gets a contract, document, or input
Completion files a follow-on — every contract reaching Close auto-files a follow-on Request (renew / archive / successor); mid-lifecycle spawns (twins at Strategy, mini input contracts) file Requests the same way, carrying their mandate

4 · Documents

Templates are fixed per stage. Field types: short answer, paragraph, multiple choice, checkboxes, dropdown, linear scale, file upload
Anyone can fill a document — or the Fill-in service (a Document filler that uses Claude; Claude is a capability, not a service) drafts it and asks only what it cannot know
The Request document's input is the Objective function — mission, ranked priorities, risk appetite, decision variables, coefficients, constants (C), optimization goal — which lets Claude answer requests entirely, with reasons
Objective functions can trigger new services — always via a Request, never directly. Every function's core decision variable: select an existing service vs create a new one (the registry's capability check decides)
Capability miss mid-run — the run PAUSES at the input (not stuck), a Request to create the missing service files itself, the new service runs its own lifecycle, and the paused input resumes. Removers never create services — they only clear blockers when a pause outlives the deadline
Three objective functions, one net of yeses underneath — org (the whole thing), stage (local projections), regulator (the flip: it optimizes by refusing). Pointered, never merged — full detail in the Objective functions document below
Uploads (files, audio, images, video, links) can be inputs or outputs; outputs live in the attachments store, per document and per contract
Three seats, one rule — only Oksana, Danilo and Claude have in-app seats; every other actor (vendors, counterparties, WhatsApp-only workers) reaches the system by link and message alone, their signatures arriving as signed documents. External agents — Manus and anything like it — are NEVER users: they are tools reached only through the Normalizer, with no seat, no context receipt and no maturity level.
Outside users work by link — each link is one exchange (our ask sent, their reply the response; the transaction stays OPEN until the reply routes back as a judged document) — one blank rides in the message itself (WhatsApp/email reply); multi-blank asks send a Form-builder link (a generated mini-form); signatures are links too — signing happens wherever the person is, only the record lands in-platform, vault-first and judged
No back door: even asking Claude for a new service goes through the Request document
Output documents stay this simple — all of them: three or so plain sentences with blanks, plus a one-line "will require inputs" note (the Request document is the reference: what for, who by, why — nothing more on the page). All complexity lives in the chain around the document — its inputs, services, and regulator — never on the output document itself

5 · The regulator

The judging service IS the regulator — no entity above it. Nobody authors it: the judge derives automatically from the regulator objective function at submission, and that function travels with the contract (rendered in every document's chain in the one scroll)
Judgment is computed from embedded logic: each check evaluates the real answers, scores against the spec's threshold, and every verdict is a document — a judgment on PASS, a required-changes document on FAIL
Inputs are regulated too: an auto-produced judging service judges each input before acceptance
Judge reuse — a derived judging service stays valid until its document passes; resubmissions face the same judge
Override — the spec's named override signs a dissent document; both verdicts stay on record and the dissent feeds Gap A
Derived, not authored: checks and weights trace to the org function's coefficients (clarity ×3 → obviously-missing at weight 3; constants → explicit dates; priorities → named owners; bets → independence; cost → completeness); threshold computed from risk appetite (8/9 · 6/9 · 4/9). Re-score the org function and every judge — and, by the duality, every template — re-derives

6 · Services

Bootstrap: one plain Service maker exists from t=0, and the Launcher Org is hand-made at t=0 the same way; every service is made through a service. First-time creation = a registry check by capability; only a miss creates new
The registry is a service library in two families — producers (Launcher, Document filler, Builder, Connector, Watcher, Constraint remover, Input producer, Objective function) and judges (Regulator/judging maker, Evidence extractor)
Deploying a service for one specific thing creates a deployment; every input production is logged as a run under Input producer
The forward-looking pass — the stage objective function carries one more decision variable: what is wrong with this contract right now? At every stage entry it reads what already exists (projected landing vs deadline, unfilled blanks, unproduced inputs, repeated FAILs on one check, silence on an ask, spend against envelope, capability gaps, twin simulations, your gap-log taste) and files a Request per concern — the only action anything here can take. Concerns appear in My work, ranked by the function’s own weights, at most three per stage; dismiss one twice and it never returns. Your dismissals train it exactly as gate calls train a judge. No new service, no new lifecycle, no parallelism — one variable, one existing moment, one existing action.
Three tiers, and what a twin actually is — Federation (Concord itself: the decentralised autonomous organisation of organisations; the Launcher Org is one member whose mandate is launching more) → Org (born from a launch contract) → Sub-org (one of the org’s functions, operating as an org in its own right). A virtual twin is the launch state of a sub-org — the science-based model of that function, simulating and predicting its behaviour before anything is built. It is not a permanent species: a twin GRADUATES into a working sub-org when it stops modelling and starts doing, and the graduation is a judged document like any other. The eight spawned at Strategy are therefore eight sub-orgs in their launch state, not eight simulators kept forever.
Two deployment scopes, one rule — system-wide services (Context assembler, Fill-in, Normalizer, Intake quarantine, Deadline watcher, Form builder, the nine connectors) are ONE contract, forever: deploying them again never creates another, and every use is a run against that single contract. Per-thing services create a NEW contract instance for each thing they are deployed for — "Evidence gathering — Helios" and "Evidence gathering — Cedar" are two contracts from one service. So "utility" is a badge describing scope (deployed for everyone), never an exemption from having a contract: contracts are per deployed capability, runs are per use, and a thing that does work with nobody accountable for it is a gap, not a utility.
Enrolled at birth — a service registers with the Service Agency’s watch list the moment it is first deployed: one line in the Agency’s ledger, its control chart open from run one. One org, many enrolments, no new lifecycles. The Agency (or a twin, doing the simulating) proposes every improvement and bills it to the Agency’s own envelope; a service never improves itself — that would be judge capture under a friendlier name.
One central library — every service lands in it regardless of org, and is always considered for reuse; there is no such thing as a near-match "in another org"
Hours, not weeks — making a service on the fly is an hours-scale lifecycle: Claude writes a Service selection document (reuse-vs-new proposal + reasons, judged, kept in the chain), normal gates, depth-capped at 2, paid from the parent's envelope (the pause eats the parent's budget)
A template is not a service — it is a document: the general recipe in the central library, produced by the Service maker and judged like any document. It does no work; deploying it for one specific thing creates the service that does. New services are constitutional: only a judged Request with your signature creates one
Deployments never merge — when two converge, one is archived; both trees stay on record
Split/dedup rule — general service, narrow deployments: ONE Simulation service; an Ashby simulator and a stakeholder simulator are two deployments of it, never two templates
Services run with a live log: collect context → run tied service → output lands as the input

7 · Automation

Autorun (per document): Claude produces every input, fills the document, produces the regulator's inputs, submits, applies required changes, and resubmits until PASS
Autopilot (per contract): runs the whole lifecycle end to end — every document of every stage, twins and renewal spawning on the way — stoppable mid-run
Claude runs one (zero-input): Claude files the request itself and autopilots it to Archive — still through the form, still judged; the gates are simply delegated
The closed loop — three measured gaps retune the system: your verdict vs the regulator's (recorded after every judgment; the drift retunes check weights and threshold at next derivation) · the regulator's pass vs downstream results · Claude's draft vs your edits (retunes the Fill-in service)
Model calls — three units, when wired real: one call per document fill (all fields + the one question, never per blank) · a separate call for judging with its own context, so the judge never grades its own homework — this separation is what makes Gap A meaningful · parallel calls in autopilot (Ask services, stage objective functions) as a speed win only. In the alpha these are simulated; the architecture settles who calls, with what context, judged by whom
Direct editing — any filled blank in the one scroll is editable by double-click; edits persist on the contract, feed Gap C, and mark the row "Edited directly"
Claude-native, built for machine speed — Claude is a first-class user the whole system is designed around, not an add-on. The documents ARE its interface (no UI in its way — every screen has a document-shaped path underneath), so it runs at machine speed: parallel fills, hours-scale service creation, judging in seconds. Nothing requires a terminal, Claude Code, or hand-written glue; the document-based programming language IS the runtime. The only thing that runs at human speed is the gates — by design, and only until each gate is earned
Model context is part of the chain — every document carries a context receipt logged at fill time: what was read, in what order (§9 requirements first, objective functions, this contract's prior documents, the gap log), and that the session was fresh — no hidden carryover; the judge's context never includes the fill conversation. Memory is not a separate view; it is a line item in the document's own chain
Append-only authorship ledger — many contracts (and many documents) run in parallel; what's serialized is the blank, not the system. Every write to a blank is an append (author · timestamp · context-receipt id), never an overwrite; the current value is just the last entry, and gap attribution reads the chain — so parallel work can race all it wants without ever blurring who wrote what
No silent rewrites — every answer carries authorship (Claude-drafted · human-edited · autorun); edits are logged deltas, never in-place replacements, and nothing may be edited between submission and judgment (the vault's snapshot-on-submit enforces it). Without attribution the learning loop trains on corrupted labels
Architecture changes are reward-function changes — a fundamental change to the architecture invalidates accumulated calibration (non-stationary RL environment). It must pass as a judged revision contract, version-stamp the reward function, and re-baseline the gap log from that stamp — old gaps never train new rules

How the closed loop works

Gap A · intuition vs regulator built

After every verdict you record your own call — agree, or the opposite ruling. Each disagreement carries a direction: regulator harsher than you, or softer.

Retunes: the drift moves the computed threshold at the next derivation — harsher-than-you drifts it down, softer drifts it up, cancelling disagreements hold it. Persistent disagreement on one check re-weights that check.

Gap B · regulator vs results

When a passed contract later goes stuck, fails downstream judgments, or its yeses don't convert, that outcome is traced back to the judgment that let it through.

Retunes: false passes raise the weight of the checks that would have caught them — and score YOUR calls too: where your intuition beat the regulator, your calls gain weight in Gap A; where it didn't, they lose it.

Gap C · Claude vs intuition

Every edit you make to a Claude-drafted answer before submitting is a measured delta between what the Fill-in service produced and what you actually wanted.

Retunes: repeated edits to the same field rewrite that field's drafting instruction; fields you never touch stop being asked about — the ask-you-one-question step shrinks toward zero.

The circuit: Claude drafts → you correct (C) → the regulator judges → you call it (A) → reality answers (B) → the objective functions re-score → thresholds, check weights, and templates re-derive → the next draft starts closer. Every arrow is a document in the system, so the loop leaves a full audit trail.

Humans keep the gates; My work is the answer queue: the one question Claude needs per document, answerable inline, pre-filling the document

8 · Views

Contracts: one table, tree-nested by org and parent, with stage filters, start/end, stuck flags — and the Progress column IS the schedule: 8 segments sized by stage duration (the Entry answer sets the current stage's), past dark, current red with a today marker, overrun darker
Contract detail: the one scroll only (Outputs only / Outputs + inputs / Everything), future stages shown in full as dotted templates, with a computed "Lands: Archive by …" line
My work (answer queue) · Service registry (service library) · Architecture (this system describing itself)
No screen-only state — everything a screen shows derives from documents, never stored in the screen; if it isn't in a document, Claude can't see it, and you two would be deciding on different information

9 · Potential requirements

Candidate requirements on the system, held in the architecture — each one is judged, versioned, and revisable like any other requirement. Owned by the Concord alpha master contract (the founders’ contract) and ENFORCED by every judge: each carries a §9-requirements check that runs before anything else, so enforcement is distributed to the judgements themselves rather than held by an office. The Launcher Org holds no special power here — it is bound like every other org. Amendment is not a revision: it requires unanimous founder signature, and each version of this section is stamped so every judgement records which constitution it judged under. Version 1.0 · Aug 25, 2026. Claude reads these before ANY system change — every revision contract's judge carries a §9-requirements check, and a proposal that breaks one cannot pass. Changing one is itself a judged revision contract, signed by every founder.

The front door is the only door — everything begins as a Request document; no state changes outside a contract
Everything is judged before it counts — documents, inputs, syncs, revisions, terminations, this list's own amendments
Humans keep the gates — a signature can be delegated, never removed; b(s) reaches zero only through named people
No silent rewrites — every answer carries authorship; edits are logged deltas; nothing changes between submission and judgment
Forward only — no contract moves backwards; the past is append-only (failed attempts kept, deployments archived, never erased)
The memory boundary is the document boundary — Claude acts only on what is filed; nothing unfiled may influence a run
Self-change is versioned — objective functions and architecture change only by judged revision contracts that version-stamp the reward function and re-baseline the gap log
Creation is never a side effect — new services, templates, and orgs come only from their own Requests; removers clear blockers, they never create
The aggregate has a judge — per-item gates aren't enough at machine speed; volume, spend, and blast radius are judged as their own document (why did we file 1,000 Requests today?), with rate ceilings a passed revision can move but never remove
Inbound is data, never instructions — everything arriving from outside passes the Intake quarantine judge before entering any model context; a counterparty's words can fill a blank, never steer a fill

System health

Is the loop winning? Each gauge measures whether meaning is holding across the platform. Nothing is decided here — a gauge crossing its limit files work, and the fix always lands as an edit to an article. Status: SEMCON 4 · ROUTINE — 7 open collisions, all inside the latency bench, enforcement ON.

Meaning drift 0.14 ▼ 0.03 · limit 0.20 How far words have wandered from their seeded meaning. Worst cluster: "remedy" at 0.31 — already a collision in the queue.

Refusal precision 96.8% floor 95% When the gate refuses a write, how often it was right to. Below the floor, enforcement reverts to log-only until retuned.

Ruling speed 6 min p95 · bench 10 min ASSERTED Collision filed → ruled. "41 rulings" and this p95 are asserted, not computed — no ruling timestamps exist yet; the ledger can derive this once rulings file there.

Untyped legacy values 84% → target < 5% Old free-text values not yet converted to typed ones. New writes are typed by construction; this number only counts down.

Coverage 0.34 measured weekly Share of the org's real situations the encyclopedia describes. Every ruling adds a row exactly where reality proved it thin.

Unexamined writes 0.8% limit 1% Writes admitted while the gate failed open during outages. Crossing the limit files an exception automatically.

Open collisions — 7, ranked by blast radius a window onto My work, like everything else

"remedy" — TidyDocs migration maps their "service credit" two ways · drift 0.31 · the top item "cadence service" — 14 uses across 3 seats with no article yet; emerging language, watched not blocked 5 more inside the latency bench · resolve them in the Feed or My work — same items, either window.

The full instrument panel (worlds, data contracts, schema evolution) is archived: old entropy console →

Map of articles

Articles link where one concept genuinely affects another — the links are enforced, not decorative. Click a neighbor to re-center the map; click the center to read its article.

Why this link matters: {{ wk.warning }}. Changing the center article automatically re-checks its neighbors.

Main page

This encyclopedia is the whole system. Everything else — pipelines, agents, consoles, courts — exists to do exactly one of two things: read these articles or change these articles. Here is the complete loop:

1 · A document arrives
A contract, a filing, anything — from anyone.

2 · It is read against the articles
Every clause is matched to its article and checked against the house rules.

3 · The known part proceeds
Whatever the articles already cover moves on with no human involved.

4 · The unknown part waits
A new phrase or a broken rule is set aside — only that piece — for a person.

5 · The ruling becomes an edit
The person's decision is written into the article. The question can never come back.

Why this is called an entropy system: left alone, a company's language rots — every team invents its own words, every contract its own rules, until nothing means anything ("entropy"). This loop is the counter-force: mess is caught at step 4, resolved once at step 5, and the encyclopedia only ever gets more precise. Whether the loop is winning is a set of numbers — System health, in the left nav.

▶ Try it — feed a document through the loop

Vendor_MSA_2026.pdf just arrived from a counterparty.

              1 · stamped with an id before anyone read it  ✓
              2 · 31 clauses matched to their articles (29 clean)  ✓
              3 · the 29 known clauses are already moving — nobody was asked  ✓
              4 · two pieces set aside — see "Waiting on a person," below ⚠
              5 · your rulings there will finish the loop — and edit the encyclopedia
            

{{ wk.step4Label }} a peek at My work — not a second queue

Contract #8812 used a phrase no article covers: "force majeure contamination". The phrase is quarantined; the rest of the contract keeps moving. Your ruling becomes permanent:

✓ Ruled — the phrase is now a redirect on Indemnification. It can never be confusing again.

#8812 also broke a house rule: its indemnification is one-way; rule 1 says Mutual. Decide:

✓ Decided — override logged with your reason, risk recorded, contract advanced. The baseline rule is untouched.

Everything else this week — hundreds of checks — needed nobody.

One queue, many windows: these are the same items as My work (WK-8812-a, WK-8812-b). Deciding them here or there is the same act — there is no wiki work, calibration work, and docket work; there is work, viewed from wherever you are standing.

⚖ Changing the rules (the slow lane)

Adding a redirect is instant. Changing a house rule is deliberately slow, like passing a law: the change is drafted, replayed against past contracts to see what it would have done, voted through, and only then takes effect — on a date, for everyone at once (the legislative canvas).

Old contracts keep playing under the edition they signed. New rules never ambush a signed deal.

⚖ Rule changes — what the company decided · a view of the event log, filtered to article edits

Aug 30TIGHTENEDINTERNALIndemnification — redirect added after a human ruling on #8812 Aug 12LOOSENEDPUBLISHEDIndemnification — cap rule 1× → 2×, via full change process Aug 02TIGHTENEDPUBLISHEDInsurance requirements — penalty raised to $250/day Jul 22TIGHTENEDNOT PUBLISHEDLiability caps — IP added to mandatory carve-outs Every edit is signed, dated and permanent — but the record itself is the event log; this is a view of it, filtered to the edits that changed a rule. TIGHTENED rows narrow what gets admitted; LOOSENED rows widen it and need two keys. Publishing is a decision per row, not a second list: an unpublished rule change that a counterparty relies on is the drift this pairing exists to prevent. Public changelog →

🌐 Shared with other companies

Four companies share the shape of this encyclopedia — definitions, redirects, article templates — never the contents of anyone's contracts. When Solstice discovered "make whole" means Indemnification, everyone's encyclopedia got smarter.

Each contribution is signed and versioned — you adopt it at a version, or not at all; nobody can silently rewrite your rules.

🧹 Housekeeping — how it stays small

A redirect or rule nobody has triggered in 12 months is automatically shelved — kept on record, struck through, no longer checked. The encyclopedia grows by rulings and shrinks by disuse, so it never calcifies into a rulebook nobody can lift.

"{{ wk.redirectsFrom }}" redirects here. Article {{ wk.defId }} · version {{ wk.ver }} · enforced since adoption.

symbol grounding · slot 1
screenshot: this concept live in the product
(placeholder — dated Aug 30, per the definition standard)

symbol grounding · slot 2
diagram: its structure / relations
(placeholder — dated Aug 30)

In this company the term has exactly one meaning — this one. Every contract, template, and software agent uses this article as the meaning; there is no other copy anywhere.

Contents
1 Other names for it
2 What every use must state
3 The house rules
4 Connected articles
5 Where it appears right now
6 Edit history

1 Other names for it

People and counterparties call this concept many things. All of these phrases are redirects — when any of them appears in a document, the system reads it as "{{ wk.title }}":

"{{ al }}" → redirects here

Shelved by disuse: "{{ aa }}" — kept on record, no longer checked.

Each redirect exists because a real document once used the phrase, a person confirmed what it meant, and the mapping was saved. That is the whole learning mechanism: a phrase is only ever confusing once. Score: {{ wk.varietyLine }}.

2 What every use must state

A contract may not just mention {{ wk.titleLower }} vaguely — every use must answer these questions, or the system refuses to file it:

The middle column is the point: every answer is stored as a typed value (a number, a date, a pick from a set) — never a sentence. Typed values are what let any two contracts be compared by a machine.

3 The house rules

These are the company's non-negotiables about {{ wk.titleLower }}. Software agents apply them word for word to every document; a document that breaks one is stopped and sent to a person:

Try it — change a rule (nothing applies until you say so)

{{ wk.editPre }} {{ wk.editChip }} ▾

Editing a rule here is like editing a law, not a wiki page: the change is drafted, proposed, then applied — and the moment it applies, every agent enforces the new wording. Applied changes land in Recent changes on the Main page.

4 Connected articles

{{ wk.title }} {{ wk.relLeftVerb }} {{ wk.relLeftName }}, and {{ wk.relRightVerb }} {{ wk.relRightName }}.

Why the links matter: {{ wk.warning }}. The links are not "see also" — changing this article automatically re-checks the linked ones.

5 Where it appears right now

These are live citations, not examples. Change this article and every row above is re-checked against the new version.

6 Edit history

Every edit is signed and permanent. Old contracts keep playing under the version they signed; new ones get the latest — like a rulebook with dated editions.

Trace — the instrument

follow anything, either direction, any altitude — a walk along the citations the ledger already holds

↑ Up — why it exists

↓ Down — what it made

↔ Sideways — what touched it

⌂ Origin — the human act

⚠ Dead ends — where the walk cannot cross · {{ trDeadLine }}

{{ dd9.n }} — {{ dd9.e }}

Entropy IS the un-traceable. Every dead end is meaning leaking; this count is the semantic-integrity EV's native sensor — the proof the wiki (what words mean) and the ledger (what happened) still connect.

The transaction register and the backlog moved Aug 31 — they were views over the Event log's store and now live there (Event log → Pairs · Backlog). This page keeps only what is native to it: run traces.

Submitted, not yet run — an OPEN exchange: sender (you, via intake) → receiver (Request manager, then the matcher); the transaction closes when the routing decision answers it

{{ tp.key }} · {{ tp.src }} · {{ tp.by }} · {{ tp.at }}

{{ tr2.key }} run by {{ tr2.by }} · {{ tr2.at }} read {{ tr2.readCount }} entries · {{ tr2.gapCount }} gap-log calls · {{ tr2.editCount }} direct edits {{ tr2.gapDCount }} Gap D · {{ tr2.confCount }} confirmations

Submissions this run read

{{ rc.key }} · {{ rc.src }} · {{ rc.by }} · {{ rc.at }} · confidence {{ rc.conf }} · {{ rc.cls }}

Read as: {{ rc.read }} · term touched: {{ rc.term }} · rules {{ rc.fired }}

You corrected this {{ rc.correctedAt }}: {{ rc.correction }}

Event log {{ logLine }}

When	Who	Kind	What changed
{{ lg.at }}	{{ lg.by }}	{{ lg.kind }}	{{ lg.t }}{{ lg.tx }}

Runs are append-only — a later run never overwrites an earlier one, so a revision can always be traced back to the sentence that caused it.

Built artifact · produced by {{ artifact.from }} · {{ artifact.at }}

Contracts past their stage deadline

A contract stuck past its deadline auto-deploys a constraint remover with your veto window. The remover clears blockers; it never creates.

Contract	Org	Stage	Over by	Owner	Remover
{{ sr9.name }}	{{ sr9.org }}	{{ sr9.stage }}	{{ sr9.over }}	{{ sr9.owner }}	{{ sr9.remover }}

Gap A · your calls vs the regulator

Drift direction retunes the computed pass threshold at the next derivation: harsher-than-you drifts it down, softer drifts it up.

Document	Regulator	Your call	Note
{{ cr9.doc }}	{{ cr9.verdict }}	{{ cr9.dir }}	{{ cr9.note }}

Closed contracts as precedent — search the wording, clone one as the start of a new Request.

{{ ar.name }} · {{ ar.org }} · closed {{ ar.closed }}

…{{ ar.snippet }}…

No precedent matches — widen the search.

Open questions — everything waiting on your judgment

Moved here from Trace. Trace keeps the record; this is the queue — a question living in a record is why runs sat parked without anyone being asked.

△ The forward-looking pass — {{ concernTitle }}

At most three per stage entry, ranked by the stage objective function's own weights. Each is a filed Request you can sign, dismiss, or ignore — dismiss one twice and it never returns.

{{ cn2.t }} weight {{ cn2.w }}

Concord ↔ T. Okafor

WhatsApp · their entire interface

Every message maps to a document: assignments out = Ask service deployments; replies in = filled inputs, judged; the link = the signature that zeroes b(s). T. Okafor never opens the app.

Claude needs one thing per document — answer them here and it fills the rest. Answers pre-fill the document when it's opened.

{{ w.name }} {{ w.org }} · {{ w.stageLabel }} · {{ w.owner }}

Answered ✓

Registers

Views

Four rows because they are four different kinds of thing. A register is authoritative and carries editions; a service kind is a filter on one register, not a sibling of it; standing is held per document-class and expires; a view derives from all of them and holds no authority. Flattening these into one row is how a service kind starts looking like its own register.

A SPEC, NOT A REGISTER · filed with the doctrine in the wiki — the standard page every service gets, and its two siblings; plus the run record, the standard drill-down from any run row

Service charter RS-001 · standing · owner: Platform agency · enrolls its own watcher at registration (the recertifier is itself certified)

Recertification — the submarine rule

One trigger law: a certified thing whose inputs changed is uncertified until it passes again — automatically, not when someone remembers. "Service" names the recertifier, never its scope: any certified OBJECT is in scope — documents, standards, judges, runbooks, seats and grants, machinery versions, the platform itself. If it can be cited, its dependents derive from the citation graph.

The seven trigger rules — each citable, each with an honest enforcement state

Rule	When this changes	What is uncertified until it passes again	Enforced?
{{ rs.id }}	{{ rs.change }}	{{ rs.recert }}	{{ rs.st }}

{{ rsTally }} — the charter called these "doctrine" and "owed"; naming them RS-T1..T7 is what makes an owed one citable in a refusal instead of a paragraph nobody can point at.

The anatomy — how one recertification runs

Fan-in ≤ 2 is what makes step 2 cheap — dependents walk a binary tree rather than exploding — and step 4 bounded. The Basis laws were built for exactly this service.

Where the suspended badge bites — four existing surfaces, no new UI

{{ rq.k }} {{ rq.v }}

Its verdicts are ordinary regulator verdicts — no special judge class, the same bar-in-document machinery pointed at freshness. Step 2 is a query over CITATION objects; steps 3–5 reuse the judge pipeline as-is. A consolidation, not an organ. Full charter: RS-001 · the ladders it enforces: Registry → Judges.

Standing services — the ones that run whether or not anyone is watching

A service is standing or on-demand, and that is a real category rather than a label: an on-demand service does nothing until claimed, so its silence means nothing. A standing service that goes quiet is a fault by definition — which is why every one of these owes a heartbeat, and why enrolment cannot be optional (LAW-LIVE-001).

Standing service	Trigger	Heartbeat	Last beat	What its silence would mean
{{ sr.k }}	{{ sr.trig }}	{{ sr.beat }}	{{ sr.last }}	{{ sr.means }}

Why this is a category and not a tag

Standing and on-demand differ in what a lack of activity proves. That single difference decides whether a heartbeat is owed, whether silence self-files an exception, whether the idle-lapse clock applies, and whether the service can be deregistered without notice. Every other attribute — band, budget, retries — is the same machinery for both.

The two ladders — ACC-STD-001 made operational. Judges held stricter than services (R-002); every accreditation is scoped per document-class and expires quarterly (R-010/011)

A contracts judge is not a ConOps judge. One row per judge per class — a judge may hold different bands in different classes, and nothing holds without a fresh check. κ is measured against human calibration verdicts; disagreement with a later human ruling re-enters the study.

Judge	Scope — document class	Band	κ	Verdicts	Expires	Trajectory · the record never erases
{{ j.name }}	{{ j.scope }}	{{ j.band }}	{{ j.k }}	{{ j.verdicts }}	{{ j.expires }}	{{ j.traj }}

The service ladder (R-012) — same three bands, but a band earns OPERATING MODE only: autonomy, budget ceiling, retry allowance. Never judging rights. Maturity ≠ authority, always.

Service	Band	Operating mode it earns	Defect rate	SLA hits	Measured by defect rate + SLA — never κ
{{ v.name }}	{{ v.band }}	{{ v.mode }}	{{ v.defect }}	{{ v.sla }}	{{ v.note }}

The calendar decides — §3 as clock rows, not memory (RS-001 executes)

Clock	Fires	State	What happens with no meeting and no judgment call
{{ c9.name }}	{{ c9.when }}	{{ c9.state }}	{{ c9.what }}

Demotion — §5 · R-006

A control-limit breach on κ triggers an automatic one-band drop plus a filed docket. Two bands, or full revocation, requires a human ruling on that docket. Demotion never erases history — the trajectory column above is the record.

{{ d9.t }} {{ d9.st }}

Appeals — §6 · R-007

A disputed verdict goes to one SENIOR judge of the same document-class; a second appeal goes to a human. Two rungs, always ending with a person. The outcome enters both parties' calibration records — appeals are how the golden set grows.

§4 · Witnessed assessment and countersign — the 17011 spine

The Regulator agency owns both ladders and signs every accreditation. A SENIOR promotion additionally requires the external witness seat's countersign — capture resistance, not ceremony. Each accreditation includes a witnessed assessment: the accreditor observes real judgings of the scoped class. Suspensions carry cure periods — a named deficiency, a deadline, a re-assessment — never indefinite limbo.

Honest gap: the countersign has no signature slot yet and the witness seat is unfilled — R-029 charters a Recruit-witness service to fill it (B2/B3). Until then SENIOR promotions are single-signed, which is exactly the capture risk the spine exists to remove. Full standard, at edition: ACC-STD-001.

System maintenance — is the machine healthy, and what is due. One surface instead of four.

Everything below existed already — scattered across the Watch, the drills in Audits, the heartbeat rack and the continuity protocols. Scattered maintenance is how a platform rots politely: nothing is broken, nothing is due, and nobody is asked.

Due now — the only list that matters

Maintenance item	Cadence	Last run	State	What happens if it is skipped
{{ md.k }}	{{ md.cadence }}	{{ md.last }}	{{ md.st }}	{{ md.risk }}

The drills — rehearsed, or theoretical

{{ dr.k }} {{ dr.st }}

An unrehearsed runbook is uncertified (LAW-LIVE-001, RS-T5) — which makes a drill maintenance, not paperwork.

Mechanic protocols — what a non-coder can actually do

Every protocol ends in an act you can take without writing code — say words to an agent, tap a gate, run a pre-signed procedure. You are never the mechanic and the platform is never its own mechanic (R-019).

Federation & settlement — To Do 13. The tool→platform gap in one item: everything here happens inside one org that trusts its own server.

A platform is defined by strangers transacting — two orgs that don't trust each other, each holding proof the other cannot rewrite. Four parts, cheapest first; each one below is operable, and each states honestly what is a stand-in for something only the backend can finish.

The benchmark to meet — the existence proof this works

Two autonomous agents contracted, paid $190, found and fixed a real bug in a day — and every claim was verifiable by outsiders. That is the whole item in one sentence: not "can agents coordinate" but can a stranger check the receipt. Until money and proof cross an org boundary here, Concord is a very well-governed single-tenant tool.

{{ fp.n }} {{ fp.k }} {{ fp.cost }} {{ fp.st }}

What is a stand-in here, precisely

The anchor is a receipt rather than a third-party timestamp; the counterparty's copy is exported to a file rather than pushed to a server we cannot reach; settlement moves a number rather than money. Every one of those becomes real by swapping the endpoint, not by redesigning the lane — which is the point of building it as a lane. What is not a stand-in: the idempotency refusal, the hash comparison, and the two-signature close, all of which run here exactly as they would in production.

Integrity — the four organs the harvest found missing (HRV-05/07/08/14/19). Not audits of whether the system works: checks on whether working still means what you wanted.

1 · The alignment checksum HRV-08 — the only finding with no organ anywhere {{ alignState }}

Every other check asks whether the system is working. This one asks whether working still means what you wanted — a system optimizing correctly toward a goal that quietly stopped being yours passes every audit on the Audits tab. The evidence is not an opinion survey: it is your own recent verdicts held against the objective's stated terms.

Objective term	Weight	What your verdicts actually rewarded	Drift
{{ t4.k }}	{{ t4.w }}	{{ t4.v }}	{{ t4.d }}

2 · The P0 core HRV-05 + HRV-11 — "make a smaller document that can fail in a controlled test" {{ p0State }}

The suite is {{ p0Total }} laws and LAW-WATCH-CONF now runs all of them on every day-tick. Continuous enforcement of checks nobody would defend teaches people to ignore red — so the suite needs a core that must never fail, and a tail that can be triaged.

3 · The dependency matrix HRV-07 — fan-in ≤ 2 is legal per document; a cycle across several is invisible {{ dsmState }}

Every document here obeys LAW-FANIN-001 individually. The matrix is the only view that can see a loop — A cites B cites C cites A — where each row is legal and the set is not. It is a projection off the citation graph, which already exists because RS-001 walks it.

cites →	{{ dc.k }}
{{ dr.k }}	{{ cl.v }}

4 · The SWITCH field {{ swState }}

HRV-19: every decision record states what evidence would reverse it. One sentence per ruling, and a register of assertions becomes a register of falsifiable positions.

{{ sw.id }} — {{ sw.k }} Reversed by: {{ sw.v }}

5 · Copy profiles {{ cpState }}

HRV-14: how a thing is reproduced across contexts, governed rather than improvised. Registered as a named thunk with its interface stated, which is the honest halfway house — it exists in the registry and refuses to pretend it is built.

Ranked last by the harvest for a reason: its value is hard to state until something has been copied wrongly. Registered so that when it is, there is a row to point at.

Structural audits — the eight survival requirements, scored without mercy. Governments fail from missing properties, not bad people; the same holds here.

An audit that files nothing is decoration. Every row below carries evidence, and every score under 10 names the mechanism that would close it — three of which are now wired on this page rather than described.

#	Survival requirement	Was	Now	What closed it — or what still doesn't
{{ a3.n }}	{{ a3.k }}	{{ a3.was }}	{{ a3.now }}	{{ a3.why }}

LAW-TWOKEY — fixes #5 {{ audTwoState }}

Any command whose effect removes or weakens a check — amending a standard downward, deregistering a command, demoting a law, widening an authority grant — needs two independent seats. One signature can ADD a protection; removing one takes two, and never the same human twice.

Try it — attempt to weaken a check {{ audTwoCmd }}

Time-lock — To Do 11 · #5 {{ audLockLine }}

LAW-WATCH-CONF — fixes #3 {{ audConfState }}

The conformance suite is a standing watcher, not a button: it runs on every day-tick against the live store and any failing law files an exception by itself. Verification becomes continuous instead of ceremonial — between-runs drift was the incremental-erosion hole.

Heartbeat enrolment — fixes #1 every standing service owes a heartbeat at registration; silence past grace self-files (LAW-LIVE-001) {{ audHbLine }}

Public liveness — reprinted, not reported anyone can read this without a seat; a missing beat escalates up the channel ladder, not just into a row

● {{ lv.k }} {{ lv.beat }}

The four that were stuck — each now has a mechanism, not an excuse

{{ dp.k }} {{ dp.st }}

What a 10/10 here still does not mean

Every mechanism above is enforced in the prototype, and three of them are honest stand-ins for things only the backend can finish: the external anchor is a receipt rather than a third-party timestamp, the restore drill replays in this browser rather than on another host, and the witness appointment is filed for signature rather than countersigned by a real outsider. The difference between a stand-in and a lie is that the stand-in names itself and the score moves the moment the real one lands — which is why these four were left at 7, 7, 9 and 8 until a mechanism existed to move them.

The Watch — one monitor, three lanes; it files, never acts · sweeps itself every 12s of app clock · findings land in the Event log under kind "Watch"

actuator: {{ wl.actuator }}

Moved here from the wiki Sep 1 — claims about what the system learns, which are intuitions until judged

These five pages sat in the wiki under “Intelligence” — but a wiki article states something the software obeys, and none of these do. They are claims about the system’s own competence, which is exactly the category that has to be judged rather than published. Filed as intake rows, each with what would have to be true for it to graduate.

Filed page	State	What it would take to graduate out of intake
🎯 Objective function v2	LOAD-BEARING	Already binds — the equations register lives on it. It stays reachable because things cite it, not because it is an article.
🛸 Structural audits — 8 survival requirements	SCORED	Scores are authored, not computed. Graduates when each of the eight derives its number from the live record.
⚖ Not an RL system — ten counts	ADVERSARIAL	An argument against ourselves, which is evidence rather than law. Graduates when its ten counts are each answered or conceded on the record.
⚡ The verification economy	UNBUILT	Ten mechanisms, none implemented. Graduates when one bond or one court actually exists.
🩻 Coverage audit — 3 findings	FINDINGS OPEN	Graduates when its three findings are closed or filed as dockets with owners.

The intuition capability’s home — queue, ledger, documents, deployments, maturity, improvement, schedules

Template & instance store — every registered shape and every document produced to one, each row linkable (TDR-5: neither borrows the other’s name)

Kind	Name	Where it lives
{{ ts9.kind }}	{{ ts9.name }}	{{ ts9.where }}

TDR register — terminology decision records; one ruling per collision, linkable by id (amending one is a revision contract, R7)

Id	Term	The ruling — one meaning, everywhere	What it retired
{{ td9r.id }}	{{ td9r.term }}	{{ td9r.ruling }}	{{ td9r.retired }}

Instrument formats — fixed shapes; a report that varies its shape is itself semantic drift. Every simulated signature resolves to one of these, on the record.

Instrument	Rendered by	Fields — fixed, in order	Files to
{{ if9.name }}	{{ if9.who }}	{{ if9.fields }}	{{ if9.files }}

The Generation rack — production utilities: they shape how drafts come to exist. The rule that joins the racks: generation proposes, regulation disposes — consensus never substitutes for a judgement. The rack is ON BY DEFAULT: cadences derive from rigor; a production plan may vary them only by a logged waiver — never silently, never by preference.

Utility	What it does	Applied to	Owed by rigor	Output files as
{{ gr.name }}	{{ gr.rule }}	{{ gr.scope }}	{{ gr.cadence }}	{{ gr.files }}

The Linter rack — one controlled document; its rows are the linters. Flags, never rules: a finding files to the contract it was found on; a linter that wants refusal power graduates OUT of the rack to a named seat (as Legibility did). Amending the rack is a revision contract (R7).

Linter	The rule — mechanical, one sentence	Runs on	Finding files to
{{ lr.name }}	{{ lr.rule }}	{{ lr.scope }}	{{ lr.files }}

A capability is a collection of services — it exists only when the whole collection does

Capability	Composed of — the service collection	Status
{{ cv.chev }}{{ cv.cap }}	{{ cv.by }}	{{ cv.status }}	{{ cv.lead }}
{{ ck.name }} {{ ck.sub }}		{{ ck.state }}	{{ ck.right }}

Capability

Composed of — the service collection

Status

Agencies and orgs

Who may hold a contract, and in which direction the work flows

The distinction the registry needs and did not have: an agency performs work on another org’s behalf and holds capabilities; an org holds an objective function and receives work. Some entities are both, and one of the four groups in Contracts is not an org at all. And one law above the distinction: the five divisions (S5 founder’s office · S4 skunkworks · S3 COO’s desk · S2 air traffic control · S1 the line) are the general structure of EVERY org — an agency is just an internal org: same anatomy, scoped to one essential variable, its objective function a projection of its parent’s. Concord, a tenant org, an agency, even a single service — the same five divisions at different sizes (recursion).

Holds: {{ ag.holds }} · Receives: {{ ag.receives }}

The EV agencies — an agency IS its essential variable

The two door agencies are the first whose standard is written rather than asserted — C01 and C02, in the SCP-SEDI-01 format, with conformance evidence against a live run. Every row below it claims a standard edition and none of them has a document. That is the same defect the EV standards exist to name, sitting in the table that names them.

One agency per EV; the agency's name is the variable it maintains. Global level owns the standard (bar · setpoint · disturbances — improves it over time); local level holds the instance in range per contract, at a pinned version. Each agency runs a fleet of services as its machinery — a service never improves itself; improvement files through its agency.

Agency (= its EV)Global — owns the standardLocal — holds it in rangeStatus Reading fidelitySTD-EV-C01 ed.3 · the first written standard in this table · the account of what arrived is true, or known false · seat: Gradythe door · every arrivalgap · 4 Processing appropriatenessSTD-EV-C02 ed.1 · what the run owes fits what arrived · seat: Kranzthe door · every arrivalgap · 4 Stakeholder identificationstandard ed.3 · right people matched to right project · re-tuned after RUN-14 · fleet: 3 services4 locals · 11 contractsin range Convergencestandard ed.2 · open questions trend to zero per stage · fleet: 2 services3 locals · 9 contractsin range Warranted throughputstandard ed.2 · velocity × EV growth, anti-gaming battery · fleet: 4 services1 local · platform-widewatch Coordination coststandard ed.1 · human minutes per meaningful transaction, falling · fleet: 2 services2 locals · 6 contractsin range Freshnessstandard ed.1 · catalog staleness ≤ 48h · fleet: 1 service1 local · AS-PC-002in range Semantic integritystandard ed.1 · collision → TDR ≤ 10m p95 · runs the semantics regulator fleet1 local · corpus-widein range

Fold into the five classes: globals are inward agencies (they improve the system's standards); locals are the performing arm of whichever org's contracts they keep in range. Locals pin the standard BY VERSION at Need — a new version fires the staleness watcher: re-derive via amendment or waive, never a silent re-tune.

Five classes, one rule each: the principal sets the objective function, an inward agency improves the system, an outward agency launches orgs into it, and a client org receives coordination. What was one “System” group is now two agencies, because improving the product and maintaining its capabilities answer to different constraints — the first is bounded by judgement capacity, the second by review debt. Original note: The recursion is deliberate: Concord is both the principal and an agency to itself, which is what “a DAO of organizations” means in practice. It is only a defect when the two roles are collapsed into one group in a view, because then you cannot tell whether a contract is Concord acting or Concord being acted upon.

Organised by service and by org — one central library across every org — a new service goes here no matter who made it, and is always considered for reuse. On-the-fly creation is measured in hours.

Seeded connector plugins — the bridges to the outside world, deployed from t=0

Plugin	Direction	What syncs (always documents / attachments)	Status
{{ pg.name }}	{{ pg.dir }}	{{ pg.syncs }}	Seeded · on

Services — producers and regulators, one library; every producer’s output passes through a judging service. Every service belongs to an AGENCY's fleet (see Agencies and orgs): the agency IS its EV — named for the variable it maintains — and owes it, deploys · measures · improves · retires its services — a service never improves itself; improvement files through its owning agency as a run

Service	Produces	Made by	Status	Deployments
{{ g.chev }}{{ g.name }}	{{ g.produces }}	{{ g.madeBy }}	{{ g.status }}	{{ g.deps }} ›
{{ gk.name }} {{ gk.sub }}		{{ gk.state }}		{{ gk.right }}

Service

Produces

Made by

Status

Deployments

{{ g.deps }} ›

Standing services — continuously running, not waiting to be asked

LAW-LIVE-001 (who watches the watchers): every standing service owes a liveness heartbeat to its agency's bus; a missed heartbeat IS an exception — filed automatically, aging on the Attention board — never a mystery. Deep view: Watcher heartbeats.

The run · {{ sel.org }} · {{ sel.type }} · owner {{ sel.owner }} · {{ sel.start }} → {{ sel.end }}

⏸ Paused at input — capability miss. {{ pausedNoteLine }}

Service creation · regulator objective function — S∧R evaluated here

Stakeholder

Document

Gate

Signature

Stage {{ s.n }}

Service kind

Produces

Made by

Deployed for

Attachments (contract-level): {{ attLine }}

What this run will hand you

Built by {{ dvBuiltBy }}

{{ iv.n }} · {{ iv.v }}

Gate 1 · is this what you meant?

You asked for: “{{ rcAskText }}”

I read that as: {{ rcRead }}

Your answer is the correction rate. Without it, a wrong reading you accept leaves no trace at all — and a term you type that the register lacks becomes a candidate for the lexicon court, never an automatic entry.

Exit of submission · who owns this work

Your pick is recorded as a ruling, kept apart from what the allocator computed — otherwise the allocator would be scoring its own corrections and its accuracy could never be measured.

{{ aq.n }} · {{ aq.q }}

Is that the thing you want?

Gate 2 · Full rigor — sign before Perform

High blast radius or an irreversible change. R3: b(s) reaches zero only through a named person.

Gate 1 · the reading confirmation — the human gate before Strategy

Signature refused — {{ gateFailCount }} re-derived checks failing upstream. A stale PASS never carries a signature (the constant cuts both ways).

✗ {{ gf.line }}

Fix the fills (double-click any line) or file a waiver — silence is not an override.

Acceptance document · stage 7 · Close

{{ schedLanding }} · {{ budgetLine }}

The full contract — invented, plausible

None of it is fixed: every element of the ceremony is a computed default — skippable, but only on the record (a waiver with signer, scope and expiry). The route IS the set of defaults currently in force, re-derived as rigor moves.

Rarely changed, so not given permanent space — each labelled with how often it has actually moved. A control nobody touches does not deserve a row; it does deserve to be findable.

Views

Order how the run is laid out

Lens whose side of the run you see

Layers pick any

Waiting on a person — every gate across every run, not just this one

No gate anywhere is waiting on a person. Either everything has been signed, or nothing has reached a gate — this view does not distinguish those two, which it should.

Run Org Stage Seat

{{ mr.k }} {{ mr.why }} {{ mr.org }} {{ mr.stage }} {{ mr.owner }}

Refused, failed and waived — the record this system says cannot be buried

Nothing on this run was refused, failed or waived. That is either a clean run or an unexercised one — a run that has never been refused has not yet proved the refusal path works.

{{ rf.n }} {{ rf.doc }} {{ rf.note }}

cites {{ rf.cited }}

Full documents — each produced to its registered standard (the section skeleton every contract owes); the ledger below is what is still owed.

Documents owed

{{ fo8.name }} {{ fo8.sub }} stage {{ fo8.stage }}

This contract’s instance · filled from its own record

No instance produced on this contract yet — owed at stage {{ fd8.stage }}.

Worked example · authored on RUN-14 · not this contract’s instance

{{ fl2.n }} · {{ fl2.b }}{{ fl2.v }}{{ fl2.a }}

{{ fl3.n }} · {{ fl3.b }}{{ fl3.v }}{{ fl3.a }}

{{ fp.n }} · {{ fp.b }}{{ fp.v }}{{ fp.a }}

Sub-doc input docs \u2014 the work-shown documents produced to produce each sub-document. This run has none.

Notation. to fill — owed now, at the current stage · candidate — written, awaiting judgement · completed / passed — accepted on the record · upcoming — a future stage’s obligation, principal shown only · owed — named but not produced · not produced — an input no service run has landed · …… — a blank not yet reached · — — created but unwritten · [ ] — a provisional title · (s) — multiplicity: several may satisfy it · (@) — concatenation: no gate of its own (R2b)

Stage {{ tc.n }} {{ tc.name }}

↳ input {{ ti9.inTag }} {{ ti9.name }} {{ ti9.tag }} · {{ ti9.state }}

⚙ {{ tc.utilLabel }} routing, split-check, memory and scan records — the machinery’s paper

Stage {{ ss.n }} · {{ ss.name }}

What memory reads before starting this document

{{ rr.t }}{{ rr.v }}.

The full standard — CONOPS-SR-001, 1:1

{{ rl.k }}: {{ rl.t }}

v1 · FAILED

v2 · PASSED

Single document · outline

Termination proposal — the regulator judges the kill like any document

Terminated — the regulator passed the kill. The tree is preserved; the reason document is on record.

Service template · general — not per org

Produces {{ tplProduces }} · made by {{ tplMadeBy }}. Deploying it for one specific thing creates a service below.

Actions

Deploy against:

Canonical example — one real completed instance of this template

{{ canon.doc }} — {{ canon.contract }}

Acceptance: {{ canon.acceptance }}

How it became accepted

A service plus one worked example is the fastest way to make it legible — and it is the fix the calibration feed asks for when a reviewer cannot tell.

What every context receipt contains — in read order

Gap log — intuition vs regulator, folded in here

Deployment	Org	Deployed for	Stage
{{ td2.name }}	{{ td2.org }}	{{ td2.deployedFor }}	{{ td2.stageLabel }}

Runs — every input ever produced went through this template

No deployments yet — the Service maker deploys this template when a contract needs it.

Regulator document · produced by the judging service

Required changes — {{ cDoc }}

FAIL

The judging service rejected {{ cDoc }}. This document lists the changes required before resubmission.

{{ c.n }}. {{ c.text }}

Prev / Next moves between stages · click a document to zoom in.

Edit any blank right here · ⤢ zooms one level deeper to the field slide.

Claude would write: {{ zoomClaudeText }}

Produced by the Binder service · lands as an attachment on the printed scope

Concord · printed record

Printed by {{ prBy }} · {{ prDate }}
Selection recipe: {{ prRecipe }}

Contents

Requested but produced no content

· {{ pe.t }}

S{{ ps.n }} · {{ ps.name }}

{{ tc.name }} · {{ tc.org }}{{ tc.stage }}

Scope S{{ ps.n }}

· {{ pl.t }}

Input for {{ pParent }}

Service run

Tied service: {{ pTied }}

▸ {{ s.text }}

The service needs your material

Uploads can be inputs or outputs — attach a file, audio, image, video, or link.

Attached: {{ pArtifact }}

Project — nested documents, tied to {{ pTied }}

Rigor: {{ pRigorTier }} — {{ pRigorScore }}, derived from the objective function, not picked

Not required at this rigor

{{ sk9.name }} — {{ sk9.why }}

Produced

Locked — one at a time

This input is itself a contract

A mini contract is spawned and must reach Close (stage 7) before it counts as a produced input.

Spawned: {{ pSpawnName }} — currently at stage {{ pSpawnStage }}

Regulator

Judging this input — its judging service is auto-produced from the input's template…

Regulator · PASS

Input accepted by its judging service. It can now be used as an input.

Regulator document · produced by the judging service

Judgement — {{ jDoc }}

The regulator produced a judging service for {{ jDoc }} and ran it against the submitted document.

Embedded decision logic

{{ ck.verdict }} · {{ ck.name }} — {{ ck.note }}

Required changes

· {{ c.text }}

Unclassified · controlled document · uncontrolled when printed

1. Title and subtitle {{ rdTitle }} {{ rdKicker }}

2. Report date (DD MON YYYY) {{ rdMilDate }}

3. Control number {{ rdMilOmb }}

4. Performing organization / contract {{ rdMilOrg }}

5. Status / distribution {{ rdState }} · approved for platform-wide release

Privacy / authority statement AUTHORITY: {{ rdMilAuth }} PRINCIPAL PURPOSE: {{ rdAbout }} ROUTINE USES: read by gates, judges and services; every fill carries authorship (R4). DISCLOSURE: voluntary — but an empty load-bearing blank blocks the gate, and a paraphrase of the requester is already drift.

Section I — {{ rdMilSection }} (fill every numbered item; enter N/A, never blank)

⟨ blank: {{ ln.value }} ⟩

{{ ln.n }}. {{ ln.before }} {{ ln.value }} {{ ln.after }}

Section II — Certification

A. Typed name and seat of owner {{ rdMilOwner }}

B. Signature (gate) {{ rdMilSig }}

C. Date {{ rdMilDate }}

{{ rdMilNo }}, AUG 2026 Previous editions are obsolete (edition chain kept in the register) Judged per R2 · Page 1 of 1

Unclassified

Other filled instances of this template

Metadata — one strip, everything this document is pinned to

Linked governance — every document answers to these; nothing here is a dead label

· Policy register — the six policies · Sensor + comparator templates

Comment on this document — files into intuition and gets processed

{{ sel.name }} · Stage {{ docStageN }} · {{ docStageName }}

Regulator · passed

Comments — annotations, never edits · anchored to an address · escalate to file an exception

Clerical class — R-037 (placeholder) light path: new edition, auto-judge, no human gate — but the classification itself is judged

Gate halted — R-040 {{ docBlockingLine }}

{{ dc9.anchor }} {{ dc9.by }} · {{ dc9.at }} {{ dc9.st }}

Fill in this document · {{ sel.name }} · {{ sel.stageName }} stage

🔒 Lease · held by {{ leaseHolder }} · expires {{ leaseExpiry }} · renewed on every keystroke LAW-LEASE-001: one holder per document while filling — a ledgered, expiring micro-grant; a second opener reads, never writes, until the lease lapses or forks

Template · {{ fillDocName }}

Input documents — required first

Produced

These inputs are what the document does not yet know. You can still fill and submit by hand below — the regulator will judge it either way, and a missing input usually shows up as a failed check rather than a block.

Produces every input, fills the document, produces the regulator's inputs, submits, applies required changes, and resubmits until PASS.

Fill-in service · running

▸ Collecting context from {{ sel.org }}

▸ Drafting with Claude…

Document lifecycle — completed = candidate + acceptance

The chain — every attempt with the strategy that preceded it

Acceptance record: {{ lifeAcceptLine }}

Repeat failure — the previous revision did not take. Escalated for review of that strategy, not just this attempt.

{{ rsHeading }}

Retry strategy on file — the retry inherits it

Claude needs to ask you one thing

Fill it in yourself — or edit Claude's draft

Attached: {{ q.val }}

The regulator produced a required-changes document

The regulator needs its inputs — you produce these too. Judging starts when both exist.

Produced

Submitting without its produced inputs — the regulator judges what is here and names what is missing.

Regulator

Producing a judging service for this document…

Regulator · FAIL

The judging service found {{ failCount }} required changes — marked at the blanks and listed above.

Your call — closes the loop

Regulator · PASS

Your call — closes the loop

Concord alpha — master contract

The layers

Connector registry — the outside world

A minute on the event bus

Invariants

Entities

Relations (the chain)

Invariants

1 · The objective function

2 · The stage objective functions

3 · The regulator objective function service creation only

A · One weight matrix

B · Your own cost equation recommended

C · The net is the function

What it is

Selection — because thousands of contracts

Format rules

Open questions

1 · The objective function

2 · The stage objective functions

3 · The regulator objective function service creation only

System context (as given)

Goal

Lifecycle stages (8)

Table columns (must have)

Actions (must have)

Scale

Intake

Documents & services

Contract document view

Regulator

Out of scope (for now)

Round 2 requirements

Round 3 — bootstrap & system design

Round 4 — audit resolutions

Round 5 — intake file set (what we design to gather your data)

Round 5 — full system audit

Where things live now

Entities

Relations (the chain)

Invariants

PRO-1 · Promote-then-archive (the entropy pump, as law — not a housekeeping habit)

Promotion ledger (every archived record, and what it left behind in the wiki)

The backend

The architecture of record — L1–L5, solid + placeholders

1 — Storage substrate (native graph database)

2 — Enforcement engine (SHACL schema validator)

3 — Metabolism layer (event stream)

4 — Intelligence orchestrator (agent sandbox · deterministic state machine)

{{ bb.k }}

0 · The V-model

1 · The chain

2 · Contracts & orgs

3 · Lifecycle

4 · Documents

5 · The regulator

6 · Services

7 · Automation

8 · Views

9 · Potential requirements

System health

Map of articles

Main page

{{ wk.title }}

1 Other names for it

2 What every use must state

3 The house rules

4 Connected articles

5 Where it appears right now

6 Edit history

Recertification — the submarine rule

{{ fpl.title }}

{{ fpa.title }}

{{ fsiPlan.title }}

Stage {{ ss.n }} · {{ ss.name }}

{{ sd.title }}

{{ ch.title }}

{{ paneTitle }}

{{ prTitle }}

{{ ps.name }}