SPEC-OPS-002: External Status Persistence Model

Reference Number	Version	Effective Date	Supersedes	Authority Level
SPEC-OPS-002	1.6	2026-09-30	1.5	Normative

I. Purpose

Define the minimum logical persistence model for independent external status infrastructure. This specification stops at object semantics and does not authorize provisioning, indexes, retention schedules, or runtime implementation.

II. Scope

This model governs externally observed service conditions, independently publishable status notices, public projections, bounded history, and optional reconciliation references. It does not persist, reproduce, or replace canonical Operations incidents or any CTH business-domain state.

III. Authority Level

Normative (SPEC Tier). Subordinate to INV-CORE-000, INV-CORE-001, INV-ARC-009, INV-ARC-016, DOM-OPS-001, DOM-OPS-002, and SOP-OPS-001.

IV. Dependencies

• DOM-OPS-001_OPERATIONS_DOMAIN.md
• DOM-OPS-002_AUDIT_LINEAGE_INTEGRITY.md
• SOP-OPS-001_SERVICE_STATUS_AND_INCIDENT_COMMUNICATION.md
• SPEC-OPS-006_PUBLIC_REQUEST_MONITORING.md

V. Persistence Objects

5.1 Internal/probe Evidence Observation — append-only

This evidence schema remains distinct from public numerical request snapshots. It MUST NOT gate public request cards or be used to reinterpret HTTP measurements as domain correctness. New public request collection uses §5.5 exclusively.

Records one bounded observation received by the independent status service for one public capability or infrastructure dependency. The condition may be measured by the external collector itself or evaluated within CTH and transported to the collector. Persistence outside CTH does not make an application-produced result an independently performed external probe.

Required logical fields:

• stable observation ID;
• check time (checked_at, null only when no check ran), collector receipt time (received_at), and correlation ID;
• approved freshness class and immutable staleness state at receipt;
• bounded evidence source, including independent EXTERNAL_PROBE and APPLICATION_RUNTIME_EVIDENCE for feature results transported from CTH;
• capability/component key from a closed registry;
• observation class: LIVENESS, READINESS, CORRECTNESS, or INFRASTRUCTURE_FAILURE;
• outcome: PASS, FAIL, or UNKNOWN;
• epistemic state: KNOWN or UNAVAILABLE;
• bounded diagnostic code and bounded latency/result metadata;
• probe version, identifying the external collector/check transport;
• bounded evaluator version for a registered application feature result; null only when no feature evaluator ran (including an unregistered UNKNOWN result) or for non-feature observations.

The current projection recomputes staleness from checked_at, freshness class, and evaluation time. An old recorded FRESH state cannot keep a capability green after its maximum age. A missing check time cannot establish current health. For an external probe, check time is the time of its own measurement; for an application result, the collector preserves CTH’s original check time rather than replacing it with receipt time.

Observations MUST NOT contain tenant identifiers, PII, credentials, raw response bodies, stack traces, arbitrary payloads, or inferred internal causes. They cannot be updated or deleted during their retention window. CONFLICTING is not a raw-observation state; it belongs to derived assessment or projection state composed from multiple observations.

An external collector MUST preserve the source of the condition it transports: fetching an application-produced feature result does not turn that result into an independent external probe. Its own reachability measurement remains an EXTERNAL_PROBE, separately timestamped from the application’s bounded feature assessment. Both records retain their original provenance. The collector protocol’s probe_version is not evidence of which owning feature evaluator ran; a conclusive registered feature result also requires its separate evaluator_version from CTH.

The fields have distinct meanings: outcome records the result of this observation; epistemic_state records whether the capability state can be established from the available evidence. A single observation cannot claim aggregate disagreement.

Observation State Matrix

Outcome	Epistemic state	Validity	Meaning
PASS	KNOWN	Valid	The probe established the tested condition successfully.
FAIL	KNOWN	Valid	The probe established that the tested condition failed.
FAIL	UNAVAILABLE	Valid	The probe could not reach or obtain a usable result from the target; the target is not thereby proven internally faulty.
UNKNOWN	UNAVAILABLE	Valid	No usable result was obtained and no pass/fail conclusion is lawful.
PASS	UNAVAILABLE	Invalid	A successful result cannot simultaneously be unavailable.
UNKNOWN	KNOWN	Invalid	An unknown outcome cannot assert that the condition is known.

The Cartesian product of the declared raw-observation enums consists of six possible combinations. Only the four combinations explicitly marked valid are lawful; the remaining two are invalid and MUST be rejected before persistence. CONFLICTING is excluded from the raw-observation enum and may appear only on a derived assessment or public projection.

