tegwick
e0ca7de63b
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
67 lines
3.5 KiB
Markdown
67 lines
3.5 KiB
Markdown
# 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.
|