info-tech-canon/workplans/INFO-WP-0029-emission-cadence-adoption.md
tegwick e0ca7de63b
Some checks are pending
CI Smoke / host-smoke (push) Waiting to run
CI Smoke / container-smoke (push) Waiting to run
Close out INFO-WP-0030; record second Emission Cadence declaration
INFO-WP-0030: register practice-pattern/explicit-unsafe-diagnostic-mode
(adapted from coordination-engine's OrwellLoggingDiagnostics candidate,
INFO-DEC-2026-003) at canon 0.13.0, close the assimilation, and notify
coordination-engine for COORDINATION-WP-0004-T02. Workplan finished.

INFO-WP-0029: record activity-core's source-owned declaration (T03/T04
done) with its expected-rate/calendar-schedule incompatibility as
demand/EmissionExpectedRateCalendar.md, and record audit-core's
structural-only observer evaluation of net-kingdom's declaration as a
steward note. No party has yet produced a real observer result against
traffic, so T05 and the workplan stay blocked on external action.

Updated artifact-count and practice-pattern-count assertions in
tests/test_cli.py and tests/test_service.py for the new artifact.

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

Assistant: claude-code
Assistant-Model: sonnet
Assistant-Process: 317218@bnt-lap001
Assistant-Session: a8d6c0ab-c70f-4610-a288-576f44d747d4
2026-09-28 00:06:16 +02:00

8.1 KiB

id type title domain repo status owner topic_slug created updated flavor state_hub_workstream_id
INFO-WP-0029 workplan Seek independent Emission Cadence adoption evidence infotech info-tech-canon blocked claude canon-optimization 2026-09-21 2026-09-27 coordination d743e220-9d2d-52d8-8df3-880805269639

Emission Cadence adoption

INFO-DEC-2026-002 split the promotion gate and moved the standard to candidate, which asserts a specified contract and no adoption. This workplan pursues the other half: the evidence the stable level requires. Authorized by the founder (GOVERN @ estate) on 2026-09-21, which lifts the restriction INFO-WP-0019-T06 carried against outward messages.

Success is not "two declarations arrive". Success is learning whether the contract survives someone implementing it. A recorded incompatibility closes this workplan as usefully as a clean adoption does.

Publish what a source owner needs

id: INFO-WP-0029-T01
status: done
priority: high
state_hub_task_id: "c5d6422b-53a2-597a-a554-52741d4ae146"

docs/emission-cadence-adoption.md states what a source owner supplies — a declaration they own, valid against the schema, pinned to the contract digest — and what it does not ask for: no deployment, no runtime proof, no conformance claim. It names the validate command, both declared forms, the separate observer role, and says plainly that the contract has never been implemented and that reporting where it does not fit is a successful outcome.

The ask points at this page rather than restating itself in every message, so what is being asked cannot drift between recipients.

Ask net-kingdom, the origin owner

id: INFO-WP-0029-T02
status: done
priority: high
state_hub_task_id: "845c27d1-5b66-5317-8abb-0a62eb0d9638"

The contract was assimilated from the King's Guard taxonomy and the evidence classes remain NetKingdom-owned, so net-kingdom is the one party with a pre-existing stake in being able to read silence. It is also the party most likely to find the contract's real gaps, since it wrote the problem statement.

Ask for one source-owned declaration for an event class it already emits. Waiting for a reply is expected; this task tracks the ask, not the answer.

Sent 2026-09-21 as State Hub message 3432a831-b25f-4717-ad8b-cb19fb1b6633. Answered the same day (3b2db043): a declaration was published at net-kingdom 116643f, local-identity/emission-cadence.yaml, together with an incompatibility finding. It is recorded under T04.

Ask a second, independent source

id: INFO-WP-0029-T03
status: done
priority: high
state_hub_task_id: "bb74cce9-12d8-58e2-ad44-c4aeb7b72f37"

The second declaration must come from an owner independent of net-kingdom. activity-core is the candidate: it has a real, documented periodic emission relationship into issue-core, so declared cadence is a question it already has rather than one this request invents.

Sent 2026-09-21 as State Hub message f1687805-3153-47c2-9744-05a2b1a6b8c1. Both messages name the brief rather than restating the ask, and both say that a recorded incompatibility is a successful outcome.

