68 lines
3.5 KiB
Markdown
68 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.
|