Chandrahub — The Governed Deployment Network
Source: chandrahub.net homepage (live-fetched, 2026-08-23); marshaller.chandrahub.net and vatican.chandrahub.net (live-fetched, confirming the multi-org pattern); James, directly, on the narrative positioning below. The doc subpages linked from chandrahub.net's own nav (Understanding Chandra, Being Audited, Auditing with Chandra, Examiner Reference, Standards, Compliance) all returned HTTP 404 as of this fetch — only the homepage is live. Revisit this chapter once those pages exist.
Chandrahub is described on its own homepage as "the forest authority for every governed Chandra deployment." It sits above the Marshaller (Chapter 7) conceptually — Marshaller tracks one organization's (or GR's own) fleet of spine addresses; chandrahub is the broader, public reference point that any Chandra deployment, anywhere, can point an examiner at.
chandrahub.net itself is the open beta — General Reasoning's own public instance, the entry point for organizations evaluating or beginning a Chandra deployment. Confirmed live and reachable: vatican.chandrahub.net, lockheed.chandrahub.net, and anthropic.chandrahub.net are each running what appears to be a full spine (the Vatican instance shows the same Acceptance/Canary/Production toolbar documented in Chapter 2, at build v31c444).
This is where the narrative needs to be stated carefully, per James directly, rather than left to the subdomain examples to imply on their own: chandrahub.net is simply the site hosting the public beta test. It is technically capable of multi-tenancy — the subdomain pattern above could look like a multi-tenant SaaS offering at a glance — but that is explicitly not the story this manual tells, and not the end-state General Reasoning is selling. Shared tenancy is itself a violation of the CRC standard's own Consolidate/Close pillars (Chapter 5): a shared hosting boundary is exactly the kind of unowned, traversable edge CRC exists to eliminate, regardless of how well-isolated the tenants' data is within it (see the next section). Standalone servers — for example, dedicated instances on Linode — are a legitimate interim deployment shape for a client not yet ready to run their own hardware. But the actual end-state offer to a client that wants real control and security is a sovereign, self-hosted deployment running their own AegisGenera boundary (Chapter 19) — not a seat on General Reasoning's shared infrastructure, however well-partitioned. Document chandrahub.net's multi-org subdomains as a beta convenience and a demonstration of the architecture's generality (Chapter 6 makes the same point about the Vatican personality), not as evidence of a multi-tenant product direction.
Every organization's data on chandrahub — and in the Chandra architecture generally — is isolated, which directly serves the CRC/ISS formula (Chapter 5) and enables fine-grained segmentation. It's worth naming the second reason this matters, stated by James directly, because it's a distinct argument from the security one and easy to under-weight: isolating each organization's chronicle (its CU chain history, Chapter 1) independently gives the best realistic chance of recovering it intact, regardless of that organization's complexity, physical size, or database size. A monolithic shared store makes disaster recovery an all-or-nothing proposition — one corruption event, one bad restore, one operational mistake can threaten every tenant's history at once. Per-organization isolation means a DR event's blast radius is bounded to the organization(s) actually affected. This is the same underlying posture — isolate everything down to fine-grained, independently-recoverable segments — that also drives Chapter 18's Help-content architecture; security and disaster recovery turn out to want the same shape of system for related but distinct reasons.
Chandrahub.net's stated role, regardless of whether a given deployment is the open beta or a client's own sovereign instance: it is the stable public reference the examiner reference lives at permanently. It's the URL printed on a GABA cert (Chapter 11); it's where an examiner starts, and it does not move even if the underlying deployment they're examining is running entirely on the client's own infrastructure elsewhere.
The site names three distinct audience-specific documentation tracks, planned but not yet live as of this fetch: - Examiner Reference — for regulators verifying GABA certs, reading CUs, and tracing audit opinions to work papers, written for someone with no prior Chandra knowledge. - Auditing with Chandra — for auditors, covering SSAE 18 engagement types, governed work papers, opinion issuance, and chain of custody. - Being Audited — for organizations, covering what their audit trail contains, how to produce evidence for examiners, and retention policies by standard.
Two pieces of vocabulary get their first plain-language public statement on this site, worth using consistently rather than the internal shorthand elsewhere in this manual:
The Spine UI's "ANDON ALL" control, visible live on vatican.chandrahub.net, is not fully developed yet (confirmed by James directly — see also Chapter 8). Don't describe it as operational in this chapter or elsewhere until that changes.
The doc subpages (Standards, Compliance, and the three audience tracks above) should be re-fetched and folded in once they're live — this chapter currently reflects only what the homepage states, plus direct clarification from James on positioning. The relationship between chandrahub's attestation model and the Marshaller Attestation Console (Chapter 7, Chapter 16) also has not been confirmed and shouldn't be assumed from naming alone.