# 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.