Chapter 2: What Chandra Enterprise Is

What Chandra Enterprise Is

Source: chandra-enterprise-editor.html (build v31c425+); ent-hub.lisp, ent-tree.lisp, ent-spine.lisp (source zip); vatican.chandrahub.net (live-fetched, confirms the environment-root model described below).

Chandra Enterprise (CEE) is the application layer built on Chandra Protocol. If Chapter 1's protocol is the ledger, CEE is the database-plus-UI that regulated organizations actually work in day to day — and it is deliberately shaped like a FileMaker-generation business database (Chapter 12 documents the operational parity directly: Sort, Found-Set operations, Found navigation, Duplicate, Import/Export, Portals) rather than a bespoke enterprise app, because that's a UI paradigm regulated-industry staff already know.

The data model: Hub and Spoke

CEE's schema vocabulary is Hub and Spoke:

• A Hub is a governed table — a business object type (e.g., "Loan Applications," "Vendor Contracts," "Holy See Apostolic Acts" — see Chapter 6's Vatican personality example). A Hub carries a Form Design (Chapter 14): the field schema, validation rules, and layout that every record in that Hub conforms to.
• A Spoke is a governed row — one record inside a Hub, with its own CU chain (Chapter 1), its own lifecycle state (active/archived/deleted — Chapter 12), and, if it's a child record, a parent Spoke it's attached to (the mechanism behind Chapter 12's Related-Record Portals).

This is a deliberately narrow vocabulary. ent-environment-roots.lisp reserves a small, closed set of Spoke types — hub-info, form-design, help-context, bug-report, attachment, integration-genesis — meaning even CEE's own internal machinery (its help content, its bug-report system, its file attachments) is represented as governed Spokes inside the same Hub/Spoke model business data uses, not as a separate privileged internal data layer. There is no backstage.

Environment roots: Acceptance and Production

Every CEE spine has (at minimum) two environment roots: Acceptance and Production (ent-environment-roots.lisp — *ent-environment-roots* is literally '("acceptance" "production")). This is confirmed live on vatican.chandrahub.net, whose UI shows a SPINE / CANARY / PRODUCTION toggle. Acceptance is where a spine configuration is tested; a distinct "Accept Acceptance Spine" action (seen live) commits the current test spine as the accepted source for Production — the confirmation dialog is explicit that this only sets up what Production should look like, and that "Production creation or any later Production change remains governed by the Production/Concordia rules," i.e., promoting to Production is its own separately-governed act, not a side effect of accepting an Acceptance spine.

Help and Bug Reports are root-scoped — each environment root gets its own Help/Bug-Report Hubs, per the boot-log comment in start-enterprise.lisp: "environment roots — Acceptance/Production anchors with root-scoped Help and Bug Reports Hubs." This is a smaller, earlier instance of the same isolation instinct documented at length in Chapter 18: don't let content homed in one governance context bleed into another, even within a single spine.

What CEE adds on top of the protocol

Chapter 1 draws the line already, but concretely, CEE is what turns "an append-only attested chain" into something a compliance analyst can actually use:

• Forms (Chapter 14) — schema, field types, validation, and now (as of build v31c425) calculated fields (Chapter 12 §8)
• Browses — the found-set/sort/navigation toolbar documented exhaustively in Chapter 12, which is CEE's entire day-to-day surface for a working analyst
• Reports and exports — CSV and, as of the same build, PDF generation (Chapter 12 §9)
• Governed automation — Trigger Definitions (Chapter 12 §10), which is how CEE does auto-entry and cross-field validation logic without ever exposing a free-form scripting surface (the save path explicitly pattern-matches and rejects anything that looks like injected code)
• Related-table modeling — sub-Hubs (Chapter 12 §7), created through a governed /api/enterprise/sub-hub/create call, not a schema-migration side channel

None of this exists at the protocol layer. Chandra Protocol doesn't know what a "Form Design" is; CEE is the layer that decided a Hub needs one, and that a form's publish should itself be a CU.

CEE is not the only thing built on the protocol

It's worth being explicit that CEE is a product on Chandra Protocol, not the product. The Marshaller (Chapter 7) and Chandrahub (Chapter 10) are both separate applications sitting on the same protocol, with their own Hub/Spoke-shaped internal data (per Chapter 18's Help-content architecture) but serving entirely different jobs — fleet discovery and public governance reference, respectively, rather than line-of-business record-keeping. When this manual says "governed," it means governed the Chapter 1 way, regardless of which of these three products is doing the governing.