The System

AEIIEA keeps records of what AI systems do and lets anyone check them later. This page says how it is built: seven responsibilities the system performs, the things it holds, the concerns that cross it, and what is running, what is being tried, what is only designed. It is the map the front door points at and the one the people building it use. When this page and the code disagree, this page is wrong first; the code is the fact.

Each responsibility below is a role with a boundary, not a step in a sequence. Its card says what it takes and gives, what it establishes and what it does not, what runs today and what is only named, and the test that would fail if the claim were false. The paragraphs between are for reading; the facts come from the architecture model the page is rendered from, and anything that changes often, a count or a version, is read live on the Readout rather than written here. The Readout explores the system through its seven existing doors: six of these responsibilities and a restricted Operations door. They correspond to the responsibilities here but are not one to one; Index / Projection has no door of its own. Verify is where a downloaded record is checked on your own device.

Read as a map of roles and boundaries, not as the order anything runs. Process is the frame: it sets the rules for change and runs the promotion path, and a release that bypassed that path is detected, not prevented. Producer, Contract and Archive are the evidence path; a record moves that way once and never back. Assurance checks a record against all three and changes nothing. Index and Application read from the Archive and never write to it. Identity, privacy, security, interoperability and operations cross everything and are boxes nowhere.

Makes evidence under an explicit process and a versioned instrument.

Symposium is the producer today. Four seats: two debating models, an auditor, and a narrator, with a rule-based heuristics engine and a human Observer line. The orchestrator seats the models, runs the turns, stops at the turn limit, at a cost cap, after three failed turns in a row or when a person stops it (a batch also stops a run at its time limit), never on agreement, and hands the result to the storage adapter; a batch runner drives it unattended from a list of topics. It never edits a turn after it is spoken and never ranks a model.

What was measuring is frozen into every record at session start: the instrument, as hashes of the auditor's system prompt and assessment template, its validator, the heuristics source, the narrator prompt, the dialogue configuration, and the code commit the record names as its producer. Two records are comparable only when their instruments are accounted for. A change to any source the instrument snapshot watches fails the test suite until it is written down; the three inputs the gate did not watch were brought under it on 2026-10-10 (D-029), and the rules history now lets a record made under an earlier instrument be checked against that instrument, not today's.

The topic packs the harness draws from are JSON files, written by hand and versioned in the repository; the model registry says which models exist, with stable keys, labs and retirement dates, and a retired model keeps its records. The Readout's Producers layer carries the live counts.

takes

a topic; the models; the instrument

gives

records that satisfy the contract, written once

establishes

what was askedwhat was saidunder which instrumentwhich code commit the record names as its producer

does not establish

that any model was rightthat the auditor was right

today

• Symposium: the orchestrator, the batch runner, the provider clientsoperational
• The instrument and its snapshot gate (also Assurance, read by the verifier through the rules history)operational
• The auditors roster and the family guardoperational
• Topic packsoperational
• The model registry (also Application, read by the Explorer for names and colours)operational
• The Judging Room, as a producer of human judgments (also Application, today: a reader with no judgment in the archive yet)experimental

named, not built

• The Evaluation Harness, a second producerdesigned
• The Analyzerdesigned

what would fail

A change to the sources the instrument snapshot watches, with no written snapshot, fails the gate.

depends on

Contract

sources

symposium/src/server › the harness
symposium/src/server/instrument-version.js › the instrument
symposium/docs/MODEL_REGISTRY.md › the three tables

Says what a record is, for every producer: identity, type, version, seal, index line.

What a record is, for every producer: seven identity fields that may never be empty, a registered type, a schema version, a seal over the exact stored bytes, and one line in the day's index. The contract is versioned and its schema gains fields only additively; the Readout's Contract layer reads the current version and its additive fields live. A record that satisfies the contract has an identity and a shape; whether what it says is true is not the contract's business.

takes

a record about to be written

gives

a record with seven identity fields that are never empty; a registered type; a schema version; a seal; one index line

establishes

identity and shape

does not establish

content

today

