06 — Issue / Event Behavior Boundary (zero emit)

Defines exactly what the dry-run may and may not write to issue/event surfaces. The boundary is zero emit, zero issue persistence — findings are log-only.

6.1 Surface-by-surface verdict

Surface	Dry-run allowed?	Rule
event_outbox (governance)	NO	register-before-emit (Điều 45); types are active=false; any insert ⇒ ABORT
event_outbox (any domain, governance-triggered)	NO	the dry-run triggers no emit on any domain
system_issues (new rows)	NO	findings are computed in-memory / log-only; no bucket row written
governance_candidate_state / _object	NO persist	rehearsal-only inside ROLLBACK, count returns to 0
Notifications (any channel)	NO	T7 router not invoked; no Slack/email/push
governance_audit_log	NO	no governed act occurs to audit
Log-only output (report / stdout)	YES	the only permitted output of findings

6.2 Log-only finding format (the permitted alternative to emit)

A dry-run finding is a line in the run report, not a row anywhere:

[DRY-RUN][coverage] collection=<name> verdict=GAP reason=no_accountable_owner severity=high(computed) coalesce_key=(<name>,policy) materiality=above

• Severity is computed at report time (never stored).
• Coalesce key shown so duplicates are visibly merged.
• Materiality above/below shown so noise is visibly filtered.

6.3 Coalescing & noise limits (applied to log output)

• One log line per (object, scope) coalesce grain — re-detecting the same condition does not add a line.
• Below-materiality findings are summarized as a single count line, not enumerated.
• A hard cap on total log lines (e.g. ≤ 50) guards against accidental enumeration of a large source; exceeding the cap ⇒ ABORT (signals scope leak).

6.4 Why zero-emit is correct now

Emitting an event or writing a system_issue would:

1. Activate the governance event domain (crosses inert→active) — forbidden.
2. Trigger downstream T7 routing / notifications — forbidden.
3. Create persistent governance state before ratification — forbidden.

The decaying-verdict / candidacy-not-mandate design is fully exercisable as read-only logic; persistence and emit are the parts gated behind ratification, so the dry-run simply doesn't do them.

6.5 Future emit (out of scope — see doc 07)

When (and only when) the authorization model is ratified and event types are activated, emit becomes a separately-gated step: register type → activate → emit with coalescing + heartbeat. None of that is in the dry-run.

6.6 Issue/event boundary verdict

BOUNDED. Zero emit, zero issue persistence, zero notification, zero audit row; findings are log-only with computed severity, coalescing, materiality filtering, and a line cap. The dry-run cannot light up the event domain or the issue surface.