net-kingdom/canon/standards/emission-cadence-security-profile_v0.1.md

160 lines
7.6 KiB
Markdown
Raw Normal View History

---
id: netkingdom-emission-cadence-security-profile-v0.1
type: standard
title: "NetKingdom Emission Cadence Security Profile v0.1"
domain: netkingdom
status: proposed
version: "0.1"
owner: net-kingdom
created: "2026-09-04"
updated: "2026-09-28"
last_reviewed: "2026-09-28"
review_interval: 3m
scope: evidence-completeness
validator:
- tools/emission-cadence-profile/emission_cadence_profile.py
related:
- GH-DEC-2026-004
- canon/standards/security-layer-model_v0.7.md
- kings-guard/specs/EmissionCadenceDeclaration.md
---
# NetKingdom Emission Cadence Security Profile v0.1
## 1. Purpose and import boundary
This profile makes the evidence-completeness rules in Security Layer Model
v0.7 §9.6 mechanically testable without creating a second declaration
contract.
The versioned, ecosystem-wide `EmissionCadenceDeclaration` semantic contract
is owned by `info-tech-canon` under `GH-DEC-2026-004`. It defines generic
forms, fields, vocabulary, validation semantics, compatibility, and evolution.
This profile imports that contract and defines only NetKingdom security
obligations over conforming declarations.
The import is InfoTechCanon `standard/emission-cadence`, document version
`0.2.0`, schema version `0.1` (canon 0.7.0; upstream status: candidate).
- Contract: `info-tech-canon/infospace/standards/emission-cadence/InfoTechCanonEmissionCadenceStandard.md`
- Schema: `info-tech-canon/infospace/schemas/emission-cadence.schema.yaml`
- Schema ID: `https://info-tech-canon.local/schemas/emission-cadence.schema.yaml`
- Reviewed contract/schema revision: `4d0851c3fca306538b53838421f4499baf352778`
- Owner-published candidate bundle digest: `b08b4d95fc4b0bd3`
- Schema SHA-256: `6d52692eb1e4d1325e0d6062d95acded98beddaae5bcfe24c6f0e91f1b6be6ae`
The candidate bundle digest identifies the exported contract, including its
standard text and example; it is not the schema SHA-256. The September 28
review confirmed that the wire schema is byte-identical to the earlier import.
InfoTechCanon corrected its adoption brief: `972c0b6701d1693f` identified the
0.1.0 draft bundle, not candidate 0.2.0.
The schema ID is an identifier; supply the file from the owner checkout, not a
network download from that hostname. This profile remains proposed pending
owner-instance migration and validation. The King's Guard draft is provenance,
not a fallback schema.
## 2. Ownership
| Concern | Owner |
| --- | --- |
| Generic declaration contract and schema | `info-tech-canon` |
| These NetKingdom MUST/SHOULD obligations | `net-kingdom` |
| Event-class inventory, evidence classification, rarity, declaration instance, and emission | source repository |
| Stream evaluation and silence findings | `kings-guard` |
| Doctrine and conformance supervision | `gate-house` |
An observer MUST NOT infer `load-bearing`, `attributive`, or rare-event status
from an event name, payload, observed rate, or historical traffic. The source
publishes those classifications in its authoritative inventory. A conformance
run supplies that inventory to the profile checker; omission from the cadence
document is then detectable rather than circular.
## 3. Normative obligations
| Source classification | Obligation |
| --- | --- |
| Load-bearing evidence | Every class **MUST** have a cadence declaration. |
| Attributive evidence | Every class **SHOULD** have a cadence declaration. A deliberate omission is advisory and completeness MUST NOT be claimed. |
| Volume load-bearing evidence | `expected-rate` is permitted when the source explicitly classifies the class as suitable for rate monitoring. A positive window and minimum are required; falling below the minimum is a finding. |
| Rare load-bearing evidence | Rate monitoring is **forbidden**. The declaration **MUST** carry both a heartbeat and reconciliation. |
For a rare load-bearing class:
1. `form` is `heartbeat-or-reconciliation`. The historical form name does not
weaken this profile's requirement for both controls.
2. `extensions.netkingdom.rate_monitoring` is `forbidden`.
3. The heartbeat is a positive assertion, normally `nothing-to-report`, and a
missing heartbeat is a `finding`.
4. Reconciliation compares the source's committed transition count with the
evidence engine's accepted count for the same source and class. Divergence
is a `finding`.
5. Locally committed but not yet drained work is lag, not divergence. A source
SHOULD declare a bounded lag signal separately.
Evidence class and cadence cover different properties. A transactional local
outbox prevents accidental omission across a state change; heartbeat and
reconciliation detect adversarial or operational omission after the fact.
Neither prevents omission by a compromised source, and conformance to this
profile MUST NOT be described as proving stream completeness.
The entry's `extensions.netkingdom.evidence_class` MUST match the supplied
source classification. NetKingdom fields belong only in this namespace;
flattened draft fields fail generic validation. Reconciliation uses the generic
`compare_local` and `compare_observed` fields. The checker also rejects duplicate
`source_id` values as required by the generic semantic contract, and duplicate
event classes within the profiled declaration.
## 4. Mechanical conformance
The checker takes a canonical contract schema, a declaration, and
source-owned class inventory on the command line:
```bash
uv run tools/emission-cadence-profile/emission_cadence_profile.py \
--contract-schema ../info-tech-canon/infospace/schemas/emission-cadence.schema.yaml \
--load-bearing audit.deny \
--rare-load-bearing audit.deny \
--attributive audit.allow \
source-cadence.yaml
```
Contract validation always runs first. The checker has no bundled fallback
contract and refuses to profile a document that fails the imported schema.
`--load-bearing`, `--rare-load-bearing`, and `--attributive` are assertions
from the source's authoritative event-class inventory; they are not guesses by
the checker. Rare load-bearing assertions imply load-bearing.
The report separates `contract_valid` (JSON Schema validity) from
`profile_assessed` and nullable `conformant`. A profile assessment is performed
only after schema validation and with a nonempty supplied inventory. The report
records those assertions under `inventory` and marks `assessment_scope` as
`supplied-inventory`; its result covers only that inventory, not independently
verified completeness or operational emission.
Without inventory, default mode returns `profile_assessed: false`,
`conformant: null`, `assessment_scope: inventory-missing` and exit 2. Explicit
`--schema-only` returns `assessment_scope: schema-only` and exit 0 for a valid
schema instance, while leaving profile conformance unassessed. It cannot be
combined with inventory flags or `--fail-on-should`. Invalid schema/declaration
results return exit 1 with profile conformance unassessed. CLI/input errors
return exit 2.
MUST failures from an assessed profile produce exit 1. Missing attributive
declarations produce a SHOULD finding and succeed by default;
`--fail-on-should` is available for a stricter caller policy. Callers must check
`profile_assessed == true` and `conformant == true` before claiming profile
success; an empty findings list or schema-only success is insufficient.
## 5. Adoption gate
This profile can become accepted only when:
- InfoTechCanon has published the imported contract, schema, version, and
stable locator;
- the checker passes against that schema without a local compatibility copy;
- `approval-engine` and `qonto-assistant` owner-authored instances have been
checked with owner-authored class inventories; and
- `kings-guard` has been given the canonical coordinates so its handover draft
can become historical.