railiance-clock/specs/acceptance-v0.1.md

Acceptance and threat model — draft v0.1

IDs below are behavioral acceptance obligations, not a count of implementation coverage. The current coverage map identifies local test evidence, gaps and the existing owner records for native acceptance.

ID	Scenario	Required evidence
C01	Corporate Windows/WSL wall clock ±5 minutes, wrong zone and wall-clock step	Process-local interval remains correct under supported bootstrap; OS settings unchanged
C02	Asymmetric delay and deliberately delayed authentic response	True test time stays within computed interval or sample is refused; no symmetry assumption
C03	Wrong key, nonce, authority, version, signature or modified uncertainty	Refusal before any consumer validity check
C04	Replay, duplicate nonce, response after timeout/restart	Old response cannot establish a fresh anchor
C05	Authority upstream outage, large dispersion, restart or UTC rollback	Explicit unusable/holdover policy; no unearned healthy state or rollback acceptance
C06	Client reboot, suspend/resume, monotonic discontinuity and virtual clock drift	Old mapping invalidated; no frozen-clock lifetime extension
C07	Expiry/not-before boundary overlaps uncertainty	Refresh/wait/refuse; entirely valid interval accepted; signed fields unchanged
C08	Offline drift/sample-age budget exhausted	Protected use refuses; no wall-clock fallback
C09	TLS bootstrap fails due to OS time; unknown/revoked authority key	No insecure transport or circular trust acceptance
C10	Concurrent approval consume and delayed side effect	Existing CAS and action/lifetime binding still enforced by consumer
C11	Local event before calibration or across clock step	Original retained, translation unknown unless supported by evidence
C12	Two event intervals overlap / arrival order differs	No fabricated total occurrence ordering
C13	Bad numeric units, nonfinite/overflow, malformed/oversized requests	Bounded parsing and stable refusal without sensitive output
C14	Key rotation/revocation, stale trust cache and authority compromise drill	Adopted trust recovery evidenced; old samples cannot resurrect trust
C15	Authority inaccessible/slow and sustained request load	Bounded resources and honest unavailable state; liveness distinct from usability
C16	Consumer migration	Native positive plus wrong caller/owner/tenant/signature/expiry negatives; no wider access grant

Threats include compromised authority/upstream, network delay/replay, malicious producer timestamps, privileged local clock manipulation and configuration rollback. A fully compromised client process can falsify its own evidence; server-side owners must not treat client-supplied time as authority. One-host deployment does not provide Byzantine consensus. Host administrator trust and upstream error assumptions must be stated with results. No microsecond-accuracy or universal offline guarantee.

RCLK-WP-0002 reviews the matrix. RCLK-WP-0003 supplies fake-clock/property tests and an isolated authority/client exercise. RCLK-WP-0004 supplies measured native evidence, consumer acceptance and failure/recovery drills. Performance thresholds become versioned, measured policies before production admission.