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
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
- A declaration you own, valid against
infospace/schemas/emission-cadence.schema.yaml, published in your own repository. It states yoursource, yourstream_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 assertingnothing-to-report, or a comparison between your own counts and the observer's.
- 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). - 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.