info-tech-canon/feedback/2026-09-22-activity-core-emission-cadence-declaration.md

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

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