info-tech-canon/docs/emission-cadence-adoption.md
tegwick b46f1060ef
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 3s
Ask two source owners for Emission Cadence declarations (INFO-WP-0029)
INFO-DEC-2026-002 moved the standard to candidate, which asserts a specified
contract and no adoption. This pursues the other half, authorized by the
operator on 2026-09-21, which lifts the restriction INFO-WP-0019-T06 carried
against outward messages.

docs/emission-cadence-adoption.md states what a source owner supplies — a
declaration they own, valid against the schema and pinned to contract digest
972c0b6701d1693f — and what is not being asked for: no deployment, no runtime
proof, no conformance claim, no change to their system. Both requests point at
that page rather than restating the ask, so what is being asked cannot drift
between recipients.

net-kingdom is asked first because the contract was assimilated from the King's
Guard taxonomy and the evidence classes remain NetKingdom-owned, so it wrote the
problem statement and is most likely to find the contract's real gaps.
activity-core is the independent second, because its periodic emission into
issue-core means declared cadence is a question it already has.

Both messages say that a recorded incompatibility is a successful outcome, not a
failure. Success for this workplan is learning whether the contract survives
implementation, not collecting two clean files.

The workplan records what this can and cannot prove: both owners are repositories
in the same operator's fleet, independent of each other and of this repository in
the sense section 10 requires, but not independent of the operator. No promotion
note may read this as ecosystem adoption.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
2026-09-21 01:22:07 +02:00

3.4 KiB

Adopting the Emission Cadence contract as a source owner

The Emission Cadence standard is at candidate (document 0.2.0, wire schema version 0.1). Candidate means the contract is specified and machine-checkable. It asserts nothing about adoption: no source has implemented it.

This page is what a source owner needs in order to change that. It asks for a declaration you own, not for a change to your system.

What the contract is for

A source declares how often it emits an event class, so that an observer can tell silence that means nothing happened from silence that means the source stopped. Without a declared cadence, an absent event is unreadable. The standard keeps the two roles apart: the source declares, the observer evaluates, and a declaration is never evidence that the emission actually happens.

What a source owner supplies

  1. A declaration you own, valid against infospace/schemas/emission-cadence.schema.yaml, published in your own repository. It states your source, your stream_id, and one entry per event class you own, in one of the declared forms:
    • expected-rate — at least N events in a window, below which a finding is raised;
    • heartbeat-or-reconciliation — either a heartbeat asserting nothing-to-report, or a comparison between your own counts and the observer's.
  2. The contract digest you implemented against, so the declaration is pinned to a fixed reading of the contract rather than to whatever the canon says later. Current digest: 972c0b6701d1693f (info_tech_canon export-emission-contract <path.tar> regenerates it).
  3. Nothing else. No deployment, no runtime proof, no conformance claim. A declaration is a statement of intended cadence.

Validate before publishing:

info_tech_canon emission-review path/to/your-declaration.yaml

It returns ok plus operational_truth_assessed: false — the command checks your declaration against the schema and deliberately says nothing about whether your system emits at that cadence.

infospace/standards/emission-cadence/examples/qonto-assistant.yaml shows both forms. It is a worked example and explicitly not a source-owned declaration.

What an observer supplies

Separately from any source: a result produced by evaluating a source's declared cadence against events you actually observed, with the comparison references the declaration names. An observer result from the declaring source does not count — the point is that two parties read the same declaration the same way.

What this repository does with it

Validates submitted declarations, records them as adoption evidence, and reports any incompatibility found in the attempt. It does not operate your system, observe your events, or certify your conformance.

Two source-owned declarations from independent owners, plus one third-party observer result, plus a recorded incompatibility or a recorded absence of one, are what the standard's section 10 requires to move from candidate to stable.

What is honestly uncertain

The contract has never been implemented by anyone. The most useful thing a first adopter can report is where it does not fit — a cadence your system has that neither form expresses, a window semantics mismatch, an event class that needs more than one entry. A recorded incompatibility is a successful outcome of this exercise, not a failure of it.