Help Content Architecture — Per-Surface ACache Isolation
Source: cee-instance-dashboard-help-batch-v1.json and marshaller-help-batch-v1.json (real help-batch artifacts, both generated_at: 2026-08-23T13:32:00-05:00); marshaller.chandrahub.net (live-fetched, confirms the Help Index UI labeled "LOCAL MARSHALLER ACACHE"); ent-help-context-authority.lisp, ent-environment-roots.lisp (source zip); James, directly, on the Mythos graph-edge rationale below.
Chandra's in-product Help system is deliberately not a single, shared content store serving every tool. It is split by authority — a concrete, shipped mechanism, not just an architectural intention — and understanding why is a direct, worked application of Chapter 5's CRC argument to a piece of the system that might otherwise look like an obvious candidate for consolidation.
chandra-help-batch-v1 artifactsHelp content ships as versioned batch artifacts, each stamped with an explicit authority:
authority: "spine-acache", surface_group: "cee+instance-dashboard" — 41 contexts, version: "v31c452". CEE (Chapter 2) and the per-worker Instance Dashboard (Chapter 8) share this one help authority.authority: "marshaller-acache", surface_group: "marshaller+fleet-dashboard" — 37 contexts, version: "v43". The Marshaller (Chapter 7) and its Fleet Dashboard share a separate authority.Each Help context carries a context_id, title, scope, default_body, tags, a status, and a context_type. The Marshaller batch's own marshaller-overview context states the isolation boundary directly, in the product's own words, to anyone who opens it: "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." This isn't a design document's aspiration — it's live help text a Marshaller operator can read today, confirmed directly on marshaller.chandrahub.net, whose Help Index UI labels its own source plainly: "LOCAL MARSHALLER ACACHE."
Both batches carry the same merge_policy:
existing: upsert-standard-preserve-authored
preserve: [user_body, title, tags_json]
update: [default_body, scope, status, context_type,
form_design_id, field_id, field_label, level_id, hub_id]
unchanged: skip-no-cu
Reseeding help content is safe to run repeatedly: system-owned fields (the default body text, scope, status, and field/form/level/hub linkage) get refreshed to whatever the new batch says, while anything a human operator has actually authored (user_body, a custom title, tags_json) is preserved rather than clobbered. And critically, per Chapter 1's governance principle — a context that hasn't actually changed is skipped with no CU written at all (skip-no-cu). Reseeding the same batch twice doesn't spam the chain with no-op attestations; only genuine changes produce new governed history.
Keeping system Help monolithic — one shared store serving every tool — would open a graph edge a Mythos-class adversary could traverse. This is Chapter 5's Dunbar Perimeter argument, applied to Help content specifically rather than business data: a single Help store touched by CEE, the Marshaller, every worker's Instance Dashboard, and anything else in the ecosystem is exactly the kind of unowned, cross-surface connection CRC's Consolidate pillar exists to eliminate. It doesn't matter that Help content feels lower-stakes than business records — a traversable graph node is a traversable graph node regardless of what's sitting in it, and an unbounded adversary doesn't care that the content in question is "just help text."
This matters more than it might look, because Help content is client-customizable for a client's own infosec needs. A shared, monolithic Help store would mean one client's customized Help content — which might describe that client's own specific procedures, terminology, or internal security posture — sits in the same traversable graph node as every other client's customizations and every other surface's content. Splitting by authority means a compromise or traversal reaching CEE's Help content structurally cannot reach the Marshaller's, and vice versa, regardless of how the underlying infrastructure is otherwise networked.
Chapter 10 makes this same dual-argument about organizational data generally: isolating content down to fine-grained, independently-scoped segments is not purely a security measure. It's also a disaster-recovery one — a corruption or loss affecting one authority's acache doesn't cascade into every other surface's Help content. This is the same underlying design instinct (isolate everything down to the smallest sensible segment) serving two related but distinct purposes at once, and it's worth reading Chapters 10 and 18 together for that reason: neither chapter's argument is complete on its own.
The as-shipped split is two authorities (Spine-acache, serving CEE + Instance Dashboard; Marshaller-acache, serving Marshaller + Fleet Dashboard) — not literally "one acache per worker instance" as a third category, which is how the original architectural bookmark for this chapter was phrased. Whether the current two-authority split is the intended final shape, or whether a further per-worker-instance split is still planned on top of it, has not been confirmed and should be resolved with James directly before this chapter is treated as describing a finished architecture.