Implement canon conformance and maintenance optimizations

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a06e82-3e08-7042-a79d-438ac6eed8db

infospace/assimilation/emission-cadence/ASSIMILATION.md

@@ -0,0 +1,79 @@
+# Assimilation — EmissionCadenceDeclaration
+
+**Status:** Closed  
+**Disposition:** Adapt  
+**Source:** King's Guard Taxonomy draft 0.1.0  
+**Authority:** `GH-DEC-2026-004` / State Hub decision
+`89c73f45-d07b-40ea-b428-5a7375ce4b09`
+
+## Scope
+
+This assimilation covers the generic, ecosystem-wide shape by which a source
+declares an expected emission cadence for an event class. It does not absorb
+the NetKingdom security profile: evidence-class policy, MUST/SHOULD obligations,
+and the rule requiring heartbeat plus reconciliation for rare load-bearing
+classes remain owned by NetKingdom.
+
+## Findings
+
+- The Observability Model already owns `Signal`, `SignalSource`, `Event`,
+  `EventSource`, and the missing-signal pattern. It does not own a portable
+  source declaration for the expected arrival of an event class.
+- The Governance Model already owns `Finding`. A cadence declaration names
+  detection conditions but does not redefine the finding record or lifecycle.
+- The handover contains two useful generic forms: an expected count over a
+  window, and a positive heartbeat and/or count reconciliation for streams
+  whose meaningful events are intermittent.
+- `evidence_class`, security modality, and required combinations are importing
+  profile concerns rather than generic cadence semantics.
+
+## DecisionRecord
+
+### Context
+
+King's Guard needs a stable contract to evaluate silence but is a Staff-layer
+consumer, not the Taxonomy owner. Gate House assigned the generic contract to
+InfoTechCanon and the NetKingdom security profile to `net-kingdom`.
+
+### Decision
+
+Adapt the draft into `standard/emission-cadence` and schema version `0.1`.
+Preserve its two form names and field meanings. Make profile classifications
+optional extension data, and let the heartbeat-or-reconciliation form contain
+either mechanism or both. Publish strict validation for the generic core and a
+namespaced `extensions` object for profile-owned additions.
+
+### Options Considered
+
+- Keep the schema in King's Guard — rejected because a consumer would own the
+  semantics it evaluates.
+- Put the whole contract in NetKingdom — rejected because generic cadence is
+  reusable outside that security estate.
+- Joint ownership — rejected because version authority would be ambiguous.
+- Adapt the generic core here and import it from a NetKingdom profile — chosen.
+
+### Rationale
+
+The split follows the repository's Taxonomy role and Core's single-owner rule.
+Allowing heartbeat, reconciliation, or both keeps the generic form useful while
+leaving NetKingdom free to require the stronger combination.
+
+### Consequences
+
+- Sources own their declaration instances and emission behavior.
+- Observers own evaluation and findings, not the declaration schema.
+- Importing profiles may require fields or combinations but may not change the
+  generic fields' meanings.
+- King's Guard's draft becomes provenance rather than a competing contract.
+
+### Review Trigger
+
+Review the draft after two independent source implementations, or when an
+importing profile needs a third cadence form that cannot be expressed through
+extensions without changing generic semantics.
+
+## Result
+
+The source was adapted, not copied into the canon. The resulting standard,
+schema, and worked example are registered in canon 0.7.0 and validated by the
+service surface.

infospace/assimilation/emission-cadence/assimilation.yaml

@@ -0,0 +1,18 @@
+id: assimilation/emission-cadence
+title: Assimilation — EmissionCadenceDeclaration handover
+source: King's Guard Emission-cadence declaration Taxonomy draft
+source_version: "0.1.0"
+source_type: internal-draft
+source_files:
+  - source/EmissionCadenceDeclaration.md
+requested_by: gate-house
+status: closed
+disposition: adapt
+impacts:
+  - model/observability
+  - model/governance
+  - standard/emission-cadence
+decision:
+  authority: GH-DEC-2026-004
+  decided_by: Bernd Worsch
+  decided_at: "2026-09-04T00:55:29Z"

infospace/assimilation/emission-cadence/comparison-matrix.md

@@ -0,0 +1,12 @@
+# Comparison matrix — EmissionCadenceDeclaration
+
+| Source concept | Canon comparison | Disposition |
+| --- | --- | --- |
+| EmissionCadenceDeclaration | Missing portable declaration contract | Add standard-owned concept |
+| expected-rate | Missing bounded-count declaration | Add generic form |
+| heartbeat | ITC-OBS has missing-signal semantics, but no source declaration | Add form component; import observability terms |
+| reconciliation | Missing source/observer count comparison declaration | Add form component |
+| finding | ITC-GOV already owns the assessment outcome | Import; do not redefine |
+| evidence_class | NetKingdom security viewpoint | Leave to importing profile via extensions |
+| load-bearing MUST/SHOULD rules | NetKingdom doctrine | Exclude from generic standard |
+| King's Guard evaluation behavior | Consumer implementation | Exclude from canon contract |

