Systems of record decide
- What system tables and metrics streams expose
- Which MLflow runs and model versions exist
- Who may act under Unity Catalog and workspace identity
- Jobs, Lakeflow, Serving, and native operational UIs
Governed mission control · data & ML
Radar
RadarMission control for data and ML.
See health, risk, and progress across the estate. Declare SLOs, triage evidence-backed anomalies, and intervene through governance — without replacing native systems of record.
radar · the watch looprecovery verified before close
- 01
MONITOR
Workloads and SLOs declared as governed writes
- 02
DETECT
Experiments evaluators attach evidence
- 03
ANOMALY INBOX
Human or finite triage agent works the queue
- 04
POLICY GATE
Blast radius · separation of duties
- 05
INTERVENE
Governed action with verified recovery
- Cost, freshness, quality
- SLO monitors
- Anomaly inbox
- Evidence attached
- Every intervention
- Governed writes
- The loop closes
- Verified recovery
Fabric ecosystem
One mission control · native systems of record
System tables, MLflow, and Unity Catalog stay authoritative. Radar adds visibility, SLO monitors, and governed intervention surfaces.
System tablesMLflowUnity CatalogJobsLakeflowModel Serving
The 30 second answer
Systems of record stay native. Radar owns the mission-control surface.
People often hear Radar as another metrics product or a second orchestrator. That is the wrong layer. Telemetry and authorization remain in Databricks. Radar owns visibility, declared SLOs, the anomaly lifecycle, and governed interventions.
Radar decides
- Which workloads are watched and under which SLOs
- How anomalies are raised, triaged, and resolved with evidence
- How interventions enter policy, state machines, and audit
- How health, risk, and progress read as one mission-control surface
Radar is deliberately thin. It does not implement a second orchestrator, anomaly engine, metrics TSDB, or approval queue. Temporal stays the runtime of record; Radar signals it, never replaces it. Read the architecture.
When mission control earns its keep
Three estate failures a dashboard alone does not solve.
Lead with outcomes, not another chart catalog. Radar differentiates after the red tile, the unproven alert, or the write that skipped governance.
The dashboard goes red
You can see a breached pipeline or model, but the path to pause, cancel, or quarantine is a side chat, a ticket, or a privileged notebook with no audit trail.
With Radar. Radar turns threshold crossings into an anomaly inbox and routes every intervention through Fabric Platform actions with policy gates and an immutable event log.
Nobody can prove the signal
Cost, freshness, and quality alerts fire without the evaluator verdict, the workload identity, or the deploy that put this version in the air.
With Radar. Experiments evaluators attach evidence when thresholds cross. Runway events annotate monitor rows so “what shipped this” is one projection join away.
Writes bypass the control plane
Console clicks, agent tools, and webhooks each mutate workloads differently. Blast radius is tribal knowledge; recovery is unverified.
With Radar. Humans and finite triage agents share one mutation path: actor, action, policy, state machine, adapter, event, verified recovery. No side door for writes.
The product boundary
Visibility and governed intervention
are the product boundary.
Charts, alerts, and workspace UIs already exist. Radar starts where they stop: declared SLOs, evidence-backed anomalies, and interventions that leave an audit trail.
How it works
Declare. Detect. Intervene with proof.
A closed loop from governed monitor declaration through evaluator evidence to verified recovery.
- 01
Declare and observe
A monitor declares a workload and its SLOs as a governed action. Telemetry flows append-only into Lakebase metrics — high-volume signal never becomes a mutation path.
- 02
Detect and triage
Fabric Experiments evaluators over system tables and MLflow raise anomalies with evidence. Humans or a finite Harness triage agent work the inbox.
- 03
Intervene and verify
Pause, cancel, or quarantine through Platform actions with blast-radius policy. An evaluator confirms recovery before the anomaly resolves.
Choose the operating plane
Operators in the console. Workloads in the estate.
Radar does not flatten Databricks into a generic metrics product. It gives operators a governed mission-control surface while detection, transport, and policy stay with the Fabric products that own them.
Console · operators
Triage the estate without inventing a second control plane.
Use the anomaly inbox, monitor registry, and intervention approvals in the Databricks App console. Reads come from Platform projections; writes never bypass governance.
- Anomaly inbox with evaluator evidence
- Monitor registry and SLO declarations
- Intervention approvals in family shell
Control plane · composition
Compose Platform, Harness, and Experiments
The Radar module runs on the Platform Host. Detection is Experiments schedules; interventions are Harness Temporal workflows and Databricks adapters.
- Platform actions and event log
- Harness transport and workflows
- Experiments evidence and thresholds
The Fabric difference
Visibility and governed intervention are the product boundary.
Alerting and dashboards already exist. Radar differentiates where the estate needs declared SLOs, proof under every signal, and writes that survive policy, audit, and recovery checks.
Mission-control visibility
One estate view across live pipelines, experiment runs, and model deployments — health, risk, and progress without rebuilding native Databricks surfaces.
Declared SLOs, not tribal pages
Cost ceilings, freshness lags, and quality floors are governed monitor declarations, so the watch list itself is policy-checked and audited.
Evidence under every signal
Anomalies carry the evaluator verdict that raised them. Triage starts with proof, not a red tile and a guess.
Governance under every write
Interventions are Platform actions with state machines, blast-radius gates, durable execution, and an audit trail shared by console and agents.
Composition, not reimplementation
Radar owns the monitoring domain. Platform, Harness, Experiments, and Runway keep governance, transport, detection, and delivery — Radar never smuggles them in.
Complete surface
Everything around the watch loop, in one coherent domain.
The differentiators are mission-control visibility and governed intervention. The product also includes the monitors, lifecycle, composition, and delivery surfaces needed to run them in production.
Monitors and SLOs
The unit of watch: a workload plus the ceilings operators get paged for.
- Pipeline, run, and model monitors
- Cost ceilings
- Freshness lags
- Quality floors
- Governed declaration
- Append-only metrics
Anomaly lifecycle
Threshold crossings become triageable work with a state machine and an inbox.
- Raised → triaged → acted → resolved
- Evaluator evidence attached
- Console inbox projection
- Finite triage agent tools
- Human-in-the-loop triage
- Recovery verification
Governed interventions
Every write against a live workload enters the same policy and audit path.
- Pause pipelines
- Cancel runs
- Quarantine models
- Blast-radius policy
- Platform state machines
- Immutable event log
Estate context
Connect what is running to what shipped it and who is responsible.
- Runs ledger projection
- Runway deploy annotations
- Workload identity
- Cost and freshness series
- Lakebase → Delta metrics
- Operator console shell
Fabric family composition
Radar stays thin by composing the products that already own each concern.
- Platform host and actions
- Harness Temporal workflows
- Experiments evaluators
- Runway delivery events
- Shared console shell
- No second orchestrator
Surfaces and delivery
Docs on the edge, console in-workspace, control plane on the Platform host.
- Cloudflare docs
- Databricks App console
- Platform Host module
- Lakebase event store
- Runway promotion path
- Static family contracts
Workloads
Built around what data and ML teams actually run
Pipelines, experiment series, model deployments, and the SLOs operators get paged for — watched with evidence and governed writes.
The closed loop
Every state change is a governed action.
Telemetry is the deliberate exception: high-volume signal is append-only. Everything that changes monitor, anomaly, or intervention state enters Platform with actor, policy, and audit.
- Monitor declaration is itself a governed write
- Experiments owns threshold detection and evidence
- Harness owns durable intervention transport
- Recovery is verified before the anomaly closes
radar · declare → verify
1declare · monitor pipeline.orders cost<=$420/d freshness<=15m
2observe · metrics append → lakebase · delta projection
3detect · evaluator freshness_p95=22m → anomaly raised + evidence
4triage · inbox · human or finite harness agent
5act · platform.action pause_pipeline policy=blast-radius/team-a
6verify · evaluator confirms recovery → anomaly resolved
Deploy
Edge docs. In-workspace console. Hosted control plane.
Each Radar surface lives where identity, data, and delivery already fit — the same pattern as the rest of the Fabric family.
FAQ
Straight answers to the comparison questions
Use these when someone asks what Radar provides that a dashboard or workspace UI does not.
Does Radar replace Databricks system tables, MLflow, or Unity Catalog?
No. Those remain the systems of record for telemetry, experiment history, and authorization. Radar adds declared SLOs, an anomaly lifecycle, and governed interventions on top of them.
How is Radar different from a dashboard or alerting product?
Dashboards show red. Radar attaches evaluator evidence, routes triage through a shared inbox, and makes every intervention a Platform action with policy, audit, and verified recovery.
Does Radar reimplement Temporal, detection, or a mutation pipeline?
No. Detection belongs to Experiments. Durable intervention workflows and Databricks transport belong to Harness. Governance and the event log belong to Platform. Radar owns the monitoring domain only.
How does Tower relate to Radar?
Tower is mission control for human-steered agent squads. Radar is mission control for machine-run data and ML workloads. When a Tower mission must act on a workload, it calls Radar’s governed intervention actions.
Can agents intervene, or only humans?
Both enter the same path. A finite Harness triage agent may use read tools plus one governed intervention tool. Console clicks, agents, schedules, and webhooks share actor, policy, state machine, and audit semantics.
Where do I start?
Read the docs overview, then follow the quickstart to declare a monitor over a live workload.
Contact
Talk to a person about your estate.
Questions about mission control for your Databricks workloads, a demo over your own estate, or how Radar composes with the rest of the Fabric family — send a note and a person at TechFabric replies.
Prefer email? contact@techfabric.com
Mission control · Fabric family
See the estate. Intervene with governance.
Start with the docs, declare a monitor over a live workload, and keep systems of record where they already belong.
TechFabric Radar is built and supported by TechFabric.
Contact TechFabric