register+lemniscate: subject registry is register data, naming resolved through the register map

architecture/lemniscate.md

@@ -44,10 +44,13 @@ share state or corrupt each other. Idempotency is enforced by us, via
 dedupe on `decision_uuid`/`cycle_uuid`, because JetStream guarantees
 *at-least-once*, never *exactly-once*.
 
-Subject naming (open): the engine above uses short subjects
+Subject naming: the subject registry owns the naming decision, the
-(`gate.summary`, `action.call.<target>`). Our live bus streams use
+register is law, per
-`nimmerverse.register.>` / `nimmerverse.cycle.>`. Before any engine
+[register.md, Subject registry](./register.md). Short subjects
-traffic flows, pick ONE naming convention and map it here.
+(`gate.summary`, `action.call.<target>`) are internal identifiers;
+their wire names resolve through the registry map (today: `nimmerverse.`
+prefix, live streams already follow it). Code never hard-codes a
+subject string.
 
 ### Bus transport (NATS / JetStream)
 
@@ -197,4 +200,4 @@ while elapsed >= interval:
 - Register/catalog: sensors, gates, actuators, clients, `drives`. Catalog entry declares the class path; runtime imports an explicit registry and fails loud on a missing class.
 - Clients hold own durable consumers on `zone.state.>` and `action.result.>` (replay-on-wake).
 
-Version: 0.12 | Updated: 2026-11-06
+Version: 0.13 | Updated: 2026-11-06

architecture/register.md

@@ -2,6 +2,36 @@
 
 Central registry: sensors, gates, actuators, clients, and the links between them. Runtime decisions validate against it. Register changes are governed impulses.
 
+## Subject registry (subjects are register data, not code)
+
+The register holds the subject map; code and tools derive their wire
+names from it. The naming convention itself is registry data: flipping
+it is a single switch, no engine change, and the switch itself carries
+`event_uuid` + `why` (auditable v7 causality).
+
+```yaml
+# subject registry (register holds it, code consumes it)
+subjects:
+  version: 1
+  prefix: "nimmerverse."          # <- the naming convention, one switch
+  map:
+    gate.summary:  "nimmerverse.gate.summary"    # core NATS, ephemeral
+    gate.decision: "nimmerverse.gate.decision"   # core NATS, ephemeral
+    action.call:   "nimmerverse.action.call.{}"  # JetStream, per <target>
+    action.result: "nimmerverse.action.result"   # JetStream, durable
+    zone.state:    "nimmerverse.zone.state.>"    # JetStream, clients replay-on-wake
+```
+
+Rules:
+1. Publishers and consumers derive subject strings from the registry at
+   startup. No component hard-codes a wire subject.
+2. Validation once, before fan-out: an unmapped subject fails loud at
+   startup (same pattern as class-path validation).
+3. Growth by declaration: new sensor/actuator/client/tool = register row
+   + mapped subject; the engine is untouched.
+4. JetStream streams are created manually or script-gated; the register
+   refuses subjects that no backing stream exists for.
+
 ## Registry scope
 
 | Question | Registry |
@@ -11,6 +41,7 @@ Central registry: sensors, gates, actuators, clients, and the links between them
 | What may be emitted out? | actuator registry (animation catalog, output channels) |
 | What links exist? | gate links (`drives`) |
 | Who is listening? | client registry |
+| What subjects exist and who may use them? | subject registry (see Subject registry section) |
 
 The register is a gate layer one level up: sensors, gates and clients are admitted by declaration.
 
@@ -123,4 +154,4 @@ operator signature
 
 No component can rewrite the layer above it.
 
-Version: 0.5 | Updated: 2026-11-04
+Version: 0.6 | Updated: 2026-11-06