Fabric Radar

Radar owns monitors, observations, anomalies, interventions, and estate-wide operational views. Airlift requires named observation windows for parallel run, cutover verification, and hypercare, then stores the terminal reference, digest, SLO profile, verdict, and observation timestamps.

A critical breach can stale readiness or block cutover under Airlift policy. The monitor definition and live health projection remain in Radar. When Radar is absent, use a typed external evidence profile rather than pretending the integration is installed.

Submit a Radar observation

An admitted automation principal records the observation after Radar has completed the window:

fa cutover observe --file operational-evidence.json --idempotency-key wave-4-parallel

{
  "waveId": "wav_01J00000000000000000000000",
  "phase": "parallel_run",
  "providerRef": {
    "system": "radar",
    "type": "observation_window",
    "id": "window-42",
    "digest": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
  },
  "evidenceDigest": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "sloProfileId": "airlift.cutover.production_slo.v1",
  "observedFrom": "2030-09-13T00:00:00.000Z",
  "observedUntil": "2030-09-14T00:00:00.000Z",
  "verdict": "passed"
}

Airlift rejects caller-authored human evidence, mismatched digests, unknown providers, and hypercare observations submitted before hypercare starts. A Radar screen or alert acknowledgement never changes Airlift state by itself.