KB-326C

07 — Event Handling & Activation Readiness

2 min read Revision 1
dot-runnereventsactivation-readiness2026-06-04

07 — Event Handling & Activation Readiness (Workstream F)

State

7 process.* event types in event_type_registry, all active=false (unchanged). event_missing=true for every candidate — honest.

Decision: no activation, reference-without-emit

  • The runner records event_code on component observations only when supplied; in this run it supplied NULL (no event referenced) and emitted zero event_outbox rows.
  • While the 7 types are inactive, the runner MUST NOT write event_outbox for them. Default upheld.
  • Activating a process.* type is not the same as executing a DOT, but it would make the discovery event_missing flag dishonest unless a real emit path exists — so activation is deferred to an owner-gated packet.

Activation packet (staged, not applied)

When owner approves:

  1. Flip active=true for the specific process.* type(s) actually emitted by a wired runner.
  2. Payload schema: {process_run_id, correlation_id, component_run_id, dot_code, evidence_type, status, source_system, ts} (mirrors observation columns; stream/lane/severity already constraint-valid from the draft rows).
  3. Safety: emit only for evidence_type ∈ {DRY_RUN, REAL_RUN} (never SIMULATED) and only from a runner that actually invoked logic.
  4. Rollback: active=false (additive flip, reversible).

Dry-run event emission

Not rehearsed — there is no wired emit path and no true dry-run occurred. Holding until the agent_api contract (doc 06) lands, at which point dry-run emission can be rehearsed into a test namespace.

Event path is exact; nothing activated.

Back to Knowledge Hub knowledge/dev/reports/architecture/dot-process-discovery-runner-dryrun-ui-registration-readiness-2026-06-04/07-event-handling-activation-readiness.md