Chapter 7: The Marshaller

The Marshaller

Source: chandra-marshaller.html (UI, build v37, 2026-08-23); chandra-marshaller-attestation-console.html (companion tool, v18); ent-marshaller.lisp (source zip); marshaller.chandrahub.net (live-fetched, 2026-08-23).

The Marshaller is Chandra's organization-and-spine directory — a fleet-level registry that tracks where governed deployments are, without itself holding any of their governed data. Its own file header states its scope precisely: "organization → existing spine address registry."

Address-only persistence: what Marshaller actually stores

This is the architecturally load-bearing fact about the Marshaller, confirmed both in the live UI copy and in ent-marshaller.lisp's own design history: the spine address is the only thing Marshaller persists. The UI states this to the operator directly: "This is the only value Marshaller persists. VERIFY reads the responding spine live; the result is never saved here."

Everything else shown about a registered organization — instance name, build version, environment, personality ID, personality file, instance type — is a live read, fetched at VERIFY time from that spine's own /api/enterprise/self manifest, and explicitly discarded rather than cached. The UI's own field-level help spells out the consequence directly: "Read-only live result from the spine. Marshaller discards it and can reconstruct it again from this address."

Why this matters, and a real gotcha documented in the source history: because VERIFY is a point-in-time snapshot and not a subscription, a Marshaller org-detail view can go stale relative to the spine's current state — if a personality gets set directly on the spine after the last VERIFY, Marshaller's displayed view won't reflect that until VERIFY is run again. ent-marshaller.lisp's own v9 changelog entry addresses this directly: "Marshaller's org detail view was stale relative to a spine's current state (VERIFY is a point-in-time snapshot; re-running it is the only way to pick up a personality set directly on the spine afterward — not a bug, just how VERIFY works)." Treat a Marshaller view as "as of the last VERIFY," not as continuously live, and re-run VERIFY before trusting a detail that might have changed on the spine side.

The v9 changelog entry also confirms the breadth of what a VERIFY captures got fixed recently: earlier versions only captured a hand-picked subset of /api/enterprise/self fields; as of v9, the entire self response is embedded verbatim as one observed_self_json blob rather than requiring a new individually-named field every time self grows a key.

GR Marshaller vs. Client Marshaller

Two deployments of the same tool serve different scopes:

• GR Marshaller — General Reasoning's own fleet directory, tracking every organization GR has a relationship with. Live at marshaller.chandrahub.net, confirmed by direct fetch: its Help Index is explicitly labeled "LOCAL MARSHALLER ACACHE" in the UI (see Chapter 18), and its own marshaller-overview help context states its isolation from other surfaces directly: "Marshaller is the fleet-level discovery and observation surface. Its persistent registry authority is local to the Marshaller ACACHE. It does not read or write CEE or worker Help Contexts."
• Client Marshaller — the same tool, self-hosted by a client, tracking that client's own fleet of spines rather than GR's book of business. Nothing in the source distinguishes these as different code paths — it's the same product, deployed with a different (and much narrower) scope of organizations to track.

Registering and verifying an organization

The Marshaller workflow, per the live UI:

1. Add Spine Root (or Import — see below) — enter an organization name, a spine address, an optional Markdown description, a status (active/inactive/unverified/retired), and optional operator notes.
2. VERIFY — reads the responding spine live at that address and displays its manifest identity. Successfully verifying sets the registration's status to active automatically. There is no separate "Retire" action anymore — setting status to retired and saving takes the organization out of service the same way any other field edit does, and (per Chapter 1's governance principle) that save still appends a CU like any other edit.
3. Bulk import — one organization per line, tab-separated: Name, Spine address, and an optional Notes column. Re-running an import is explicitly safe: a name that already exists is updated, not duplicated, matching the regular single-entry save form's behavior. An optional toggle also runs VERIFY on each imported address automatically (fills in Type/Personality), at the cost of being slower and only working for addresses that are actually reachable at import time.

What Marshaller deliberately does not do

Marshaller does not proxy, mirror, or cache business data from the spines it tracks — it has no Hub/Spoke business records of its own beyond its own address registry, help content, and bug reports. It is a discovery and observation layer, not an aggregation layer: if you need to actually query or modify data on a registered spine, you go to that spine's own CEE or API surface (Chapter 9) directly. Marshaller's job ends at "here is this organization's current address and what its manifest says right now."

The Attestation Console

chandra-marshaller-attestation-console.html (v18, badge v10 in its own footer) is a companion tool: "API-backed registry telemetry" with an explicit caveat baked into its footer copy — "geographic observations are approximate and non-attested." This distinction is worth taking at face value: whatever this console shows is not itself a CU-backed attested fact the way a spine's own records are (Chapter 1) — it's observational telemetry about the fleet, presented with an honest disclaimer about its own limits rather than dressed up as governed data it isn't. Its precise relationship to the chandrahub.net attestation/GABA-cert narrative (Chapter 10) has not yet been confirmed directly and should be verified with James before this section is expanded further — the naming similarity ("attestation") is suggestive but not itself confirmation of a functional link.