The Audited Computer: Choir After the Deck

Status: published\ Source base: June 24 Choir deck; go-choir vision and doctrine docs through June 28\ Core claim: Choir is an audited computer system; the newspaper is the first public proof.

The June 24 Choir deck was right. It said the thing plainly: own your artifacts, own your learnings. It framed Choir as an object-driven, self-improving mainframe you own; a desktop whose apps are views over one substrate; a system where documents persist, version, cite, and compound instead of dissolving into chat exhaust.

That was already a better frame than “AI workspace.” It said the useful unit was not the prompt or the response. The useful unit was the artifact: the mission document, the source-backed draft, the published page, the version history, the evidence chain, the promotion record.

But the concept has tightened since then.

The deck still separated the system into three projections: mainframe, data, distribution. That is useful for a pitch, but it hides the more important claim. The deeper system is not three products stitched together. It is one object model with different projections.

The object is Texture.

The arrow is transclusion.

The state change is a typed transaction.

The computer is the replay of those transactions through a known version of Choir.

That is the upgraded thesis:

computer = choir_code(artifact_program)

The artifact program is the transaction history: the textures, revisions, transclusions, file changes, data mutations, source records, promotions, rollbacks, and evidence packets that describe why the computer is in the state it is in. The current disk image is not the source of truth. It is a cache: the output of computing the program.

This is what I mean now by an audited computer.

Not a computer with logs attached. Not a compliance layer added after the fact. A computer whose state is itself a readable, replayable, typed program.

From artifact desktop to texture category

The old software categories are too small. “Document,” “article,” “edition,” “styleguide,” “algorithm,” “renderer,” “schedule,” “source brief,” and “computer state” sound like separate types because most systems store them in separate boxes.

Choir’s newer vision collapses that separation.

A Texture is a generic versioned artifact with transclusion. That is the whole type system. An article is a Texture. An edition is a Texture. A styleguide is a Texture. A source brief is a Texture. A renderer can be a Texture. A publication schedule can be a Texture. A user’s computer can be represented by Textures that transclude its file manifest, structured state, configuration, and code version.

What distinguishes one object from another is not a type tag. It is its morphism structure: what it transcludes, what transcludes it, and what transformations preserve its relationships.

An article is not “an article” because some database row says kind = article. It is an article because it transcludes sources, claims, entities, prior drafts, publication metadata, and appears inside editions.

An autopaper is not “an autopaper” because a product manager invented a new noun. It is a Texture that transcludes an algorithm, a styleguide, a schedule, a renderer, and context Textures, then gets transcluded by edition Textures produced on each cycle.

A renderer is not outside the graph. It can be code held in a Texture. A custom domain does not need a separate CMS. The domain resolves to an autopaper; the autopaper resolves to the renderer, algorithm, styleguide, and edition chain; the frontend becomes a thin loader over the graph.

The surface changes. The substrate does not.

This is why the web desktop, the newspaper, and the future radio are not separate product ontologies. They are projections of the same category. Every app is a view onto the same work. Every publication is a projection of the same artifact graph. Every public page is a rendered path through transclusions.

The autopaper is the public proof

The first obvious application is the automatic newspaper.

The deck described Universal Wire as a live, cleaned, provenance-rich knowledge base that agents consume instead of re-deriving the world per query. That remains correct. A private AI loop cannot live on private data alone. Firms and individuals need the world: rulings, markets, papers, news, social sentiment, local events, arguments, corrections. But queries themselves reveal intent. Even with private inference, asking a hosted system the wrong question can disclose the work.

So the public/shared corpus matters. The system reads the world once, cleans it, cites it, versions it, and makes it available as public material that private agents can use without leaking private questions.

The newer concept goes further: do not just read the public newspaper. Publish your own autopaper.

An autopaper is an owned editorial machine. You define what it watches, which entities it follows, what sources it trusts, what voices it centers, what style it writes in, and what context it carries forward. Choir’s agents run the source-to-Texture pipeline under that editorial stance and produce editions.

This is not personalization in the shallow sense. It is not “take the same article and rephrase it in my tone.” The styleguide is a generative input, not a projection filter. Style implies substance.

A publication’s style determines what it sees. It determines who gets centered, which events are treated as important, which sources are quoted, which claims are interrogated, and which blind spots are accepted. Rolling Stone and The Economist can cover the same summit, but they do not merely use different adjectives. They point the camera at different people.

That means each autopaper is a perspective: a coherent allocation of attention.

No perspective sees everything. That is not a defect in the system. It is the premise. Attention is finite; style implies substance; substance implies blindness. The public value of the network is not neutral content from nowhere. It is a portfolio of perspectives whose blind spots do not perfectly align.

When many autopapers cover overlapping events, the graph becomes more valuable than any single feed. You can see who transcluded what, which claims recur, which sources are shared, where one perspective ignored what another centered, where a story was faithfully carried forward because it mattered beyond editorial framing, and where a new article is genuinely new because its upstream context was different.

That is an automatic newspaper worth building: not an infinite content mill, but a public graph of situated attempts to become less deceived.

The private proof is the audited computer

The public proof is the newspaper. The product is the audited computer.

The old computer is an opaque state machine. It accumulates files, settings, databases, caches, package installs, source trees, local builds, sessions, and hidden side effects. You back it up by copying blobs. You migrate it by moving blobs. You audit it by taking snapshots and diffing accidents. You trust it because you have no better option.

