coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
info-tech-canon/feedback/2026-09-22-activity-core-emission-cadence-declaration.md
tegwick e0ca7de63b
Some checks are pending
CI Smoke / host-smoke (push) Waiting to run
Details
CI Smoke / container-smoke (push) Waiting to run
Details
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

4.6 KiB
Raw Blame History

id type status date consumer consumer_domain canon_version artifacts related_demand related_workplan spawned_demand spawned_workplan
feedback/2026-09-22-activity-core-emission-cadence-declaration consumer-feedback reviewed 2026-09-22 activity-core infotech 0.13.0
standard/emission-cadence
demand/EmissionExpectedRateCalendar.md
INFO-WP-0029
demand/EmissionExpectedRateCalendar.md

Feedback: second source-owned Emission Cadence declaration (activity-core scheduled evidence)

Consumer: activity-core Canon version used: contract digest b08b4d95fc4b0bd3 (Emission Cadence document 0.2.0, wire schema 0.1) Artifacts exercised: infospace/schemas/emission-cadence.schema.yaml, standards/emission-cadence/InfoTechCanonEmissionCadenceStandard.md Related demand: demand/EmissionExpectedRateCalendar.md

Source: activity-core's reply to INFO-WP-0029-T03 (State Hub message 161d5aa5-d2a9-4f6a-b833-3727e06007f8, thread f1687805-3153-47c2-9744-05a2b1a6b8c1), and the file it published at activity-core commit f20db47: docs/emission-cadence/activity-core-evidence.yaml.

Consumer purpose

Declare intended cadence for three scheduled activities emitted as State Hub progress events — a daily backup, a weekly package prune, and a daily SBOM catch-up — so an observer could evaluate silence against a fixed schedule.

Hits

  • expected-rate with a window sized to the schedule's period plus run slack (PT26H for a daily cron, P8D for a weekly cron). Two of the three entries expressed a fixed-time schedule cleanly this way.
  • heartbeat-or-reconciliation with a reconciliation block, for the third entry, once expected-rate proved unable to express its schedule (see Gaps).
  • extensions. activity-core.definition and activity-core.schedule carried the activity's own identifiers and cron expression without touching the generic contract shape.
  • The declaration is contract_valid: canon-side emission-review returns ok: true, errors: [], operational_truth_assessed: false.

Friction

  • emission-review could not be run by the consumer directly; the CLI needs infospace-bench, which is not installable from a package index there. The consumer worked around this by calling contracts.py directly. This is the same packaging limitation the net-kingdom declaration hit (feedback/2026-09-21-net-kingdom-emission-cadence-declaration.md), now observed by a second independent consumer.

Gaps

  • expected-rate cannot express a weekday-only schedule. The third activity (sbom_catchup) runs 15 9 * * 1-5 Europe/Berlin — weekdays only. A wall-clock window sized to catch a daily run (PT26H) raises a false finding every Saturday and Sunday morning. A window wide enough to span the weekend (P4D) would hide a genuine three-day outage that starts midweek. Neither window size is honest. The consumer declared this entry as heartbeat-or-reconciliation/reconciliation against its own local activation count instead, which is correct but sidesteps the form the activity actually needs. Filed as demand/EmissionExpectedRateCalendar.md.

Drop candidates

None.

Steward notes

  • This is the second source-owned declaration from an owner independent of both net-kingdom and this repository (INFO-WP-0029-T03). Its incompatibility — a wall-clock window cannot express a calendar-shaped schedule — is a different gap from net-kingdom's session-scoped silence. Both are recorded, per the workplan's framing, as successful outcomes: they show the contract is implementable and where its expected-rate form currently falls short of a real production schedule.
  • What this counts toward. Standard §10's stable gate asks for two source-owned declarations from independent owners plus one observer result. This declaration is the second. It also records a second, distinct incompatibility. No observer result yet evaluates this stream specifically: activity-core's periodic emission into issue-core is currently off in production (ISSUE_SINK_TYPE=state-hub), so this declaration covers State Hub progress evidence, and no third party has registered as an observer of that stream. The standard stays at candidate; INFO-WP-0029-T05 (observer result) stays open.
  • Both known incompatibilities (this one, and net-kingdom's session-scoped silence) point at the same underlying limitation of expected-rate: a single wall-clock window cannot represent activity that is legitimately bursty, calendar-shaped, or attended-only. A future standard revision should weigh both before choosing a fix, rather than solving each in isolation.