The Industry Configurator
Source: index.html (Industry Configurator source, including the crcPolicy() and buildPersonality() functions); three real personality artifacts examined directly — personality-general_reasoning-finra-1783102313180.json, personality-general-reasoning-sifi-1781207518833.json, and personality-vatican-8level.json.
The Industry Configurator produces a personality — a portable artifact describing a regulatory domain's logical organizational structure, ready to seed a new Chandra Enterprise deployment. It has been run for at least FINRA, a "SIFI" (systemically important financial institution) domain, and — as a genuine stress test of how general the model is — an 8-level Holy See/Vatican City State spine (domain_class: "vatican", industry: "Holy See / Vatican City State — Sui Generis").
The live tool is at config.genreason.com. This is the same instance referenced throughout chandrahub.net's own beta-onboarding flow (Chapter 10) — generate a personality here, then email the resulting JSON to inquiries@genreason.com to actually get a deployment stood up.
Every personality artifact examined shares the same top-level shape: artifact_kind, standard (a versioned schema name, e.g. "chandra-industry-level-personality-v1"), industry, domain_class, organization, submitter identity, an architecture_contract, logical_level_count, a logical_spine (Chapter 4's Level structure), a crc_isolation_policy block (Chapter 5's formula, carried as policy), a list of fields excluded_from_personality, and a validation result.
This is the single most important thing to understand about this tool, and it's stated in its own source rather than inferred: the Configurator's architecture_contract names its scope as "map and edit ordered industry Level spine" — nothing more — and explicitly lists forbidden_outputs:
instance_count, tier_count, deployment_bindings, hub_templates,
spoke_templates, hubs, spokes, ports, urls, runtime_health
Every one of these is explicitly deferred_to_spine_editor, alongside Hub/table definitions per Level, Spoke/row definitions per Hub, form designs, and CRC physical-instance packing. The Configurator's own excluded_from_personality list reinforces this from the other direction: Hub/table schema, Spoke/row schema, physical instance count, instance addresses, ports, localhost URLs, deployment hostnames, runtime health state, and environment-specific routing are all named as things a personality artifact will never contain.
Why this boundary exists, and why it matters enough to be enforced in code rather than just convention: a personality is meant to be a portable description of an industry's organizational logic — the same FINRA personality should describe what a FINRA-regulated broker-dealer's spine looks like regardless of whether that specific deployment ends up running on one worker instance or twenty, on one Linode box or a client's own AegisGenera hardware (Chapter 10). If the Configurator baked in instance_count or ports, every personality would be tied to one specific physical deployment the moment it was generated, defeating the point of having a reusable, industry-general artifact at all. The boundary is also a direct expression of Chapter 5's Consolidate/Reduce discipline applied to the tooling itself: the Configurator doesn't know about physical infrastructure because knowing about physical infrastructure isn't its job, and a tool that does one job with a hard boundary is easier to reason about and secure than one that does several.
As domain, organization size, and workflow selections are made in the Configurator, the tool scores the resulting configuration against Chapter 5's ISS formula live — visible directly in the source as the crcPolicy() function, which is called at multiple points while building the personality (crc_isolation_policy: crcPolicy()). Note again the configurator_role: 'not_computed_here' field embedded in that same function's output: even while giving you live feedback as you configure, the Configurator is not the system of record for the actual physical-instance math — that calculation belongs to the Spine Editor (Chapter 13), which consumes the same formula and principal definition the Configurator hands it, against real deployment-specific complexity/risk inputs the Configurator never sees.
The Holy See/Vatican personality is worth walking through briefly because it demonstrates the model handling something far outside the FINRA/CMMC/HIPAA-style domains this tooling was probably first built for. Its 8-level spine runs from Level 8 (Holy See / Apostolic See — the top of the hierarchy, per Chapter 4's stored-bottom-up/displayed-top-down numbering) down through the sovereign structure of the Holy See, with each Level's level_form_values carrying domain-appropriate metadata: canonical_label, internal_term, description, primary_authority (e.g., "Roman Pontiff / Secretariat of State" for the top Level), and typical_records (e.g., "Apostolic constitution, motu proprio, Lateran Treaty file"). The Level 8 entry is flagged attestation_boundary: true — the Configurator's schema supports marking specific Levels as formal governance anchors, not just organizational nodes, which is presumably relevant to how the Spine Editor eventually treats that Level when computing isolation surfaces.
The fact that the same underlying tool, schema, and CRC isolation policy produce a coherent personality for a broker-dealer's FINRA obligations and for the Holy See's sovereign governance structure is a reasonable proof point for how domain-general the Level/Hub/Spoke model actually is — worth keeping in mind when Chapter 4 talks about a Spine as a general organizational-hierarchy concept rather than something scoped narrowly to financial regulation.
The pipeline, confirmed end-to-end across the Configurator source, the personality schema, and Chapter 5's formula:
This chapter documents step 1 only. Don't describe the Configurator as doing anything past producing the personality artifact — that boundary is enforced in its own code, not just a convention this manual is choosing to respect.