Chapter 5: The CRC Standard and Isolation Surface Size

The CRC Standard and Isolation Surface Size

Source: crcstandard.org homepage and /scoring.html (live-fetched, 2026-08-23); isolation-surface.html (crcstandard.org, uploaded copy); personality-vatican-8level.json's crc_isolation_policy block. CRC is independent of Chandra — it's an open standard General Reasoning publishes, MIT-licensed v1.0, that happens to be the design philosophy behind why Chandra deployments look the way they do.

CRC — Consolidate, Reduce, Close, Boundary — is General Reasoning's published Minimum Surface Standard for AI-era regulated infrastructure. Understanding it is a prerequisite for the rest of this manual's architecture chapters: the Spine (Chapter 4), the Industry Configurator's scope boundary (Chapter 6), the Spine Editor's actual job (Chapter 13), and the entire per-surface isolation posture in Chapters 10 and 18 are all downstream of this standard's argument.

The Dunbar Perimeter

CRC's argument starts from a claim about human cognition, not computers. Anthropologist Robin Dunbar observed that humans can maintain stable relationships with roughly 150 people before cognitive load becomes unmanageable. CRC extends this to systems: a CISO can hold one application's architecture in their head with clarity, maybe two — by five or ten interconnected platforms, they're past what human cognition can manage.

So organizations partitioned by team: the Salesforce team secured Salesforce, the SAP team secured SAP, the identity team secured Active Directory. Each team felt like a perimeter. CRC calls this the Dunbar Perimeter — a security boundary created not by architecture, but by the cognitive limit of the humans responsible for it. It was never a real control plane; the systems were always connected, the connections just weren't fully seen.

The SaaS business model industrialized this. Every vendor sells a best-of-breed, independently-certified, independently-secured solution for one domain — and every one of them connects to all the others. Each integration, each SSO connection, each shared data flow crosses a Dunbar Perimeter and is secured by no single owner. Individually secure SaaS systems can compose into a collectively insecure architecture.

This was survivable as long as the attacker had a Dunbar limit too — a human attacker, even a sophisticated one, could only hold so many systems in their head at once, and picked targets accordingly. CRC's stated reason this no longer holds is Anthropic's Mythos model: a model with no Dunbar limit, that doesn't partition systems into cognitive domains, doesn't fatigue, and doesn't privilege one context over another — it constructs and traverses the full dependency graph across identity systems, SaaS platforms, and data flows simultaneously and autonomously. The connections that were always there, running through every integration boundary that nobody owned, become first-class attack paths the instant something can see the whole graph at once. "If Mythos cannot reach it, Mythos cannot chain it" is CRC's stated design objective, and it's the reasoning behind the isolation choices documented throughout this manual — including, per James directly, why system Help content itself is split by authority rather than kept in one store (Chapter 18): a monolithic store is a graph node, and a graph node is something Mythos can reach.

The Governed Server Boundary Prerequisite

Before any of the four pillars apply: CRC assessment applies exclusively to governed server deployments under formal organizational control. End-user devices, developer workstations, and any environment where AI agents with computer-use capability operate outside a governed boundary are out of scope. If that prerequisite isn't met, a CRC score is not zero — it is inapplicable. This is a scope gate, not a caveat to note in passing; a deployment that fails the prerequisite isn't "scoring poorly on CRC," it's not a CRC-assessable system at all until the boundary condition is fixed.

The four pillars

CRC scores a deployment 0–4 on each of four pillars, for a total of 0–16. Regulated deployment certification requires 13 or higher.

01 Consolidate — How many integration boundaries exist between regulated-workflow apps?

• 0 (Uninspected): Multiple apps, boundaries unowned, uninventoried
• 1 (Inventoried): Boundaries documented, ownership assigned, data flows mapped
• 2 (Controlled): Boundaries owned, monitored, traffic logged, API contracts enforced
• 3 (Consolidated): Majority of workflow on one governed platform, remaining boundaries are conscious decisions
• 4 (Minimal): Single governed platform, zero unowned boundaries, every data flow is an immutable attributed audit record

02 Reduce — What's in the production execution environment beyond the app itself?

• 0 (Uninspected): General-purpose OS, full package universe, shell accessible
• 1 (Inventoried): Services documented and pruned, OS hardened to a benchmark (CIS/STIG), shell restricted and logged
• 2 (Controlled): Containerized, no package manager in production, break-glass-only shell
• 3 (Reduced): Purpose-built OS image, no shell binary present, read-only root filesystem, signed boot chain
• 4 (Minimal): TPM-attested measured boot, immutable filesystem, the application is the OS

03 Close — What can reach production from outside the governed boundary?

• 0 (Uninspected): Public-facing services, unrestricted egress, ports open by default
• 1 (Inventoried): Firewall rules documented, egress filtered by category, topology mapped
• 2 (Controlled): Ingress restricted to known authenticated sources, egress allow-listed, zero-trust enforced
• 3 (Closed): Circular topology, nodes only talk to other known authenticated nodes, mutual TLS, no public-facing endpoints
• 4 (Minimal): Single auditable egress point, certificate-pinned endpoints only, every crossing logged as a first-class audit event