Choir’s claim is different: promote typed artifacts, not opaque machine accidents.

A user’s computer should be reconstructible from its program:

• the Choir code version, including its dependency inventory;
• the artifact program version, including its mutation transaction history;
• the content-addressed blobs, source records, structured state, file manifests, and configuration Textures that the program references.

Given those inputs, another node should be able to compute the same computer. Deployment becomes recomputation. Migration becomes recomputation. Replication becomes sending the program, not copying the opaque output. A disk image may still exist, but it is no longer sacred. It is a derivation product.

This is the same leap Nix made for software, extended from the package layer to the state layer. Instead of “something is installed on this machine,” you have an expression, inputs, hashes, and a reproducible output. Choir wants the same discipline for the user’s actual computer: files, app state, agent work, publications, candidate worlds, and promotions.

That is why SBOMs matter here. They are not enterprise theater. The code side of the equation must be inventoried. If choir_code_vN(artifact_program_vM) computes a computer, then choir_code_vN has to be knowable: dependencies, versions, licenses, build inputs, and supply-chain facts. The program side has to be knowable too: who changed what, when, under which authority, with which inputs and outputs.

Auditability becomes native. Compliance becomes a query over the tape. Reproducibility becomes a build property. Tamper evidence becomes a Merkle property. Portability becomes a consequence of computing from inputs rather than worshiping outputs.

The tape is not a log

The hardest shift is psychological.

A log records what happened after the real thing happened somewhere else. It is secondary. It is evidence, but it is not the operating medium.

The artifact program is not a log in that sense. The tape is read and written by the system. The computer reads its current state, acts, observes the result, writes a transaction, and then later reads that transaction as part of the state it must compute from.

That means the tape is both computation history and learning history.

A texture revision is a computation step. A promotion is a conjecture tested by execution. A rollback is a verdict. A source citation is an evidentiary edge. A candidate computer is a proposed future. A published article is a committed object in the public graph. A correction is not a vibe; it is a transaction that changes what future work can rely on.

This is why long-running agents need documents, not just threads. A chat transcript records the conversation. A Texture carries the current belief, the evidence, the open uncertainty, the proposed next state, and the promotion gate. It can be revisited by a human and advanced by an agent. That dual property is the whole point.

The document is the control plane because the document is where belief becomes state.

Why now

Three things changed at once.

First, model memory and training pressure make sovereignty unavoidable. If frontier systems retain everything, valuable work cannot be treated as disposable prompt traffic. High-context work has to remain inside an owned loop.

Second, consensus arrived around the learning loop. The important intellectual property is not only the current answer. It is the accumulated context, corrections, sources, taste, decisions, and operating habits that make tomorrow’s answer start higher.

Third, agents now do real work for long enough that the compounding becomes material. A system that runs for minutes can get away with a transcript. A system that runs for hours across tools, files, sources, versions, candidates, verifiers, and publications needs durable artifact state.

This is the gap between chatbot productivity and operational capital.

A chatbot helps you do work. An audited computer becomes the machinery through which the work is done, remembered, verified, improved, and published. It is not labor replacement in the crude sense. It is institutional-capital replacement: the private archive, the editorial desk, the operating system, the source room, the reviewer, the publication surface, the promotion protocol, and the memory of what has already been learned.

What to watch

The test is not whether Choir can produce more demos. The test is whether the same substrate keeps absorbing more of the real system without changing ontologies.

Watch for these transitions:

• editions become per-cycle Textures instead of a sliding window over a singleton feed;
• the Wire API becomes graph traversal rather than special-case document reading;
• Qdrant and corpus publication become functors over the Texture graph, not bolt-ons;
• autopapers become real owned objects that transclude algorithm, styleguide, schedule, renderer, and context;
• renderer code becomes versioned artifact state instead of a hardcoded frontend exception;
• user computers become replayable from artifact programs rather than protected only by opaque disk images;
• promotion and rollback become typed transaction verdicts at every level: document, app, computer, platform, doctrine.

Each step is independently valuable. But the important part is that each step should reduce special cases. A new app should not create a new ontology. A new publication surface should not create a new CMS. A new private computer should not create a new state theory. The whole point is one substrate, many projections.

The claim

The June 24 deck said:

Own your artifacts.
Own your learnings.

The June 28 vision sharpens that into a systems claim:

Own the program that computes your computer.

If the state of your computer is an opaque accident, you do not own the learning inside it. You own a fragile output. You can back it up, rent it, screenshot it, export pieces of it, or beg a vendor to remember it for you.

If the state of your computer is a typed, replayable, auditable artifact program, then the learning can compound under your control. The same graph can generate a private workspace, a public newspaper, a radio traversal, a source corpus, a publication network, and eventually an economy of citations and rights.

That is the actual product vector:

automatic computer -> automatic newspaper -> automatic radio -> automatic capital

Not four products. Four projections of one self-authoring artifact system.

The newspaper matters because it proves the machine can read the world, synthesize public artifacts, preserve provenance, and distribute into the graph. The desktop matters because it gives the human a place to steer the machine through artifacts rather than chat. The radio matters because traversal becomes ambient and screenless. The capital layer matters because durable public artifacts, citations, attention, and rights eventually become economic state.

But the center is the audited computer.

A computer you can read.

A computer you can replay.

A computer whose every meaningful byte has a reason.

A computer that learns by writing its own program, under evidence, provenance, verification, promotion, and rollback.

That is the new level of information technology Choir is trying to build.