infospace/assimilation/emission-cadence/extracted-concepts.yaml

@@ -0,0 +1,33 @@
+source: KG-DRAFT-EMISSION-CADENCE
+concepts:
+  - id: emission-cadence-declaration
+    source_term: EmissionCadenceDeclaration
+    definition: A source-authored statement of expected event-class emission.
+    classification: missing_concept
+    proposed_owner: standard/emission-cadence
+  - id: expected-rate-cadence
+    source_term: expected-rate
+    definition: A minimum event count expected within a bounded window.
+    classification: missing_concept
+    proposed_owner: standard/emission-cadence
+  - id: heartbeat-cadence
+    source_term: heartbeat
+    definition: A positive liveness claim expected within an interval.
+    classification: broader_than_existing
+    existing_anchor: model/observability
+    proposed_owner: standard/emission-cadence
+  - id: reconciliation-cadence
+    source_term: reconciliation
+    definition: A comparison between source-side and observer-side event counts.
+    classification: missing_concept
+    proposed_owner: standard/emission-cadence
+  - id: evidence-class
+    source_term: evidence_class
+    definition: Security importance assigned to an emitted event class.
+    classification: viewpoint_difference
+    disposition: importing-profile-extension
+  - id: finding
+    source_term: finding
+    definition: The observer outcome produced by a cadence breach.
+    classification: already_covered
+    existing_anchor: model/governance

infospace/assimilation/emission-cadence/mappings.yaml

@@ -0,0 +1,25 @@
+id: mapping/emission-cadence-handover
+title: Emission cadence handover mappings
+source: KG-DRAFT-EMISSION-CADENCE
+target: standard/emission-cadence
+mappings:
+  - source_concept: EmissionCadenceDeclaration
+    target_concept: EmissionCadenceDeclaration
+    mapping_type: adapted
+  - source_concept: expected-rate
+    target_concept: ExpectedRateCadence
+    mapping_type: equivalent
+  - source_concept: heartbeat
+    target_concept: HeartbeatCadence
+    mapping_type: adapted
+  - source_concept: reconciliation
+    target_concept: ReconciliationCadence
+    mapping_type: adapted
+  - source_concept: finding
+    target: model/governance
+    target_concept: Finding
+    mapping_type: imports
+  - source_concept: event_class
+    target: model/observability
+    target_concept: EventType
+    mapping_type: imports

infospace/assimilation/emission-cadence/open-questions.md

@@ -0,0 +1,14 @@
+# Open questions — EmissionCadenceDeclaration
+
+No question blocks adoption.
+
+The following promotion questions remain for the draft's future review:
+
+1. Do two independent source implementations need interval tolerance or grace
+   fields in the generic core, or can profiles carry them in `extensions`?
+2. Should schema 1.0 retain the handed-over name `sources` for cadence entries,
+   or migrate to the clearer `cadences` with explicit compatibility tooling?
+3. Does reconciliation eventually need a generic typed counter-selector
+   language, or are owner-defined field references sufficient?
+
+These are review triggers, not deferred implementation tasks.

infospace/assimilation/emission-cadence/proposed-changes.md

@@ -0,0 +1,12 @@
+# Proposed changes — resolved
+
+1. Publish a draft Emission Cadence Standard under `infospace/standards/`.
+2. Publish and register `emission-cadence.schema.yaml`.
+3. Include one schema-valid worked example derived from the handed-over
+   `qonto-assistant` fixture without claiming it is the source-owned instance.
+4. Add structural validation for the schema and example.
+5. Register the standard and assimilation in all retrieval surfaces.
+6. Bump the canon minor version and record compatibility rules.
+
+All proposals were accepted under `GH-DEC-2026-004` and implemented by
+`ITC-WP-0018`.

infospace/assimilation/emission-cadence/source-summary.md

@@ -0,0 +1,17 @@
+# Source summary — EmissionCadenceDeclaration draft
+
+The King's Guard draft proposes a source-authored declaration that makes stream
+silence observable. It distinguishes two forms:
+
+- `expected-rate`: an event-class minimum over a time window;
+- `heartbeat-or-reconciliation`: a positive liveness assertion, a comparison of
+  source and observed counts, or both.
+
+The draft was written against `qonto-assistant` and the Gate House approval
+emission contract. It assigns evaluation to King's Guard and explicitly asks a
+Taxonomy repository to own the schema.
+
+Security-specific content associates event classes with `attributive` or
+`load-bearing` evidence and requires the stronger form for rare, load-bearing
+events. That policy is part of the source context, not the generic core adopted
+by InfoTechCanon.

infospace/assimilation/emission-cadence/source/EmissionCadenceDeclaration.md

@@ -0,0 +1,134 @@
+---
+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
+
+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.