The public capability state is derived from the set of observations and applicable canonical publication information. A PASS + KNOWN observation may support a public AVAILABLE state only when no newer valid failure or unresolved disagreement controls the projection. A FAIL + KNOWN, FAIL + UNAVAILABLE, or derived CONFLICTING state MUST NOT be projected as healthy. Missing observations do not imply PASS.

5.2 External Status Notice — append-only publication history

Records a bounded communication artifact published independently when canonical Operations publication is unavailable or when an explicitly authorized external communication is required.

Required logical fields:

• stable external notice ID;
• append-only notice event ID, event type, and publication timestamp;
• notice state: AWARE, INVESTIGATING, IDENTIFIED, MONITORING, or RESOLVED;
• affected capability key;
• impact statement;
• recommended user action, including NO_ACTION_REQUIRED where applicable;
• recovery expectation state: KNOWN, ESTIMATED, or UNAVAILABLE;
• recovery expectation only when supported by the state;
• next-update timestamp or explicit NEXT_UPDATE_UNAVAILABLE state;
• optional source snapshot/observation IDs and bounded author/provenance metadata;
• operator investigation evidence note or reference when no automated source is linked;
• optional reconciliation reference.

The notice is not a canonical incident. Its existence MUST NOT imply that a canonical incident exists.

AWARE records that an operator has been told of, or has seen signs of, a possible problem that is not yet confirmed — the problem may not be happening at all. It precedes INVESTIGATING, which records a confirmed problem whose cause is not yet known. AWARE, INVESTIGATING, IDENTIFIED and MONITORING are the active states; only RESOLVED ends a notice. An AWARE notice is still operator communication: an automated measurement alone never creates one (DOM-OPS-001), though an operator may draft one from it.

5.3 Public Status Projection — replaceable derived state

Contains separate current request measurements and operator notice publication events. It MAY be replaced or rebuilt. It MUST identify whether the current view is based on external observation, canonical publication, or an unresolved disagreement, and MUST NOT be treated as authoritative incident state.

5.4 Historical Rollup — optional derived state

Aggregates non-tenant request snapshots for measured-window history under SPEC-OPS-006. The requested 90-day history is the concrete product need. Rollups are replaceable derivatives, never source evidence. Gaps, idle windows and monitoring failures must not be represented as successful uptime.

5.5 Public Request Snapshot — append-only

Use the closed schema, classification and history rules in SPEC-OPS-006. Persist source sampled time separately from collector receipt time. Append a source-minute snapshot once; atomically update its daily rollup and a monotonic current pointer. Retries must not inflate coverage. Older snapshots must not overwrite current data. Old evidence observations remain retained; do not convert them into request history.

VI. Reconciliation

Reconciliation is optional linkage, not conversion. Store only:

• the stable external notice ID;
• the canonical incident identifier, when one exists;
• linkage timestamp and reconciliation outcome.

Do not copy canonical incident content into external storage. Do not require linkage for publication. Never rewrite the original observation, notice event, or public message after reconciliation.

VII. Authority and Availability Rules

• Firestore MUST NOT contain canonical_incidents, authoritative incident_events, or authoritative incident_summary.
• External notices MAY be published during normal operation or canonical-service unavailability under DOM-OPS-001.
• When canonical publication is available, ordinary canonical incidents MUST NOT be duplicated automatically as external notices.
• Conflicting external observations produce an explicit CONFLICTING state; nulls and free-form strings MUST NOT encode epistemic meaning.
• No layer may infer internal cause or canonical domain state from external reachability alone.

VIII. Retention Classes

The implementation must define separate retention classes before provisioning:

• detailed external observations and publication events: bounded operational evidence;
• public status projections: replaceable current state;
• historical rollups: longer-lived derived history only if justified;
• reconciliation links: retained long enough to preserve lineage, subject to Operations policy.

Generic cleanup MUST NOT cross retention classes or delete append-only evidence before its authorized retention boundary.

IX. Deferred Implementation Decisions

This specification intentionally does not decide collection names, document paths, indexes, TTL values, probe cadence, Scheduler, Cloud Run, Firestore regions, deployment topology, authentication mechanisms, or public UI structure. Those decisions require review against this model.

X. Amendment

Revisions require incrementing the version, updating the Effective Date and Supersedes fields, preserving the distinction between canonical Operations truth and external communication artifacts, and updating the documentation index.