FabricFabricRadar

Architecture

The concepts behind Fabric Radar — monitors and SLOs, the anomaly lifecycle, and governed interventions — and the loop that connects them.

Radar is a Fabric family vertical: it composes published contracts from Platform, Harness, and Experiments and never re-implements them. Three domain concepts make up the product.

Monitors and SLOs

A monitor is the unit of work: a watched workload — a pipeline, an experiment run series, a model deployment — plus its declared SLOs. SLOs cover the dimensions operators actually get paged for: a cost ceiling, a freshness lag, a quality floor. Declaring a monitor is a governed action, so changes to what is watched are policy-checked and audited just like changes to the workloads themselves.

Telemetry is the deliberate exception to "everything is an action." Metrics ingest is append-only into Lakebase metrics tables with a Delta projection on top — high-volume signal never becomes a mutation, and the event log stays a record of decisions, not samples.

Anomalies

Detection belongs to Fabric Experiments. Evaluators over Databricks system tables and MLflow run on a Temporal Schedule; when one crosses a monitor's threshold, Radar raises an anomaly with the evaluator evidence attached. The anomaly lifecycle is a state machine — raised, triaged, acted on, resolved — projected into the console inbox from Platform events. Triage is done by humans in the console or by a finite Harness agent whose only write tool is the governed intervention request.

Interventions

An intervention is a governed write against a running workload: pause a pipeline, cancel a run, quarantine a model. Interventions are Fabric Platform actions executed through Harness adapters — model quarantine, for example, applies Unity Catalog model-version tags and alias locks via Harness's Databricks transport. Blast-radius policies gate how much a single intervention can touch, and durable execution comes from Temporal intervention workflows composed from @fabric-harness/temporal.

The loop

Every arrow that changes state is a Platform action invocation with an actor, a policy check, a state-machine transition, and an audit event. Radar also consumes runway.* events through listEvents() projections, so deploys, gate verdicts, and promotions annotate monitor rows — the answer to "what shipped this" is always one join away.

Boundaries

Radar owns no Temporal client plumbing, no anomaly-detection engine, no Databricks auth or REST clients, and no mutation pipeline of its own. Those belong to Harness, Experiments, and Platform respectively; the repository's regression contract rejects the imports that would smuggle them back in.

On this page