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

id	type	title	domain	status	version	owner	created	updated	last_reviewed	review_interval	scope	validator	related
netkingdom-emission-cadence-security-profile-v0.1	standard	NetKingdom Emission Cadence Security Profile v0.1	netkingdom	proposed	0.1	net-kingdom	2026-09-04	2026-09-28	2026-09-28	3m	evidence-completeness	tools/emission-cadence-profile/emission_cadence_profile.py	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:

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.