Chapter 1: What Chandra Protocol Is

What Chandra Protocol Is

Source: chandraprotocol.org (referenced throughout the ecosystem; live-fetched 2026-08-24 for the five-primitives section below); ent-crud.lisp and related schema files (source zip, chandra20260823.zip); chandrahub.net homepage and chandrahub.net/deployments.html (live-fetched, 2026-08-23), the first places the underlying record type is spelled out in plain language for a non-technical audience; chandraprotocol.org/blockchain.html (live-fetched, 2026-08-23) for the blockchain-comparison section below.

Chandra Protocol is the governance layer underneath everything else in this manual. It is not a product you install by itself so much as a discipline every other Chandra system is built to honor: every act — every human decision, every agent action — produces a record at the moment it occurs. Immutable. Attributed. Hash-sealed to its predecessor.

The protocol's own official banner (chandraprotocol.org), reproduced here because this is the chapter it actually describes. Note the license line: MIT LICENSE · v17.0 · General Reasoning, Inc. — this applies to Chandra Protocol specifically. It does not apply to Chandra Enterprise, the Marshaller, chandrahub, or anything else this manual documents past this chapter; see Chapter 3 for exactly where that boundary sits.

The CU: Chandra's unit of record

The fundamental unit is the CU — a Context Unit (chandrahub.net is the first source to spell the acronym out plainly; internally and in code comments it's usually just "CU"). A CU is:

• Attested — it names who or what performed the act (a human, an agent, a service account — see Chapter 5's principal definition, which is Chandra's precise vocabulary for "who")
• Hash-sealed to its predecessor — each CU's hash incorporates the previous CU's hash, forming a chain. Altering a past CU would break every hash after it, which is what makes the chain tamper-evident rather than merely tamper-logged
• Append-only — there is no update-in-place operation on a CU once written. A correction is a new CU that supersedes an old one, not an edit to the old one. This is the single most consequential design decision in the whole system, and nearly everything else in this manual traces back to it: Chapter 12's soft-delete/archive/restore lifecycle exists because you can't actually delete a record's history, only its current visibility; Chapter 9's optimistic-locking pattern (loaded_tail_hash) exists because a write has to reference the specific point in the chain it's building on; Chapter 12's Trigger Definitions publish as CUs for the same reason a Form Design publish does — anything that changes system behavior is itself an attested act.

"The record is not a receipt. It is produced simultaneously with the act it records." (chandrahub.net's own framing.) This is the distinction worth sitting with: a conventional audit log is written about an action, usually by a different system, sometime after the fact, and can in principle be edited or deleted by whoever has database access to the logging system. A CU is not a log entry describing the action — in Chandra's model, the CU-write is the action's completion. Chapter 12's records/create endpoint doesn't "create a record and then log it" — the record's existence and its genesis CU are the same event.

Chandra's five primitives

Chandra Protocol's own site states plainly that the CU is one of five primitives, not the whole story — worth documenting properly rather than letting this manual imply Chandra is just "the CU plus a chain," which undersells two primitives (Snapshot, Tickler) that don't come up naturally anywhere else in this manual and would otherwise go completely undocumented.

1. Context Unit — Atomic, immutable append. One artifact. Full attribution. Always. (This is the CU as described above.)
2. Lineage Chain — Ordered, hash-sealed sequence per governed subject. Tampering is detectable. Broken chains halt new appends. (This is what the rest of this manual informally calls "the chain" or "CU chain" — Lineage Chain is the precise term.)
3. Attribution Record — Every CU carries who acted — human, agent, or system. Anonymous appends are rejected at the protocol level. This is the formal name for the "Attested" property listed above; Chapter 5's principal vocabulary is what populates it.
4. Snapshot — Complete, AI-readable reconstruction of any subject at any point in history. No replay required. Not documented elsewhere in this manual: this implies Chandra doesn't require walking an entire Lineage Chain from genesis to reconstruct a subject's current (or historical) state — a Snapshot is a first-class, directly queryable artifact in its own right, not something every consumer has to derive by replaying every CU. Nothing in the source reviewed so far describes when a Snapshot is generated (on every append? on demand? periodically?) — that's a real gap worth closing once there's source to verify against.
5. Tickler — A forward-scheduled CU with a trigger time and a target. Described as "the federation primitive." Cancellation is a superseding append, not a deletion — consistent with the append-only discipline above (Chapter 1's "correction is a new CU, not an edit" rule applies to scheduled future actions too, not just past ones). Also not documented elsewhere in this manual, and its description as "the federation primitive" suggests a connection to Chapter 10's chandrahub/forest concept and the "Cross-Forest Trust Protocol" referenced as forthcoming on chandrahub.net's Standards page — but that connection is speculative, not confirmed, and shouldn't be treated as established until there's real source describing how Ticklers actually cross a forest boundary.

Primitives 4 and 5 (Snapshot, Tickler) are genuinely new territory for this manual — nothing elsewhere here describes either one operationally. Treat them as named-and-defined but not yet operationally documented, the same honesty standard the rest of this manual applies to unbuilt features — the difference here is these primitives are stated to exist at the protocol level already, just not yet walked through in this manual.

Why append-only is the whole point

An append-only chain converts a hard question — "can I trust this history?" — into an easy one — "does this hash chain verify?" You don't have to trust the operator's honesty going forward; you can check the math. This is what lets Chapter 10's audience (examiners, auditors) verify a GABA cert or trace an audit opinion back to its work papers without taking anyone's word for it, and it's what makes Chapter 9's migration-verification pattern (checking chain/index after a write, not just trusting the HTTP 200) a meaningful practice rather than theater.

It also explains a few things that might otherwise look like limitations elsewhere in this manual: - Why CSV import (Chapter 12) is add-only with no update/upsert path — an "update" that silently overwrote history would be exactly the kind of edit-in-place the whole chain exists to prevent. A correction goes through the same append-only records/update call as any other change, producing its own CU. - Why a locked/published Calculated Field formula (Chapter 12) or Form Design can't be edited in place — the discipline of "retire, don't rewrite" is Chandra Protocol's append-only principle applied to schema, not just data.

What governance means concretely

"Governed" is used loosely across the industry to mean almost anything about oversight. In Chandra's vocabulary it means something specific: every mutation is an attested, chained fact, full stop — not "most mutations get logged," not "mutations above a certain sensitivity get reviewed." Chapter 9 documents the one real gap in this story as it stands today: request-level authentication and access control are not visible anywhere in the current source (confirmed by direct search of the source zip — no bearer tokens, no API keys, no auth middleware). Chandra Protocol governs what happened, completely and verifiably; it does not yet, on its own, govern who was allowed to make it happen at the network-request level. That's a real, open architectural gap worth naming rather than glossing over, and it's presumably part of what AegisGenera (Chapter 19) and Chandra Passport (Chapter 15) are meant to close once they exist.

Why Chandra is not a blockchain

This is worth addressing directly because the word "immutable" reliably makes people reach for the wrong comparison. Chandra Protocol's own site (chandraprotocol.org/blockchain.html) states the distinction more precisely than this manual could paraphrase it, so most of what follows tracks that page closely.

Blockchain and Chandra use the same primitive — a hash chain — to solve different problems. Blockchain answers how do mutually distrustful parties agree on a shared ordered ledger without a central authority? That's a real problem, but it isn't a regulated enterprise's problem. Chandra answers how does an organization prove what a governed human, agent, system, or process did, under what authority, at the moment it happened? A regulated firm already has an accountable, named institution — it doesn't need to eliminate trust in that institution, it needs to make that institution's own actions provable. As the source puts it: "Blockchain tries to eliminate the need to trust an institution. Chandra makes the institution's actions provable."

Concretely, this means Chandra has no need for miners, validators, staking, gas, mempools, or global transaction finality — none of blockchain's adversarial-consensus machinery. It needs the opposite set of properties: identity binding, authorization evidence, schema conformance, role/scope capture, policy references, contemporaneous event production, hash continuity, and examiner-readable reconstruction. Blockchain's ideal is that no central authority can control the ledger; Chandra's ideal is nearly the inverse — every authority is explicit, attributed, bounded, and auditable. A regulator does not want to hear "the decentralized network did it" — they want to know which person, system, policy, or approval path caused an outcome, and Chandra is built to answer exactly that question.

Topology reflects this difference directly. A blockchain's vocabulary is network → nodes → blocks → transactions. Chandra's vocabulary is marshaller → instance → domain → hub → spoke → context unit (Chapters 2, 4, and 7 cover instance/hub/spoke/marshaller in detail; domain as a distinct governance boundary — e.g., an FDA design-control spoke versus a FINRA supervision spoke being different regulatory realities, not just different transaction streams — is a term worth tracking as this manual's chapters on the Spine and Hub/Spoke model are revised). An auditor essentially never asks "show me the entire global ledger" the way a blockchain explorer would answer; they ask "show me the record for this control, this exception, this authorization" — which is exactly what a Spoke's own reconstructible CU chain (Chapter 1, above) is built to answer directly, without reconstructing anything from a global transaction stream.

External anchoring is optional, not constitutive. Chandra chains can optionally anchor a root hash or daily digest to an external ledger, which makes later tampering harder to deny — but that's supplementary evidence, not the governance mechanism itself. Chandra may anchor to external ledgers; it does not outsource governance to them. A blockchain can prove a hash existed at a point in time. Chandra proves what that hash meant inside a governed system — who acted, under what authority, against what policy, with what evidence.

This chapter covers the protocol layer only — the CU, the chain, the attestation principle. Chapter 2 covers Chandra Enterprise, the product built on top of it (Hubs, Spokes, forms, browses). Chapter 5 covers CRC, an independent standard that happens to be the design philosophy behind why Chandra's deployments look the way they do, but which is not itself part of the protocol. Don't conflate the three — Chandra Protocol is the ledger; CEE is the application; CRC is the architectural doctrine that says how few, how isolated, and how closed the deployment of that application should be.