The Spine Editor
Source: index.html's crcPolicy() and architecture_contract (Industry Configurator source — this is where the Spine Editor's role is defined, from the other tool's own boundary statement); personality-vatican-8level.json's crc_isolation_policy block. spine-editor.html itself (the tool's actual UI) is present in the broader source tree but has not yet been reviewed in depth for this chapter — everything below describes the Spine Editor's confirmed role, not yet its operational UI. This chapter should be substantially expanded once that review happens; treat it as a scope statement, not a how-to yet.
The Spine Editor is the tool that turns a logical personality (Chapter 6) into a physically deployed spine — it is the hinge between "here is an industry's organizational shape" and "here are running worker instances" (Chapter 8).
No source reviewed so far documents the Spine Editor from its own perspective in detail — but its scope is stated with unusual precision by the other tools that hand work off to it. The Industry Configurator's architecture_contract lists everything deferred_to_spine_editor:
The spine_editor_role field embedded directly in personality artifacts states the physical-sizing half of this most plainly: "compute physical Instance count and pack whole logical Levels into physical Instances using deployment-specific complexity/risk inputs."
Chapter 6 draws this line from the Configurator's side; it's worth restating from the Spine Editor's side because it clarifies what makes this tool necessary at all rather than redundant with the Configurator. A personality is meant to be reusable across deployments of wildly different scale and risk tolerance — the same FINRA personality might seed a small regional broker-dealer's single-instance deployment or a large SIFI's twenty-instance deployment. The Configurator cannot make that physical-sizing decision, because it doesn't know (and by design, is forbidden from knowing — see its own forbidden_outputs list in Chapter 6) anything about the specific deployment's actual principal population, risk profile, or infrastructure. The Spine Editor is where those deployment-specific inputs finally enter the picture, and where Chapter 5's ISS formula — carried forward as inert policy through the entire Configurator stage — actually gets evaluated against real numbers for the first time.
Chapter 5 established that S* (optimal principals per isolation boundary) is population-independent — the same target surface size applies whether the deployment has 50 principals or 50,000. The practical consequence for the Spine Editor, inferred directly from that math but not yet confirmed against the tool's own UI: given a personality's logical Levels and a deployment's actual principal count/risk inputs, the Spine Editor's packing decision should be choosing how many physical instances to stand up at the optimal S*, then assigning whole Levels to instances — not shrinking or growing individual instances to fit an arbitrary Level count. Whether the tool's actual UI frames this as directly as "here is your computed S*, here is how many instances that implies" is unconfirmed; this is the mathematically consistent expectation given everything upstream of it, not a description of a screen anyone has actually looked at yet for this manual.
This chapter needs a real pass against spine-editor.html itself: what the packing UI actually looks like, whether attestation_boundary-flagged Levels (Chapter 4's Vatican example) get any special treatment during packing, how a packing decision is saved/published (presumably as a CU, per Chapter 1, the same way a Form Design publish is), and how this connects operationally to the Acceptance/Production promotion flow documented in Chapter 2. Until that review happens, this chapter states the Spine Editor's contract with confidence (it's directly sourced from two other tools' own boundary statements) but its operation only as a reasoned expectation.