Integrations
Connect Guardian to the AI monitoring stack you already use
Guardian adds a lightweight governance and evidence layer on top of your existing models, pipelines, and monitoring tools — so your team can turn technical monitoring outputs into traceable governance records.
No stack replacement required.
Keep your current monitoring stack
Ingest metrics via API or webhook
Normalize signals into governance-ready evidence
How Guardian connects
Most enterprises already compute model metrics. The challenge is not measurement — it is turning heterogeneous technical signals into a consistent governance layer.
Simple flow
Existing monitoring and evaluation tools → Guardian API or webhook → Normalized governance schema → Evidence records, status tracking, and oversight workflows
Ingest existing signals
Send the metrics your team already produces from monitoring jobs, evaluation pipelines, or internal review systems.
Normalize governance outputs
Guardian maps different model-specific metrics into a stable schema for drift, consistency, status changes, and evidence tracking.
Operationalize review and oversight
Use normalized outputs to support governance dashboards, internal review processes, escalation workflows, and traceable records over time.
Two integration modes
Choose the integration path that best fits your engineering environment and internal control model.
Native metric ingestion
Send the raw or existing monitoring metrics you already compute. Guardian handles the translation into a normalized governance schema.
Example metrics
- PSI
- precision / recall
- MAE / RMSE / MAPE
- embedding drift
- hallucination rate
- NDCG / ranking metrics
Best for
Fast onboarding and pilot deployments
Pre-translated ingestion
If your team prefers to control the mapping logic internally, you can send Guardian-normalized fields directly.
Example fields
- driftScore
- fairnessScore
- groupConsistencyScore
- psi
- disparateImpact
- demographicParity
- tprDifference
Best for
Teams that want tighter control over internal adapters and mapping rules
Built for heterogeneous AI environments
Different AI systems produce different native metrics. Guardian does not force them into one technical framework. It translates them into a common governance layer.
Binary classification
PSI, recall, disparate impact, demographic parity, equal opportunity gaps
Regression and scoring
MAE, RMSE, MAPE, calibration error, score-distribution drift
Forecasting
MAPE, SMAPE, forecast bias, residual drift
Computer vision
mAP, IoU, embedding drift, confidence drift, per-group recall
Ranking and recommenders
NDCG, MAP, MRR, CTR shift, exposure fairness
LLM and generative AI
Hallucination rate, groundedness, refusal rate, toxicity rate, task success, prompt drift
Standardize governance outputs, not model internals.
API-based metric ingestion
Use Guardian's API to submit metrics from scheduled evaluations, batch monitoring jobs, or internal reporting pipelines.
Typical payload includes
- schema version
- tenant or system ID
- model type
- run ID
- timestamp and evaluation window
- source metadata
- native metrics
- evaluation context where relevant
Illustrative payload
{
"schemaVersion": "1.0",
"tenantId": "example-enterprise",
"systemId": "wafer-defect-detection-model-01",
"systemName": "Wafer Defect Detection Model",
"modelType": "computer_vision",
"runId": "quality_monitoring_2026_05_12_1030",
"timestamp": "2026-05-12T10:30:00Z",
"window": {
"start": "2026-05-12T09:00:00Z",
"end": "2026-05-12T10:00:00Z"
},
"source": {
"provider": "internal-monitoring",
"pipeline": "manufacturing-quality-monitoring",
"environment": "prod"
},
"nativeMetrics": {
"mAP": 0.91,
"embeddingDrift": 0.14,
"confidencePSI": 0.18,
"recall_groupA": 0.92,
"recall_groupB": 0.87
},
"evaluationContext": {
"groupType": "production_line",
"reference": "line_A",
"comparison": "line_B"
}
}Guardian stores the native metrics, applies the relevant mapping logic, updates governance state, and appends the result to the evidence trail.
Webhook-based event integration
Use webhooks when governance-relevant events should trigger ingestion or downstream workflows automatically.
Inbound webhook examples
- monitoring.completed
- evaluation.completed
- drift.alert.triggered
- model.retrained
- incident.opened
Inbound events can either carry metrics directly or notify Guardian to retrieve them from a configured source.
Outbound webhook examples
- governance.status_changed
- consistency.threshold_breached
- oversight.review_required
- evidence.package.generated
- serious_incident.record_opened
Outbound events allow Guardian to connect with alerting systems, workflow engines, GRC platforms, and internal review queues.
Illustrative outbound event
{
"schemaVersion": "1.0",
"eventType": "governance.status_changed",
"tenantId": "example-enterprise",
"systemId": "wafer-defect-detection-model-01",
"timestamp": "2026-05-12T10:32:00Z",
"previousStatus": "GREEN",
"newStatus": "AMBER",
"scores": {
"driftScore": 74,
"groupConsistencyScore": 83
},
"reason": "drift and group-level recall deviation exceeded configured thresholds"
}What Guardian does not require
A first integration can start from aggregate monitoring signals and model metadata — without changing your existing AI stack.
- No replacement of your monitoring stack
- No direct access to model weights
- No raw training datasets
- No raw inference payloads
- No intrusive changes to existing ML pipelines
- No immediate standardization of all model families under one internal metric framework
Start with one metric source, one integration path, and one governance workflow.
Designed for enterprise integration
Guardian is intended to fit engineering environments where reliability, traceability, and controlled rollout matter.
- Authentication: API key, OAuth2, mTLS, or signed webhook payloads
- Schema versioning: versioned payloads for safe evolution
- Idempotency: duplicate submission protection for retries or repeated batch runs
- Retry logic: controlled delivery retries for temporary failures
- Observability: ingestion logs, processing status, validation errors, and failed payload tracing
- Mapping traceability: every normalized output linked to raw metrics and rule versions
- Deployment boundary: support for EU-hosted or controlled deployment models where required
- Auditability: threshold rules, mapping logic, and status transitions should be versioned and reviewable
Guardian provides technical evidence infrastructure. It does not determine legal compliance on its own.
Frequently asked questions
- Do we need to replace our current monitoring tools?
- No. Guardian is designed to sit on top of the monitoring and evaluation systems you already use. The goal is to add a governance and evidence layer, not to replace your existing stack.
- Do we need to send raw model data?
- Not for a first integration. A metrics-first approach can start from aggregate monitoring signals, model metadata, evaluation windows, and governance-relevant events.
- Can we keep our own internal metric mapping logic?
- Yes. Guardian can support both native metric ingestion and pre-translated ingestion, depending on how much control your team wants over the adapter layer.
- What kinds of AI systems can Guardian support?
- Guardian is designed for heterogeneous AI environments, including classification, regression, forecasting, computer vision, ranking systems, and LLM-based applications.
- What is the best way to start?
- The most effective starting point is a narrow pilot: one model family, one existing metric source, one integration path, and one governance workflow.
- Is Guardian a legal compliance determination tool?
- No. Guardian provides technical evidence infrastructure and governance workflows. It supports compliance readiness, but it does not replace legal assessment or formal conformity assessment.
Start with one system first
The best way to evaluate Guardian is through a focused pilot: one model family, one existing metric source, one lightweight integration, and one evidence workflow.
Keep your monitoring stack. Add the governance layer.