A protocol for how information moves.

01 · Why Works exists

Business information systems have no shared architectural contract.

Every installation reinvents the same decisions: how data enters, where it lives, how it transforms, who authorizes its release, and how to prove any of it happened. Without a shared protocol, every integration is custom and every audit is uncertain.

Works provides the architectural vocabulary so that different installations can speak to each other, audit each other, and extend each other without renegotiating the basics every time.

02 · Our inspiration

Charles Babbage drew the map. Works follows it.

In 1837, Charles Babbage described the Analytical Engine — a mechanical computing machine whose architecture divided the work of computation into three named elements: the Store, which held numbers awaiting operation; the Mill, which performed the arithmetic; and the Barrel, the punched-card mechanism that sequenced the program itself. Babbage's insight was structural — that computation is not a single activity but a composition of memory, transformation, and control, each with a distinct role and a defined boundary between them.

Works inherits these names deliberately, not as ornament but as acknowledgment. The Store holds chunks. The Mill transforms them through a lens pipeline. The Barrel sequences the compound's operations as a stored program. More than a century and a half later, the architectural logic Babbage identified in the gears of a Victorian calculating engine persists intact — Works is one more expression of it, adapted for the compound movement of business information through authenticated, auditable, and authorized paths.

John von Neumann formalized Babbage's intuition in 1945: stored program, system bus, input and output units, the separation of memory from the processor. The diagram below maps Works onto that lineage. The nine buildings are not invented from nothing — they are placed in a tradition.

03 · What Works is

A protocol standard, not a product or framework.

04 · Core argument

The Stream is the source of truth. Everything else is derived.

If you can replay the Stream from the beginning and reconstruct the full operational state of the compound, you have a system that can survive any failure. That is the Pacioli guarantee — and Works makes it unconditional.

Works enforces this by requiring:

• Every state change recorded on Stream before it takes effect
• No chunk moves between buildings without a Stream event
• No chunk leaves the compound without Gate authorization
• Every action attributed to a named Actor
• Vault entries that are permanent and immutable

These are not configuration options. They are the compound's constitution.

05 · Nine buildings

A compound with nine roles — each defined once and frozen in v0.1.

Every Works installation is a compound of buildings. Each building has a defined role, a defined set of permitted interactions, and a defined Stream event vocabulary.

06 · Stream protocol

Three layers: Log, Bus, Replay — one constitutional guarantee.

The Stream is the Works compound's nervous system. It has three layers that serve distinct purposes:

Pacioli guarantee

The Stream Log is append-only. State is the cumulative record of all events from the beginning. No deletion, no modification, no unrecorded state change — ever. This guarantee is unconditional in Works-Standard v0.1.

Hollerith encoding

Every log line is a Hollerith record: five positional fields, a single-letter op code, and a Unix timestamp as the primary sort key. The log is sortable with sort -n -k1 alone — no schema file required.

07 · Conveyance

Every chunk movement is a Stream event. No exceptions.

Conveyance is the operational contract of the compound. The canonical path runs Intake → Store → Mill → Gate → Dispatch → Vault, but Works defines fifteen permitted paths in total.

• A Stream event is written before the chunk moves — the event is the authorization for the move
• Every conveyance appends a provenance entry to the chunk cross-referencing the Stream event
• Bench pulls from Store are not Stream events — Bench is pre-commitment working memory
• Store reads by Mill are non-destructive — the originals are unchanged
• A failed Stream Log write prevents the conveyance from proceeding; there is no unrecorded movement
• Split-brain states are resolved by completing the move, not rolling back — the Stream event is the authority

Prohibited paths

Eleven paths are explicitly prohibited, including: any path from Mill to Dispatch without Gate, External Actors writing to Store directly, Bench content going to Dispatch, and Vault entries returning to any building.

08 · Actors

Four types. Every action is attributed to a named Actor.

Anonymous actions are not permitted in a conforming Works installation. Every operation is attributed to a session and an Actor identity.

09 · Extension protocol

New building types register with Office as first-class compound members.

The nine core buildings are frozen in v0.1. The extension protocol is how Works grows beyond them — without modifying the core standard.

• An extension building declares one of six roles: input, storage, transformation, output, control, audit
• Registration requires a declaration, stream compliance statement, gate boundary proof, and Pacioli compliance demonstration
• Office issues a registration token; until then, the building is an External Actor
• Registered buildings emit only their declared op codes — violations trigger suspension
• The S register event is permanent on Stream; deregistration adds S deregister but never removes S register
• Extension is not a second-class tier — it is the incubator for future core buildings

10 · Standard family

Works-Standard is one layer in a coherent four-standard family.

11 · Document set v0.1

The current specification documents.

Click any document to read it inline. Each row links directly to the source file in the repository.

Documents 11–15 (Stream Lenses, BitPads binding, BitLedger binding, WW binding, Versioning) are in active drafting and will appear here as they land in the repository.

12 · How to use the repository

A short path from the standard to a conforming implementation.

1. Read 00-concepts.md first — it defines every term used across the spec set.
2. Read 02-stream-protocol.md and 01-chunk-format.md — Stream and Chunk are the two substrate layers everything else depends on.
3. Read 03-buildings.md for the nine building contracts, then 05-conveyance.md for the permitted paths between them.
4. Use 10-compliance.md as your implementation checklist — it consolidates all MUST requirements in one place.
5. If building an extension: read 09-extension.md for the registration requirements and op code assignment process.

v0.1 establishes stable building contracts, Stream invariants, and conveyance rules. Future revisions continue through proposal and review.