Skip to main content
Jira progress: loading…

ALERT

Alert Engines

1. Overview​

Alert Engines (ALERT) are a capability class of Micro Engines (MICE) responsible for detecting threshold violations, trigger conditions, and escalation events over signals and meta-signals.

ALERT engines:

  • evaluate explicit alert rules against incoming signals (or batches),
  • emit alert meta-signals (not value mutations),
  • optionally instruct escalation actions (e.g. notify, block, manual review request) as recommendations, not as routing authority.

ALERT is a type, not an identity.
Concrete engines are identified by MEID, versioned via ZAR, and leave CMI lineage stamps at runtime.

2. Position in the MICE Model​

Capability, not identity​

An Alert Engine:

  • does not define which engine runs (MEID does),
  • does not define deployment/version (ZAR does),
  • does define a governed capability: rule-driven detection + escalation signaling.

Typical placement​

DimensionValue
Capability typeALERT
Typical tiersTier-0 / Meta (often AME-adjacent)
Common classificationAssurance-Engine (or Meta-Engine later)
Primary outputAlert meta-signal
Lineage impactAppends CMI stamp to USO

3. Core Responsibilities​

ALERT engines exist to make “something is wrong / something needs attention” deterministic, auditable, and portable.

They typically handle:

  • Threshold checks
    e.g. “trust_score < 0.8”, “missing_scope3_categories > 2”, “water_stress_exposure > X”

  • Trend / anomaly triggers (rule-driven)
    e.g. “YoY delta > 15%”, “sudden jump vs rolling baseline” (only when explicitly rule-defined)

  • Policy gating signals
    e.g. “reporting readiness = false → hold disclosure compilation”

  • Escalation recommendations
    e.g. “MANUAL_REVIEW”, “RECOMPUTE”, “REQUEST_EVIDENCE”

ALERT engines produce meta-signals that are consumable by:

  • ZSSR (routing decisions),
  • AAE (assurance workflows),
  • disclosure compilation gates,
  • monitoring dashboards / notifications.

4. Governance Principles (Non-negotiables)​

  1. Deterministic evaluation
    Given the same inputs + same ruleset + same parameters, the engine must produce the same alerts.

  2. Explicit rule provenance
    Every emitted alert must reference:

    • rule ID / ruleset ID,
    • rule version,
    • evaluation timestamp,
    • the exact signals evaluated.

  3. Non-mutating
    ALERT engines do not modify source signals. They emit separate alert meta-signals.

  4. Safe-by-default escalation
    ALERT can recommend actions, but must not unilaterally execute destructive actions (delete, overwrite, irreversible state changes).

  5. Federation-safe
    Alerts must be representable as portable meta-signals with:

    • stable identifiers (MEID + ZAR),
    • reproducible evaluation proof inputs,
    • clear semantics (severity, rationale, coverage).

5. Inputs​

ALERT engines consume one or more of:

  • Signals (USO IDs + payload summaries)
  • Meta-signals (trust, completeness, assurance statements)
  • Context (jurisdiction, framework, org boundary, time window)
  • Alert ruleset reference (ZAR address / registry pointer)

Canonical input envelope (conceptual)​

input-envelope-example.jsonGitHub ↗
{
  "inputs": {
    "signals": [
      { "uso_id": "uso:calc:ghg.scope3.total@2025", "value": 12345, "unit": "tCO2e" }
    ],
    "context": { "jurisdiction": "EU", "framework": "ESRS" }
  },
  "options": {
    "ruleset_ref": "schema.alert.ruleset.esrs_e1_readiness.v1_0_0"
  }
}

6. Outputs​

ALERT engines emit alert meta-signals. Each alert must include:

  • severity (info/warn/high/critical)
  • condition / rule reference
  • subject(s) (the affected USO IDs)
  • rationale (human-readable + machine readable)
  • recommended action (optional)
  • proof hooks (inputs hash / rule hash / registry references)

Canonical alert meta-signal (conceptual)

alert-example.jsonGitHub ↗
{
  "type": "alert.signal",
  "severity": "high",
  "rule_id": "ESRS_E1_READINESS_MIN_TRUST",
  "ruleset_id": "ALERT.RuleSet.ESRS_E1.Readiness.1_0_0",
  "subject": ["uso:calc:ghg.scope3.total@2025"],
  "finding": { "metric": "trust_score", "value": 0.72, "threshold": 0.80 },
  "recommendation": { "action": "MANUAL_REVIEW", "target": "ZSSR" },
  "provenance": {
    "engine_meid": "MEID_ALERT_ESRS_READINESS",
    "engine_cmi_stamp": "000123",
    "ruleset_zar": "ZAR:RULESET:ALERT:ESRS_E1.Readiness:v1_0_0",
    "evaluated_at": "2026-02-07T12:00:00Z"
  }
}

7. What ALERT Engines Do Not Do​

ALERT engines explicitly do not:

  • ❌ compute primary values (CALC)
  • ❌ validate structure/contracts (VALI) (they may rely on VALI results)
  • ❌ transform formats or units (TRFM)
  • ❌ probabilistically infer missing data (SEM)
  • ❌ perform orchestration/routing as authority (ZSSR does that)

ALERT engines are detectors and notifiers, not compute engines.

8. Severity Model (v1)​

A minimal, governed severity scheme:

  • info — informational; no action required
  • warn — potential issue; review recommended
  • high — likely reporting/assurance impact
  • critical — blocks disclosure readiness unless explicitly overridden

Rule: severity assignment must be declared in the rule itself, not implied by runtime.

9. Escalation Contract (v1)​

ALERT can recommend standardized actions (v1 enum):

  • NONE
  • NOTIFY_OWNER
  • REQUEST_EVIDENCE
  • RECOMPUTE
  • VALIDATE_NEXT
  • MANUAL_REVIEW
  • BLOCK_DISCLOSURE

Important: the action is a recommendation meta-signal. ZSSR (or policy) decides what actually happens.

10. Governance & Change Control​

ALERT engines are governance-sensitive because they can:

  • block workflows,
  • trigger reviews,
  • affect disclosure readiness.

10.1. What is versioned where​

  • Engine implementation: versioned in ZAR (CMI build)
  • Rulesets: versioned as ZAR artifacts (ruleset JSON)
  • Severity / escalation semantics: versioned in rulesets, not in runtime code

10.2. Who can change what (v1 policy)​

  • Owner team can propose:
    • new rules,
    • threshold adjustments,
    • new alert subjects.
  • Core/CTO approval required for:
    • rules marked critical,
    • rules with BLOCK_DISCLOSURE,
    • changes that expand coverage to regulated outputs.

10.3. Audit requirements (minimum)​

Every alert must be reproducible from:

  • the exact rule version,
  • the evaluated input signals,
  • the evaluation context,
  • the engine artifact identity.

11. Interaction with ZSSR​

ZSSR may use alert meta-signals to:

  • route to manual review,
  • trigger revalidation,
  • block downstream compilation.

ZSSR precedence rule: explicit ZSSR rules override tag/alert heuristics. ALERT signals are strong evidence — not authority.

12. Example Alert Engines​

Loading micro engines…
  1. Summary

Alert Engines:

  • create deterministic, auditable trigger events,
  • enable escalation and workflow gating as meta-signals,
  • support federation-safe readiness verification,
  • keep “what needs attention” explicit and replayable.

They are the platform’s governed nervous system.

Stable

GitHub RepoRequest for Change (RFC)
Tags:
Last updated on by Viroway