04 Boundary — How completely are external AI inference endpoints and computer-use agent access governed?

• 0 (Uninspected): Unrestricted external AI API calls, no logging, no endpoint registry
• 1 (Inventoried): Endpoints documented, agent access identified, no formal controls beyond documentation
• 2 (Controlled): Rate-limited, logged, response-validated, no unmanaged computer-use access
• 3 (Hardened): Cert-pinned per endpoint, request signing, anomaly detection, circuit breakers, sanitized payloads
• 4 (Attested): All hardening active, GABA attestation complete for every endpoint (Chapter 11), residual risks formally signed by an authorized signatory

A stale artifact worth knowing about: the scoring page's own meta-description still reads "Score 0-12 across three pillars" — a leftover from before Pillar 04 (Boundary) was added. The live scoring UI itself correctly reflects four pillars and a 0–16 scale; don't repeat the stale three-pillar framing if you're citing this standard elsewhere.

General Reasoning's own stack, mapped to the pillars

CRC's own homepage names how General Reasoning's products satisfy each pillar, which is worth reproducing here since it directly explains why this manual's later chapters exist:

• Consolidate → DXMachine brings regulated workflows that would otherwise span Salesforce, SAP, Workday, ServiceNow, and integration layers onto one governed platform, eliminating the nodes and edges between them.
• Reduce / Close → "Purpose-built infrastructure running Chandra Protocol and DXMachine — nothing else." A purpose-built OS running exactly one thing, with a circular network topology and a single certificate-pinned egress point.
• Boundary → every external AI inference endpoint named, certificate-pinned, logged, and formally attested; computer-use agents require explicit GABA attestation (Chapter 11) separate from inference-only endpoints. This is very likely AegisGenera's (Chapter 19) job once it's built, based on the standard's own description of what Pillar 04 hardening requires — cert-pinned endpoints, request signing, a governed endpoint registry — but that connection hasn't been confirmed against AegisGenera's own source, since none exists yet.

Isolation Surface Size (ISS): Pillar 01, made quantitative

Attack surface and isolation surface are different questions. Attack surface asks where can an intruder get in. Isolation surface asks how much sits behind one boundary once they're in — a master key protecting more doors isn't a busier key, it's a more valuable one to steal.

Cost as a function of surface size:

Cost(S) = p·v̄·S·T + (c_r + c_c·f)·(T/S)

Optimal surface size:

S* = √[(c_r + c_c·f) / (p·v̄)]

The two terms trade off: safety cost rises with surface size (a bigger boundary is more valuable to compromise), while complexity/convenience cost falls (fewer, larger boundaries mean less provisioning overhead and fewer workflows hitting a seam). The curve has an interior minimum — that minimum is S*.

The key result: T cancels out of S*. Optimal surface size is population-independent. A fifty-person team and a fifty-thousand-person enterprise should target the same S* — the enterprise just needs more boundaries at that size, not bigger ones. This is the mathematical justification behind Chapter 13's per-Level physical-instance packing: you don't scale a deployment by making one worker instance handle more; you scale it by adding more instances at the same optimal size.

Worked example (ServiceNow + Salesforce, shared SSO domain): T=500, p=0.008, v̄=25, c_r=60, c_c=30, f=0.35.

S* = √[(60 + 30·0.35) / (0.008·25)] = √352.5 ≈ 19

Optimal: ~19 principals per boundary → ~26 boundaries needed. Current: 500 principals under one shared SSO boundary → the surface is roughly 26× larger than optimal, and total cost runs roughly 4.5× above the curve's minimum. The formula doesn't say the configuration is inoperable — it says it's carrying materially more risk-adjusted cost than the same environment, properly partitioned, would require.

The precise definition of principal, confirmed verbatim from a real personality artifact's schema and worth using consistently everywhere this manual talks about "who" governs or accesses something: "a distinct authority-bearing signing credential: human, agent, service account, API key, examiner, workflow engine, or integration identity that can authorize, attest, append, route, or access privileged Chandra content."

Where the formula travels, and where it's actually computed

This is a detail easy to get backwards. The Industry Configurator (Chapter 6) carries the ISS formula in every personality artifact it produces, under a crc_isolation_policy block — but its own configurator_role field is explicitly "not_computed_here". The Configurator hands the formula and its principal definition forward as policy; it never runs the calculation itself. The tool that actually computes S* against real deployment inputs and packs logical Levels (Chapter 4) into physical worker instances (Chapter 8) is the Spine Editor — see Chapter 13.

Open items for this chapter

attack-chain.html and gabastandard.com (referenced in CRC's own nav bar) have not yet been reviewed in depth — the former likely elaborates Pillars 02/03, and the latter is Chapter 11's subject. Both should be folded in once reviewed rather than assumed from the fragments seen so far.