kings-guard/specs/EmissionCadenceDeclaration.md

---
title: Emission-cadence declaration (Taxonomy draft)
document_id: KG-DRAFT-EMISSION-CADENCE
version: 0.1.0
status: Draft-for-handover
date: 2026-09-01
drafter: kings-guard
owner: Taxonomy
worked_example: qonto-assistant
reference_instance: GH-WP-0002-T04
reference_source_declaration: approval-engine/cadence.yaml
statute: net-kingdom/canon/standards/security-layer-model_v0.7.md
sections: ["9.6", "17"]
classification: Public
---

# Emission-cadence declaration — Taxonomy draft

> Historical handover, frozen after assimilation. InfoTechCanon published
> `standard/emission-cadence` schema 0.1 in canon 0.7.0 (ITC-WP-0018).
> Canonical schema: `info-tech-canon/infospace/schemas/emission-cadence.schema.yaml`.
> Runtime fixtures now consume that shape; NetKingdom owns the security profile
> (NK-WP-0035, still proposed). The original proposal below is provenance.

kings-guard drafts this artifact because it is the only consumer of
silence-as-signal and cannot implement §9.6 without a declared cadence.
**Ownership stays with Taxonomy.** This file is a handover, not an internal
schema. Inventing a local shape and keeping it here would be the drift
§17 exists to prevent.

Proposed Taxonomy homes, neither of which has assented (§17):

- `info-tech-canon` — ecosystem-wide semantic contracts
- `net-kingdom` — NetKingdom standards of record

gate-house already named the heartbeat form as doctrine in
`docs/contracts/approval-emission-detection.md` (`GH-WP-0002-T04`). The
reference source declaration is `approval-engine/cadence.yaml`. This draft
covers **both** forms, because one does not substitute for the other.

## 1. Why this belongs alongside the security genome

A source already declares intended healthy operation as a `security_genome`:
purpose, permitted capabilities, egress, tolerances. Expected emission cadence
is a claim of the same kind — a statement of intent about the evidence the
source will publish, not a measurement kings-guard takes of it.

Putting the declaration next to the genome keeps three properties:

1. **The class is the source's declaration.** Load-bearing versus attributive
   is not inferred by the observer from event contents.
2. **The form follows the class.** Volume classes declare an expected rate.
   Low-volume load-bearing classes declare a heartbeat or reconciliation.
   Rate monitoring is forbidden for the latter: a suppressed month of
   revocations is indistinguishable from a quiet one.
3. **Silence becomes observable without Tooling contact.** The source
   publishes the stream, including the positive claim that can itself go
   missing. kings-guard compares what arrived against what was declared.

## 2. Both forms

### 2.1 Expected rate — volume classes

Use when the class has a rate that can drop.

```yaml
form: expected-rate
event_class: <name>
evidence_class: attributive | load-bearing
window: 24h
expected_min: <integer>
drop_below: finding
```

A drop below `expected_min` in `window` is a finding about the **stream**,
not about any record's contents.

Load-bearing volume classes MUST declare this form (or the heartbeat form
if they are in fact low-volume). Attributive sources SHOULD.

### 2.2 Heartbeat or reconciliation — low-volume load-bearing classes

Use when the valuable event is rare: revocations, denials, containment
actions. Rate monitoring cannot work. The required property is a **positive
claim that can itself go missing**.

Reference instance: `GH-WP-0002-T04` / `approval-engine/cadence.yaml`.
Form is heartbeat **plus** reconciliation, not rate monitoring.

```yaml
form: heartbeat-or-reconciliation
event_class: <name>
evidence_class: load-bearing
rate_monitoring: forbidden
heartbeat:
  event_class: <name>.heartbeat   # or a dedicated heartbeat class
  interval: 24h
  assertion: nothing-to-report
  missing: finding
reconciliation:
  compare_local: source transition counts per class
  compare_observed: evidence-engine counts per class
  divergence: finding
  undrained_local: lag-not-divergence
```

A missing heartbeat, or a reconciliation divergence, is a finding about the
stream. None of these are informational logs.

## 3. Worked example — `qonto-assistant`

The one real source this draft is written against.

| Event class | Evidence class | Form | Why |
| --- | --- | --- | --- |
| `audit.allow` | attributive | expected-rate (SHOULD) | Forensic reconstruction; no control branches on presence. Completeness is not claimed. The rate row is here so the volume form is specified, not because qonto traffic is currently a meaningful volume class. |
| `audit.deny` | load-bearing | heartbeat-or-reconciliation (MUST) | Deny-escalation and posture branch on deny presence/absence. Statute §9.6 names denials as load-bearing. Denials are infrequent, so rate monitoring is the wrong form. |
| `audit.heartbeat` | load-bearing | the positive claim | `nothing-to-report` plus per-class counts since the previous heartbeat. |

Machine-readable worked example consumed by the local evaluator (draft-shaped,
not a competing schema): `src/kings_guard/fixtures/qonto_assistant_cadence.json`.

Until `qonto-assistant` publishes the declaration and emits heartbeats, no
argument may assume this surface is live on that source. kings-guard can
still observe the audit events it does emit; stream completeness for the
deny class stays `unknown` or `degraded` until the positive claim exists.

## 4. Consumer obligations (kings-guard)

- Copy the declared evidence class onto each observation; do not infer it.
- Evaluate the stream against the declaration, not only each record.
- Carry completeness separately from record richness in posture output.
- Treat stream findings as distinct from content findings.
- Open no Tooling client to obtain the stream. The source publishes it.

## 5. Handover

Sent to `gate-house`, `net-kingdom`, and `info-tech-canon` for ownership.
kings-guard will consume whatever Taxonomy publishes; it will not fork this
draft into a private schema.