Stream Topology & Topics

A disciplined topic taxonomy separates measurements, state, proposals, commands, and audit so each gets the right retention and access policy.

Topics carry policy, not just data

The topic a fact lives on determines its retention, compaction, ordering key, and access control. Layer 4 uses a deliberate taxonomy so that, for example, a command never shares a policy with a dashboard metric. The taxonomy is stable across the breeder and burner; only the domain segments differ.

Naming convention

<machine>.<domain>.<signal>            key                policy
breeder.magnetics.coil_current         coil_id            time-retained
breeder.plasma.equilibrium             shot_id            log-compacted
breeder.diag.neutron_flux              shot_id            time-retained
burner.plug.field                      cell_id            log-compacted
burner.dec.output                      unit_id            time-retained
*.proposals                            shot/campaign      time-retained
*.commands                             actuator_id        infinite, chained
*.audit                                event_id           infinite, chained

Five topic classes

• Measurements: high-rate, time-retained, tiered to cold storage.
• State: log-compacted so the latest per-key value is always available (equilibrium, plug field).
• Proposals: twin and copilot outputs awaiting gating.
• Commands: gated, authorized actions; infinite retention, cryptographically chained.
• Audit: decision lineage; infinite retention, never shed.

Access control by class

Command and audit topics have the strictest write and read controls; only the gating pipeline may write commands, and only via a valid token. Proposal topics are writable by L3/L5 but their contents actuate nothing until gated. This separation means a compromised analytics consumer can read measurements but can neither forge a command nor tamper with audit history.

Dead-letter topics

Each processing topic has a companion dead-letter topic for events that repeatedly fail handling, so a single poison message cannot stall a partition (see dead-letter handling). Topology, retention, and keys are all captured in the schema registry alongside the schemas.