Answered 2026-09-22 (161d5aa5): a declaration was published at activity-core f20db47, docs/emission-cadence/activity-core-evidence.yaml, together with an incompatibility finding. It is recorded under T04.

Recheck — 2026-09-21

No reply, and none should be expected yet. Both requests are unread. Neither recipient has read its inbox since before the requests were sent: net-kingdom last read on 2026-09-07 and has ten unread messages back to 2026-09-09; activity-core last read on 2026-09-04 with five unread back to that day. These agents read their inboxes only when a session runs in their repository, so the requests will be seen when that next happens, not before.

Drafting the declarations from this repository was considered and rejected. A declaration written by the same agent that wrote the contract proves nothing the stable gate asks: the gate exists to test whether parties who did not write the contract can implement it. Producing the evidence here would satisfy the letter of section 10 and defeat its purpose.

Record the evidence or the incompatibility

id: INFO-WP-0029-T04
status: done
priority: medium
state_hub_task_id: "4771ff59-264e-5917-a49d-8989b361b8ed"

Validate whatever arrives with emission-review, record it as adoption evidence under feedback/, and write up what the attempt revealed. If a declaration cannot be expressed in either form, that is the finding, and it goes to the standard as a change proposal rather than being worked around in the declaration.

Recorded so far — 2026-09-22

net-kingdom's declaration passes emission-review (ok: true). It is recorded as feedback/2026-09-21-net-kingdom-emission-cadence-declaration.md. Its incompatibility is that a session-scoped source cannot make its silence meaningful in either form. That finding goes to the standard as demand/EmissionActivityScope.md and was not worked around in the declaration.

Checking the pin exposed a canon-side defect. The brief quoted digest 972c0b6701d1693f, which is the 0.1.0 draft bundle, because the candidate promotion changed the standard's text after the digest was taken. The export manifest also hard-coded status: draft. The manifest now reads status and version from the standard. A test pins that behaviour, and the brief names the candidate digest b08b4d95fc4b0bd3. The wire schema did not change, so the declaration stays valid.

Recorded — 2026-09-27

activity-core's declaration passes emission-review (ok: true, errors: []). It is recorded as feedback/2026-09-22-activity-core-emission-cadence-declaration.md. Its incompatibility is that expected-rate's wall-clock window cannot express a weekday-only (calendar-shaped) schedule; the consumer used reconciliation instead for that entry. That finding goes to the standard as demand/EmissionExpectedRateCalendar.md and was not worked around in the declaration.

audit-core also replied (unread until this session) with a structural-only observer evaluation of net-kingdom's declaration, explicitly stating it does not satisfy the stable gate because audit-core holds no local-identity traffic to evaluate against. Recorded as a steward note on feedback/2026-09-21-net-kingdom-emission-cadence-declaration.md. It found a second incompatibility (heartbeat event_class vs. heartbeat_classes drift), noted there rather than duplicated here.

Both declarations now arrived and are recorded. This task is done. T05 (observer result) stays open: no observer has evaluated a source with registered traffic against either declaration.

Observer result

id: INFO-WP-0029-T05
status: wait
priority: medium
state_hub_task_id: "0486fcba-3609-50c5-b347-e7ee84f9f548"

One result from a party other than the declaring source, evaluating a declared cadence against observed events. Two declarations now exist (net-kingdom, activity-core), so the earlier blocker is cleared, but no result exists yet: audit-core's 2026-09-22 reply evaluated net-kingdom's declaration structurally only and said plainly that this does not satisfy the gate, since audit-core holds no traffic from that source. A real result needs a source with an expected-rate or reconciliation declaration registered at an observer and sending it traffic — neither net-kingdom nor activity-core currently sends traffic that any known observer holds (activity-core's periodic emission into issue-core is off in production). This is now blocked on an external party (a source and an observer both taking action this repository does not control), so the workplan status moves to blocked pending that.

Honest limit on what this can prove

Both candidate owners are repositories in the same founder's fleet. They are independent of each other and of this repository in the sense the standard's section 10 requires, and that is the sense the gate was written in — but they are not independent of the founder. Evidence gathered here demonstrates that the contract is implementable by parties who did not write it. It does not demonstrate ecosystem adoption, and no promotion note may claim otherwise.