info-tech-canon/infospace/standards/emission-cadence/InfoTechCanonEmissionCadenceStandard.md

id	title	short_name	type	standard_family	repository_context	recommended_path	status	version	schema_version	canonical_owner	namespace	classification	primary_cluster	imports	related	owned_concepts	provenance	created_at	updated_at
itc-emission-cadence:EmissionCadenceDeclaration	InfoTechCanon Emission Cadence Standard	ITC-EMISSION-CADENCE	standard	InfoTechCanon	info-tech-canon	standards/emission-cadence/InfoTechCanonEmissionCadenceStandard.md	draft	0.1.0	0.1	InfoTechCanonEmissionCadenceStandard	itc-emission-cadence	standard	observability-contract	InfoTechCanonCore InfoTechCanonObservabilityModel InfoTechCanonGovernanceModel	InfoTechCanonSecurityModel	EmissionCadenceDeclaration EmissionCadenceForm ExpectedRateCadence HeartbeatCadence ReconciliationCadence	source_version source_file assimilation decision 0.1.0 infospace/assimilation/emission-cadence/source/EmissionCadenceDeclaration.md assimilation/emission-cadence GH-DEC-2026-004	2026-09-04	2026-09-04

InfoTechCanon Emission Cadence Standard

Short Name: ITC-EMISSION-CADENCE
Document Status: Draft
Version: 0.1.0
Schema Version: 0.1

1. Purpose

This standard defines EmissionCadenceDeclaration: a machine-readable, source-authored claim about when records of an event class are expected to be emitted. It lets an observer evaluate a stream's silence separately from the contents and richness of records that did arrive.

The declaration describes intended emission. It is not a measurement, a health result, or proof that every event was emitted.

2. Ownership boundary

InfoTechCanon owns the generic forms, fields, validation semantics, compatibility rules, and evolution of this contract.

Other owners retain their own responsibilities:

• a source owns each declaration instance and the behavior it declares;
• an observer owns measurement, evaluation, and resulting findings;
• an importing profile owns domain policy: which classes must declare cadence, which form is required, and any stronger combination or threshold rules;
• ITC-OBS owns Event, EventType, EventSource, and missing-signal semantics;
• ITC-GOV owns Finding and its lifecycle.

In particular, this standard does not define attributive or load-bearing evidence, does not require cadence for any security class, and does not require heartbeat and reconciliation together. Those are NetKingdom security-profile rules, not ecosystem-wide semantics.

3. Declaration envelope

A declaration contains:

Field	Requirement	Meaning
schema_version	required	Contract version understood by the producer. This draft uses 0.1.
declaration_id	required	Stable identifier for the declaration instance.
source	required	Source system that owns the emission claim.
stream_id	optional	Stable stream identifier when the source publishes more than one stream.
sources	required	One or more event-class cadence entries. The name is retained from the handed-over 0.1 draft.
extensions	optional	Namespaced, profile-owned data that does not change generic field meanings.

Every entry in sources has a stable source_id, an event_class, and exactly one generic form. A declaration must not contain duplicate source_id values.

4. Forms

4.1 expected-rate

ExpectedRateCadence says that at least expected_min records of an event class are expected in each window.

source_id: example.audit
event_class: audit.recorded
form: expected-rate
window: PT24H
expected_min: 1
drop_below: finding

The window may be an ISO 8601 duration (PT24H) or a positive compact duration using s, m, h, or d (24h). A producer that cannot use duration strings may provide window_seconds instead, but must not provide both.

Evaluation is performed per complete window unless an importing profile defines a grace rule. A count below expected_min satisfies the condition named by drop_below. The string names an observer-owned outcome; it does not create or change the ITC-GOV Finding concept.

4.2 heartbeat-or-reconciliation

This form describes one or both of the following mechanisms:

• heartbeat: a positive assertion expected within an interval, so the assertion can itself be missing;
• reconciliation: references to source-side and observer-side counts whose divergence is evaluated.

At least one mechanism is required by the generic contract. An importing profile may require both.

source_id: example.denials
event_class: audit.denied
form: heartbeat-or-reconciliation
heartbeat:
  event_class: audit.heartbeat
  interval: PT24H
  assertion: nothing-to-report
  missing: finding
reconciliation:
  compare_local: source_transition_counts.audit.denied
  compare_observed: evidence_counts.audit.denied
  divergence: finding
  undrained_local: lag-not-divergence

heartbeat.interval follows the same duration rules as the expected-rate window; interval_seconds is the alternative integer representation. compare_local and compare_observed are owner-defined references. This draft does not define a query language for them.

5. Extensions and profiles

Generic objects are closed: unknown fields fail schema validation. Additional profile data belongs in an extensions mapping keyed by an owner-controlled namespace. For example:

extensions:
  netkingdom:
    evidence_class: load-bearing
    rate_monitoring: forbidden

An extension may narrow use of the generic contract. It must not redefine a generic field, change the meaning of a form, or make an instance that fails the generic schema valid.

6. Validation semantics

The normative machine contract is infospace/schemas/emission-cadence.schema.yaml.

A conforming generic declaration:

1. validates against that schema;
2. has at least one cadence entry;
3. has unique source_id values;
4. uses one duration representation for each window or interval;
5. supplies only expected-rate fields for expected-rate entries;
6. supplies heartbeat, reconciliation, or both for heartbeat-or-reconciliation entries; and
7. carries profile-owned data only under a namespaced extensions key.

Schema validation establishes declaration shape, not operational truth. Observers must not infer that a stream is complete merely because its declaration is valid.

7. Compatibility and evolution

The document version and schema_version use semantic versioning with the schema's major and minor represented on the wire.

• Patch releases clarify prose or validation without changing accepted data.
• Minor releases add optional fields or forms. Producers may opt in; consumers must not silently interpret an unknown form as a known one.
• Major releases may rename, remove, or change field semantics and require an explicit migration note.

During the 0.x draft period, incompatible changes remain possible but must be recorded in the repo changelog and accompanied by migration guidance. A consumer must reject an unsupported schema_version; it must not guess.

8. Worked example

examples/qonto-assistant.yaml is a schema-valid transformation of the King's Guard handover example. It demonstrates both forms and the profile-extension boundary. It is not the source-owned qonto-assistant declaration and makes no claim about live emission or observation.

9. Conformance

A producer conforms to this standard when its published declaration validates against the named schema and accurately identifies the source and event class it owns. A consumer conforms when it preserves the generic semantics, rejects unsupported versions and forms, and keeps observation results separate from the source's declaration.

Profile conformance is additional and is assessed by the profile owner.