coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
info-tech-canon/demand/EmissionExpectedRateCalendar.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

3.5 KiB
Raw Blame History

Demand: Emission Cadence expected-rate calendar scope — non-uniform scheduled activity

Status: proposed (change proposal to the Emission Cadence standard) Date: 2026-09-22 Source: activity-core (source owner), domain infotech Owner: InfoTechCanon Emission Cadence standard (standards/emission-cadence) Consumer evidence: activity-core docs/emission-cadence/activity-core-evidence.yaml (commit f20db47) Feedback: feedback/2026-09-22-activity-core-emission-cadence-declaration.md Workplan: INFO-WP-0029 (T04 records it; no design workplan exists yet)

Demand signal

A source-owned expected-rate entry can express only a fixed wall-clock window per event class. activity-core's sbom_catchup activity runs on a weekday-only cron (15 9 * * 1-5 Europe/Berlin). Neither wall-clock window size is honest for that schedule:

  • A window sized to the daily period plus run slack (PT26H) is quiet on Saturday and Sunday mornings for a correct reason — the activity is not scheduled then — and expected-rate has no way to say so. Every weekend raises a false finding.
  • A window wide enough to tolerate the weekend gap (P4D) can no longer detect a genuine outage that starts and ends midweek, because it is now wider than the real inter-run interval on weekdays.

The consumer fell back to heartbeat-or-reconciliation/reconciliation against its own local activation count. That is correct and preserves validity, but it moves a genuinely rate-shaped activity out of the form built for rate expectations, and it depends on the source holding its own local count to compare against — an observer with no access to that local count cannot evaluate this stream at all.

Relationship to the other open gap

demand/EmissionActivityScope.md (net-kingdom) describes a related but distinct problem: a source that can emit only while an attended process runs, where expected_min: 0 is the only honest floor and silence carries no information outside a session. This demand is different: activity-core's source runs continuously and its schedule is fully known in advance — the problem is that the schedule is calendar-shaped, not that the source is intermittently absent. Both gaps point at the same root limitation (a single wall-clock window cannot represent every real scheduling shape) but call for different fixes, and a standard revision should look at both together before committing to one.

Options named by the consumer

  1. Let an expected-rate entry name a calendar — a cron expression and timezone — so the evaluation window counts scheduled slots rather than wall-clock time. A finding fires on a missed scheduled slot, not on an off-calendar quiet period.

Constraints on a disposition

  • A new field changes the wire schema (0.1). Under the 0.x rules that is allowed with migration guidance. Existing declarations stay valid only if the field is additive and optional.
  • Declarations pinned before the change stay pinned to their digest. Stable promotion needs declarations against one fixed reading of the contract, so a schema change before stable resets which pin later evidence should use.
  • This demand is not accepted. Choosing a design (calendar-aware expected-rate, a new form, or documenting the reconciliation fallback as the intended answer for calendar-shaped schedules) is a canon-owner decision, and should be made alongside a disposition on demand/EmissionActivityScope.md rather than separately.