# Daily valuation releases and scheduler safety

Use for financial releases that add canonical day-level valuations, resumable historical backfills, or extend an already-installed scheduler.

## Preserve the full canonical identity

A day-level reader must partition by every ownership dimension, not only instrument and business date. For account valuations the canonical key normally includes at least `(scope_kind, scope_id, account_id, instrument_id, business_date)`. Omitting `account_id` silently drops one account when the same instrument is held in multiple accounts.

Add an adversarial fixture with the same instrument, date, and version in two accounts. Assert both canonical rows survive and aggregate correctly. Do not rely only on a row-count assertion at the writer boundary; exercise the actual reader used by performance calculations.

## Require explicit supersession lineage

Append-only version numbers are insufficient evidence of canonical history. When a corrected complete valuation replaces a prior complete valuation for the same business key/day, the new record must identify the previous canonical record through `supersedes_*` lineage. Probe this independently for every writer family (portfolio, crypto, managed-value snapshots); one writer having correct lineage does not validate the others.

## Bind resumable backfills after partial progress

A stale Preview check performed only before the first attempt is incomplete. Persist a post-attempt input revision after partial progress and compare it before retry. That revision must cover every consumed input and semantic lookup: confirmed activities, position/cash snapshots, price and FX rows, instrument master data, provider-symbol mappings, scope/coverage, and policy/benchmark configuration. A mapping-only mutation such as `provider_symbol` is a useful counterprobe.

If any bound input changed after the partial attempt, reject the old confirmation and require a new Preview plus a new confirmation ID. Output rows created by the partial attempt should be represented deliberately in the resume contract rather than accidentally making every retry stale.

## Treat installed scheduler state as production state

A requirement to “not activate the new writing timer” does not prove the old timer is inactive. Before deployment, inspect both `is-active` and `is-enabled`, the installed unit path, and its effective environment. If an existing schedule could fire during the release window, disable/stop it before the scheduled time when the release authorization and no-write boundary require that protection.

Deploy the new unit fail-closed:

1. install the reviewed service/timer files;
2. set the explicit write gate to disabled (`...ENABLED=0`);
3. run `daemon-reload`;
4. leave the timer inactive and disabled;
5. verify the effective service environment, not just the repository copy;
6. do not manually invoke the one-shot writer merely to prove the gate unless that probe is explicitly authorized.

Report the exact timer, service, CLI, and activation variable that would later require separate confirmation.

## Prove deployment caused no financial writes

Bracket checkout/build/restarts and read-only browser smoke with an all-table logical digest plus strict guard counts for audit rows, market runs, valuation snapshots, and coverage rows. Compare schema version, integrity check, foreign-key violations, digest, and guard counts. A matching digest and counts prove that service restart and page load did not create financial state.

Keep browser smoke read-only: inspect setup tasks, unavailable-vs-zero semantics, KPI count, reason-code leakage, overflow, and external render requests without calling Confirm or a writer service.