• The artifact contract and the envelope validatoroperational
• The schema reference and its additive fieldsoperational
• The envelope and index-line schemas the verifier applies (also Assurance, carried in every bundle and held to the harness's rules by test)operational

what would fail

validateEnvelope refuses the write; a schema change without a version entry fails the suite.

sources

symposium/docs/corpus/ARTIFACT_CONTRACT.md › the seven fields
shared/storage/layout.js › REGISTERED_ARTIFACT_TYPES; validateEnvelope

Holds the authoritative bytes and the commitments to them, and makes "never edited" checkable.

Where the records rest and what makes "never edited" checkable. The adapter writes each record once to a key built from its type, schema version and run type, computes the SHA-256 of the bytes as stored, and appends one line to that day's manifest: the key, the hash, the time, and an index summary. The manifest is append-only by rule: the day's file is re-uploaded whole with the new line, and no line in it is changed. The storage keeps every version of every object, so an overwrite would leave the original behind, and an independent reader with its own access re-hashes the whole archive against the index and records the result. Local disk and S3 behave the same.

The index line is custody evidence, not a view: it is never regenerated, and a record is checked against the line that was written for it. What the archive alone cannot show an outside party is that the line itself is authentic, since the record and its line are kept in one custody; that is the limit Assurance states on every result, and what an outside witness would one day close.

takes

a contract-valid record

gives

the bytes under a key built from the record's own fields; their SHA-256 on one line of the day's manifest; every version kept

establishes

that the bytes you receive are the bytes that were sealedthat an overwrite would leave the original behind

does not establish

that the index line itself is authentic to an outside party: the record and its line are kept in one custody

today

• The storage adapter, local and S3 the sameoperational
• The append-only manifests and the versioned corpus bucket (also Process, the bucket's policy and identities are the owner's console work)operational
• The censuses (also Process, each is a dated read of the whole archive)operational

what would fail

An independent reader re-hashes the whole archive against the index and records the result.

depends on

Contract

sources

symposium/src/server/storage › the adapter
judging-room/research › the census write-ups

Makes a record checkable by anyone with nothing of ours, and keeps the rules history honest at every release.

What makes a record checkable by anyone with nothing of ours. An evidence bundle packs one record with what a check needs: its index line verbatim, the instrument snapshot its code carried, the schemas, a checksum manifest, and the procedure in plain words. The verifier reads the folder and its own files, with the network unplugged, and says pass, partial, unresolved or fail, with a stable code on every check and, with every result, what is established and what no bundle establishes. Nine core checks run for every kind of record; a profile adds the checks for one kind; a kind with no profile is never a pass.

Which instrument a record was made with is resolved from the commit the record names, through the rules history the release carries: a map from every version of the code to the instrument snapshot in force then, regenerated by the promotion script from the repository's history at every release and checked against the previous release's. Four reference records, one of each kind the verifier tells apart, are checked live after a release that touches the verifier or the instrument.

The same checks run three ways: on the Readout, where our server fetches a record and checks it; on the command line, from a deploy commit of the repository; and at Verify, where a copy of the verifier generated from the same source runs in your own browser on a bundle you hold, with nothing uploaded. What a pass establishes, exactly: that the bytes match the carried commitment, and that the recorded instrument fields agree with the snapshot associated with the commit the record names. What it does not: that the producing process ran that commit, who published, when, an outside witness, custody integrity, or that anything the record says is true. Release control belongs here too: the promotion script writes the rules history and audits the deploy it builds on; a push that skipped it is caught by the next promotion and by CI, not prevented.

takes

a record; its index line; the instrument snapshot associated with the commit the record names; the rules history

gives

an evidence bundle; a verdict with a stable code on every check; what is established and what no evidence bundle establishes

establishes

that the bytes match the carried commitmentthat the recorded instrument fields agree with the snapshot associated with the commit the record names

does not establish

that the producing process ran the commit the record nameswho publishedwhenan outside witnesscustody integritythat anything a record says is true

today

• Bundles, the verifier, its profiles, the resolver, the exporteroperational
• The snapshot store and the rules history generatoroperational
• The browser copy and the Verify page (also Application, the page is where a visitor meets it)operational
• Release control: the promotion script, the audit, CI (also Process, the gate's hand; it catches a push that skipped the script, it does not prevent one)operational

named, not built

• The Typed Standards adapterdeferred
• Signatures, trusted timestamps, external witnesses, a public logdeferred

what would fail

Every fixture bundle gives the same result through the command line and the browser copy; a changed byte fails; the frozen 0.1 bundle still verifies.

depends on

Producer, Contract, Archive

sources

shared/assurance/README.md › the verifier
assurance/HISTORICAL_INSTRUMENTS.md › §12
/verify › the page

Views rebuilt from named authoritative sources, for finding, relating and counting; never the source.

Views rebuilt from named authoritative sources, for finding, relating and counting. Today that is the day's manifest files read into the Explorer's one-minute cache, the per-model profiles computed in the browser from the records loaded for them, the token and audit counts, and the Readout's history file, which is built from the repository's documents and held to them by test. Nothing general is built: no search index, no relational store, no graph, no vector index. The rule is stated before the first exists: a projection is a reproducible view over its sources and never the authority for them, so the first database will be a projection and not a second archive.

takes

the archive; the repository's documents

gives

derived views

establishes

nothing on its own; every view is derived

does not establish

anything its sources do not

today

• The Explorer's manifest cache, its counts and the profiles computed in the browseroperational
• Accounting: tokens and audits counted per recordoperational
• The history file and its generatoroperational

named, not built

• A search index, a relational store, a graph, a vector indexdesigned

what would fail

Delete a projection and rebuild it from its named sources; the history file is held to its sources by test.

depends on

Archive, Process

sources

explorer/src/storage-reader.js › the cache and the totals
explorer/scripts/build-history.js › the history file

Where people and programs read and use the evidence; no writes.

Where people and programs read and use the evidence; nothing here writes. The Explorer is the read-only window: a scene of particles, one per sealed conversation; a profile per model computed in the browser; a browse page for records, topics and health; the content pages; a JSON API that serves the same data to programs. It has no accounts, no cookies and no analytics. The Readout is the system in its own words, seven layers with four doors each and a door to check a record. Verify checks a downloaded bundle on the visitor's own device. The Judging Room is the human layer, built as a prototype: a person reads two AI responses to a situation they recognise, chooses, and says why, and the choice is sealed on their own device; no human judgment is in the archive yet, and when one is, the Judging Room will be a producer as well.

takes

the archive and its projections

gives

pages; a JSON API

establishes

a view

does not establish

a ranking: nothing here is a score

today

• The Explorer: scenes, profiles, browse, health, the JSON API, the content pages, short linksoperational
• The Readoutoperational
• The Verify page (also Assurance, the check it runs is the verifier's)operational
• The Judging Room (also Producer, its judgments enter the archive)experimental

named, not built

• The MCP server, a tool interface for assistantsdesigned
• The Workbench and the Atlasdesigned

what would fail

The public service's role is read-only; the API cannot write; the content policy names what runs.

depends on

Archive, Index / Projection, Assurance

sources

explorer › the Explorer
/readout › the Readout
/verify › the Verify page
judging-room/DESIGN.md › design law

Defines the rules for change, runs the tested promotion path, records decisions and disclosures, admits error, and detects a deployment that bypassed that path.

How the project decides and how it admits error. Rules, each naming what enforces it. A log of decisions. A disclosures record of public claims that were wrong, appended and never rewritten. A registry of open questions, each with a status and the condition that would settle it. Outside reviews, stored verbatim and answered in writing. The gate: one command runs every suite, on every push, and nothing is promoted while it is red. Promotion itself is on the owner's word, with nothing running, through one script that checks the deployed tree is the promoted commit and writes the rules history; the audit that follows every push to deploy catches a push that skipped the script, and does not prevent one. Process defines the rules for change, runs the tested promotion path, records decisions and disclosures, and detects a deployment that bypassed that path; the detection does not prevent every unauthorized deployment.

takes

a proposed change

gives

a rule with its enforcer; a decision entry; a disclosure; a review on file; a promotion on the owner's word

establishes

that a release made through the promotion path passed the gate and is the commit its build names

does not establish

that a decision was rightthat every push to deploy was authorized: a push that skipped the promotion script is caught, not prevented

today

• The rules and their enforcersoperational
• The decision log, the disclosures, the registry of open questionsoperational
• The outside reviews, stored verbatimoperational
• The Trust page and the machine specification (also Application, served by the Explorer)operational
• The promotion on the owner's word, with nothing running (also Assurance, the script writes the rules history)operational

what would fail

A red gate blocks a promotion; a push that skipped the script is caught by the next promotion and by CI.

sources

HOW_WE_BUILD.md › 4. The gates; 5. Who does what
OPEN_QUESTIONS.md › the registry
research/audits › the dated files

The things the system keeps, which can grow without the responsibilities above growing: a new kind of thing ordinarily means a new type and a verification profile of its own, without a change to the existing core checks.

Concerns that cross several responsibilities and are boxes nowhere. Each is described by its actual scope, never as a blanket property of the system.

Identity and authorization

none for readers; the harness's operator token and the Readout's token for the lab designed

Privacy

the public Explorer needs no reader account and runs no analytics; it holds client addresses and request times in memory for a short while to limit rates, and a wrong token is counted and logged by address; the rule that restricted information must never reach a public view is stated before any exists; nothing here establishes that every stored record is free of personal information, and the review and controls that would are designed, not built designed

Security

read-only roles for the public service, the deploy ruleset, the content policy (report-only), the rate limiter, pinned CI, no secret in the repository, outside reads operational

Interoperability

a standards map; compatibility never dependency designed

Operations

the services and their roles, the bucket's settings, the repository's rulesets and secrets: counts and dates only, names nothing operational (the Readout's Account door, behind the token)

A projection is a reproducible view over named authoritative sources. It never replaces, amends or becomes the authority for them.

authoritative

• the stored bytes of every record (the archive)
• every manifest line with its recorded commitment (the key, the SHA-256 of the bytes, the time, the summary as known that day) (the archive)
• the code, the rules, the decisions, the disclosures, the registry, the instrument snapshots and their store, the fixtures (the repository, by commit)

views

• the commit-to-snapshot map a release carries from the repository; regenerated by the promotion script from the repository's history and checked against the previous release's
• the Explorer's one-minute cache of the manifests, its counts and the profiles computed in the browser from the manifest lines and the stored bytes
• the Readout's history file: facts and dated events by layer from the repository; built from the repository's documents, not from the archive, and held to its sources by test
• the verifier's browser copy from the repository; generated from the verifier's sources unchanged and held current by test
• the running services from the repository; built by App Runner from a deploy commit
• a search index, a relational store, a graph, a vector index deferred from the stored bytes and the manifest lines; none built; the rule is stated before the first exists

The drawing below was made on 2026-10-04 and is kept as the implementation view: the parts a conversation passes through, in order, as they were then. It predates Assurance and the Readout and still says "eight live" where the registry has moved on; it is kept because the order it shows is still true. Every part on it sits inside one responsibility above, and the table under it places every component by responsibility, with its status.

The four seats sit on different layers, and the layers are one-way. Judgment can flow down into the debate; the debate can never flow up into the judgment; and every message that crosses a layer is in the record.

Two modes decide whether the downward channel is open. In treatment mode the auditor's summary is placed in each debater's context as a system message, and the record logs every such injection with the audit it came from. In observation mode the auditor reads and scores but says nothing to the debaters. Unattended batch runs default to observation, but most of the archive was run in treatment mode (the September census), so in most of it the auditor's summary did reach the debaters. The record's effectiveMode says which.

The auditor's instructions are a fixed constant; a debater's words reach it only as the material under review. The family guard records, in the instrument, when an auditor shares a lab with a debater, and refuses the same model auditing itself.

*Checked against the orchestrator, auditor, narrator and heuristics source on 2026-10-04. An older internal document, symposium/docs/FOUR_MODEL_ARCHITECTURE.md, says the narrator cannot see the auditor; the code passes the auditor's summary to the narrator, and this page follows the code.*