SLA & Scoring

SLA Management

Each data product has implicit SLA expectations based on its schedule:

Signal	Source	Alert Threshold
Freshness	Materialization timestamp	2x schedule interval
Quality score	Rolling check results	Below 95% over 24-hour window
Execution duration	Run time	Over 3x historical p95
Availability	Serving store reachability	Any failure

The platform monitors these via a platform sensor that runs every 5 minutes. Alerts are emitted as event bus messages and forwarded to configured notification channels (Slack, email).

---

Quality Score Computation

Each product’s quality score is a rolling average over the last 30 days:

quality_score = (passing_checks / total_checks) * 100

This score is synced to the OpenMetadata catalog and displayed in the Portal. Products with consistently high quality scores surface higher in data discovery results.

---

Quality Oracle System

The Quality Oracle is the governance layer that propagates quality failures through the data product graph.

Cascade Behavior

When a blocking quality check fails:

1. The platform marks the asset as check_failed

   The asset’s status changes, preventing downstream materialization.

2. Downstream assets are SKIPPED

   The platform’s graph semantics structurally prevent downstream execution. You cannot circumvent this.

3. A quality event is emitted

   {
     "event": "quality.check.failed",
     "product": "outlet-master",
     "check": "completeness_outlet_id",
     "severity": "blocking",
     "downstream_affected": [
       "daily-sales",
       "sales-dashboard",
       "churn-prediction"
     ],
     "tenant_id": "abc-123"
   }

4. OpenMetadata is updated with the quality cascade

5. Subscribers to affected products are notified

Quality Lineage

The platform tracks quality propagation through the dependency graph. An auditor can ask: “Why is my dashboard stale?” and trace it to: “The outlet-master product failed its completeness_outlet_id check 3 hours ago, blocking all 5 downstream products.”

---

Quality Results API

All check results are persisted and available via the API:

# View quality results for a product
curl -H "Authorization: Bearer $TOKEN" \
  https://api.akili.example.com/api/v1/products/outlet-daily-sales/quality

Results include: check_name, passed, severity, message, metadata_json, and executed_at. The Portal displays these as a quality dashboard with pass/fail history and trend charts.

---

Next Steps

• Manifest Authoring — Full manifest reference including quality.yaml field details
• Serving Configuration — How quality gates protect serving endpoints
• Governance — SLA management and quality lineage
• End-to-End Tutorial — See quality checks in a full lifecycle