Jira progress: loading…

ALERT

Alert Engines

1. Identity

Attribute	Value
Type code	`ALERT`
Canonical name	Alert Engines
Parent type	—
Type status	review
Tier scope	tier-0
Invocation	policy-invoked
Payload effect	none
Lineage role	both

ALERT is a category boundary, not an identity. Members are identified by MEID, versioned through ZAR as CMIs, and carry mice.category: ALERT. The type itself has no MEID, no CMI and no runtime presence.

2. Purpose and boundary

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.

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.

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.

3. Membership criteria

3.1 Inclusion tests

A micro engine is a member of ALERT when its specification satisfies the following:

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.

3.2 Exclusions

A micro engine is not a member of ALERT when any of the following is its responsibility; each belongs to the type named:

❌ 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.

3.3 Boundary cases

ALERT versus VALI: VALI reports contract violations on a payload; ALERT evaluates alert rules over signals and meta-signals and recommends an escalation.
ALERT versus AME: AME assesses trust and admissibility; ALERT detects that attention is required. An assurance classification is AME; a critical alert blocking disclosure readiness is ALERT.

4. Design rules

RULE-ALERT-001 — Deterministic evaluation

Given the same inputs + same ruleset + same parameters, the engine SHALL produce the same alerts.

RULE-ALERT-002 — Explicit rule provenance

Every emitted alert SHALL reference:

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

RULE-ALERT-003 — Non-mutating

ALERT engines SHALL NOT modify source signals. They emit separate alert meta-signals.

RULE-ALERT-004 — Safe-by-default escalation

ALERT can recommend actions, but SHALL NOT unilaterally execute destructive actions (delete, overwrite, irreversible state changes).

RULE-ALERT-005 — Federation-safe

Alerts SHALL be representable as portable meta-signals with:

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

5. Contract

5.1 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"
  }
}

5.2 Outputs

ALERT engines emit alert meta-signals. Each alert SHALL 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"
  }
}

5.3 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 SHALL be declared in the rule itself, not implied by runtime.

5.4 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.

6. Position in the computation chain

6.1 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.

7. Identity rules for members

Members are micro engines (CMPS-001 mice: block) whose identity satisfies all of the following:

mice.category SHALL be ALERT.
The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of DETECT, MONITOR.
The DOMAIN segment SHALL be TRUST, GOVERNANCE.
Typical FUNCTION segments: DETECTOR, MONITOR.
CMI kinds bound through zar.meid_cmi_binding SHALL be among ENGINE, RULESET.
Lineage: members append their CMI stamp to the evaluated signal and emit a meta-signal USO.
Tier scope: tier-0; invocation: policy-invoked; payload effect: none.

9. Governance and audit

9.1 Governance & Change Control

ALERT engines are governance-sensitive because they can:

block workflows,
trigger reviews,
affect disclosure readiness.

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

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.

Audit requirements (minimum)

Every alert SHALL be reproducible from:

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

10. Members

Loading micro engines…

AME — Assurance / Meta engines
VALI — Validator Engines
CALC — Calculation Engines
AGGR — Aggregation Engines
SCORE — Scoring Engines
TRFM — Transformation Engines

GitHub Repo Request for Change (RFC)

1. Identity​

2. Purpose and boundary​

Capability, not identity​

Summary​

3. Membership criteria​

3.1 Inclusion tests​

3.2 Exclusions​

3.3 Boundary cases​

4. Design rules​

5. Contract​

5.1 Inputs​

Canonical input envelope (conceptual)​

5.2 Outputs​

5.3 Severity Model (v1)​

5.4 Escalation Contract (v1)​

6. Position in the computation chain​

6.1 Interaction with ZSSR​

7. Identity rules for members​

9. Governance and audit​

9.1 Governance & Change Control​

What is versioned where​

Who can change what (v1 policy)​

Audit requirements (minimum)​

10. Members​

11. Related types​