TG-RULE-EVALUATOR
TrustGate Rule Evaluation Engine
0. Identity
Depends on module:
1. Purpose
The TrustGate Rule Evaluation Engine evaluates registered platform validation and assurance rules against enriched TrustGate runtime objects.
Where the Structure Validation Engine verifies that a signal is structurally valid, the Rule Evaluation Engine determines whether the signal satisfies the applicable operational, semantic, assurance, governance, federation, replay, and policy rules required before TrustGate scoring and routing.
The engine is the first TrustGate runtime component that executes rules from the platform-wide zar.validation_rule_registry.
It does not calculate the final Trust Score. Instead, it produces a deterministic rule evaluation result set that becomes one of the primary inputs to the Trust Scoring Engine, Decision Engine, Quarantine Manager, Replay Engine, AII, and AAE.
2. Position within TrustGate Runtime
Signal Parser
│
▼
Structure Validation
│
▼
Signal Normalizer
│
▼
Context Enrichment
│
▼
──────────────────────────────────────────
Rule Evaluation Engine
──────────────────────────────────────────
│
▼
TG-RULE-EVALUATOR — Rule Evaluation Engine
│
▼
TG-POLICY-RESOLUTION — Policy Resolution Engine
│
▼
TG-SCORE-TRUST — Trust Scoring Engine
│
▼
TG-DECISION — Decision Engine
│
▼
Quarantine / Attestation / DAL / Replay
The Rule Evaluation result contributes to downstream Policy Resolution, Trust Scoring, Decision, Quarantine, Replay, and assurance processes.
Runtime orchestration shall nevertheless preserve the canonical order:
Rule Evaluation → Policy Resolution → Trust Scoring → Decision.
3. Canonical Identity
| Property | Value |
|---|---|
| Engine Name | TrustGate Rule Evaluation Engine |
| MEID | MEID_SIGNAL_VALIDATE_EVALUATOR |
| CMI | vera.TG-RULE.ENGINE.EVALUATOR.1_0_0 |
| ZAR Code | TGR08 |
| Kind | ENGINE |
| Owner Module | Verification & Assurance |
| Runtime Tier | Tier-0 Assurance Runtime |
| Primary Registry | zar.validation_rule_registry |
| Replay Support | Native |
| DAL Anchoring | Evaluation summary and critical findings |
| Federation Aware | Yes |
4. Scope
The Rule Evaluation Engine evaluates rules across several platform domains.
| Rule Domain | Description |
|---|---|
SIGNAL | Signal structure, fields, formats, and semantic payload expectations |
IDENTITY | ECO Number, DID, organization, federation identity, and controller checks |
ENGINE | MEID, CMI, ZAR artifact, engine compatibility, and runtime registration checks |
METRIC | Metric identifiers, CSI references, semantic metric definitions, and compatibility |
UNIT | Unit compatibility, UOM normalization, conversion eligibility, and dimensional checks |
CRYPTO | Signatures, hashes, proofs, certificates, Merkle paths, and integrity metadata |
POLICY | Governance policies, policy bundles, routing constraints, and tenant overrides |
REPLAY | Replay readiness, deterministic reproducibility, replay references, and replay drift |
FEDERATION | Cross-ECO validity, federation status, AFLE attestations, and EGFS node state |
AI | AI model registration, explainability status, model approval, and confidence metadata |
LINEAGE | USO chain completeness, DAL reference validity, and transformation lineage |
ASSURANCE | Assurance evidence, attestation completeness, verifier state, and certification readiness |
DATA_QUALITY | Completeness, consistency, timeliness, accuracy, and quality indicators |
SECURITY | Authorization, authentication, access policy, and runtime security constraints |
5. Runtime Responsibilities
The Rule Evaluation Engine is responsible for:
- loading applicable validation rules from
zar.validation_rule_registry; - selecting rules by domain, category, function, MEID, CMI, CSI, tenant, policy bundle, and federation profile;
- evaluating rule expressions deterministically;
- recording rule results with severity, action, and evidence;
- producing replayable rule evaluation artifacts;
- flagging rule failures for trust scoring and routing;
- marking quarantine candidates;
- emitting rule telemetry to VIZZ and AAE;
- preparing rule evaluation summaries for DAL anchoring;
- preserving full explainability for auditors and replay engines.
The engine SHALL NOT modify factual signal values.
6. Rule Evaluation Architecture
Enriched Signal
│
▼
Rule Scope Resolver
│
▼
Rule Registry Loader
│
▼
Policy Overlay Resolver
│
▼
Rule Execution Planner
│
▼
Expression Evaluator
│
▼
Result Aggregator
│
▼
Severity Mapper
│
▼
Action Resolver
│
▼
Rule Evaluation Output
7. Runtime Processing Pipeline
| Stage | Description |
|---|---|
| Receive | Accept enriched signal from Context Enrichment Engine. |
| Scope | Determine applicable rule scope. |
| Load | Load active rules from ZAR registry. |
| Overlay | Apply tenant, policy, jurisdiction, and federation overlays. |
| Plan | Build deterministic execution order. |
| Evaluate | Execute each rule expression. |
| Aggregate | Combine rule results into a summary. |
| Resolve | Determine severity and action outcomes. |
| Emit | Publish rule results and telemetry. |
| Prepare Replay | Store deterministic rule execution context. |
8. Rule Selection Algorithm
Rule selection is deterministic and policy-driven.
Rules are selected using the following inputs:
| Input | Purpose |
|---|---|
signal_type | Determines signal-specific rule groups. |
metric_type | Selects metric validation and semantic rules. |
eco_number | Selects tenant, entity, and federation-specific rule overlays. |
csi | Selects schema and interface rules. |
meid | Selects engine-specific rules. |
cmi | Selects implementation-specific rules. |
policy_bundle | Selects FAGF governance policy rules. |
federation_profile | Selects AFLE/EGFS-specific federation rules. |
assurance_tier | Selects assurance intensity and review requirements. |
9. Runtime Algorithm
function evaluateRules(enrichedSignal):
scope = RuleScopeResolver.resolve(enrichedSignal)
baseRules = RuleRegistry.load(
domain = scope.rule_domains,
status = "active"
)
scopedRules = RuleSelector.filter(
baseRules,
signal_type = enrichedSignal.signal_type,
metric_type = enrichedSignal.metric.metric_type,
csi = enrichedSignal.schema.csi,
meid = scope.meid,
cmi = scope.cmi,
federation_profile = enrichedSignal.federation.profile,
policy_bundle = enrichedSignal.governance.policy_bundle
)
overlays = PolicyOverlayResolver.load(enrichedSignal)
effectiveRules = RuleOverlayMerger.merge(scopedRules, overlays)
executionPlan = RulePlanner.order(effectiveRules)
results = []
for rule in executionPlan:
result = RuleExpressionEvaluator.evaluate(rule, enrichedSignal)
results.append(result)
if result.action == "abort":
break
summary = RuleResultAggregator.aggregate(results)
emit(summary)
return summary
All rule execution SHALL be deterministic for replay compatibility.
10. Rule Execution Formula
Each rule produces a binary or weighted evaluation result.
For binary rules:
where:
- = rule passed
- = rule failed
For weighted rule scoring:
The Rule Pass Ratio is not the final Trust Score. It is an input to the Trust Scoring Engine.
11. Severity Mapping
Each rule has a configured severity.
| Severity | Meaning | Typical Action |
|---|---|---|
info | Informational finding | pass or warn |
warning | Non-blocking concern | warn |
error | Material validation failure | review or quarantine |
critical | Integrity or identity failure | reject or abort |
blocking | Processing cannot continue | abort |
12. Action Resolution
Rule actions are resolved into a TrustGate evaluation state.
| Rule Action | Runtime Meaning |
|---|---|
pass | Continue processing. |
warn | Continue with warning metadata. |
review | Continue but mark for human review. |
quarantine | Continue to quarantine handling. |
reject | Reject the signal from assurance processing. |
abort | Stop execution immediately. |
If multiple rules produce actions, the strongest action wins.
Action precedence:
abort
>
reject
>
quarantine
>
review
>
warn
>
pass
13. Input CSI Contracts
| CSI | Required | Description |
|---|---|---|
comp.TG.OUTPUT.ENRICHED-SIGNAL.1_0 | Yes | Canonical enriched TrustGate signal. |
comp.TG.EVENT.CONTEXT-COMPLETE.1_0 | Yes | Context completeness event from Context Enrichment Engine. |
comp.SSSR.SCHEMA.REGISTRY.1_0 | Conditional | Schema metadata used for schema-linked rule execution. |
comp.USO.LINEAGE.EVENT.1_0 | Conditional | Operational lineage events for lineage-linked rules. |
comp.DAL.ANCHOR.PROOF.1_0 | Conditional | DAL proof metadata for integrity and cryptographic rules. |
comp.FAGF.POLICY.BUNDLE.1_0 | Conditional | Governance rules and policy overlays. |
comp.EGFS.FEDERATION.CONTEXT.1_0 | Conditional | Federation identity and node context. |
comp.DSAIL.AI.RECOMMENDATION.1_0 | Optional | AI advisory context for AI-related validation rules. |
14. Output CSI Contracts
| CSI | Description |
|---|---|
comp.TG.OUTPUT.RULE-RESULT.1_0 | Individual rule result. |
comp.TG.OUTPUT.RULE-SUMMARY.1_0 | Aggregated rule evaluation summary. |
comp.TG.EVENT.RULE-PASSED.1_0 | Rule passed event. |
comp.TG.EVENT.RULE-FAILED.1_0 | Rule failed event. |
comp.TG.EVENT.RULE-WARNING.1_0 | Rule warning event. |
comp.TG.EVENT.QUARANTINE-CANDIDATE.1_0 | Rule-based quarantine candidate event. |
comp.TG.EVENT.RULE-REPLAY-CONTEXT.1_0 | Replay context generated for deterministic re-evaluation. |
15. Rule Evaluation Result Object
{
"rule_result_id": "TGRR-2026-000001",
"rule_code": "TG-VAL-0007",
"rule_id": "VRR-TG-0007",
"rule_domain": "UNIT",
"rule_category": "VALIDATE",
"rule_function": "UNIT_COMPATIBILITY",
"status": "failed",
"severity": "error",
"action": "quarantine",
"field": "metric.unit",
"message": "Unit is not compatible with the declared metric type.",
"evidence": {
"provided_unit": "EUR",
"expected_dimension": "energy",
"accepted_units": ["kWh", "MWh", "GJ"]
},
"evaluated_at": "2026-06-25T15:12:41Z",
"engine_cmi": "vera.TG-RULE.ENGINE.EVALUATOR.1_0_0"
}
16. Rule Evaluation Summary Object
{
"evaluation_id": "TGRE-2026-000042",
"signal_id": "SIG-2026-00001472",
"eco_number": "ECO-A123",
"engine_cmi": "vera.TG-RULE.ENGINE.EVALUATOR.1_0_0",
"rules_checked": 42,
"rules_passed": 39,
"rules_failed": 3,
"warnings": 4,
"highest_severity": "error",
"resolved_action": "quarantine",
"rule_pass_ratio": 0.9285,
"replayable": true,
"evaluated_at": "2026-06-25T15:12:41Z"
}
17. API Specification
17.1. Endpoint
POST /api/trustgate/MEID_SIGNAL_VALIDATE_EVALUATOR
17.2. Request
{
"signal": {
"signal_id": "SIG-2026-00001472",
"eco_number": "ECO-A123",
"metric": {
"metric_type": "energy.total_consumption",
"metric_value": 12843.2,
"unit": "kWh"
},
"schema": {
"csi": "comp.TG.OUTPUT.ENRICHED-SIGNAL.1_0"
},
"governance": {
"policy_bundle": "FAGF-2026.2"
}
}
}
17.3. Response
{
"status": "success",
"evaluation_id": "TGRE-2026-000042",
"rules_checked": 42,
"rules_failed": 0,
"resolved_action": "pass",
"rule_pass_ratio": 1.0
}
18. Runtime Events
18.1. Rule Passed Event
{
"event_type": "trustgate.rule.passed",
"rule_code": "TG-VAL-0006",
"signal_id": "SIG-2026-00001472",
"timestamp": "2026-06-25T15:12:41Z"
}
18.2. Rule Failed Event
{
"event_type": "trustgate.rule.failed",
"rule_code": "TG-VAL-0007",
"severity": "error",
"action": "quarantine",
"signal_id": "SIG-2026-00001472",
"timestamp": "2026-06-25T15:12:41Z"
}
18.3. Quarantine Candidate Event
{
"event_type": "trustgate.quarantine.candidate",
"evaluation_id": "TGRE-2026-000042",
"signal_id": "SIG-2026-00001472",
"reason": "UNIT_COMPATIBILITY",
"rule_code": "TG-VAL-0007",
"timestamp": "2026-06-25T15:12:41Z"
}
19. DAL Integration
The Rule Evaluation Engine does not anchor every individual rule result by default.
It produces DAL anchor candidates for:
- evaluation summaries;
- critical failures;
- rejected signals;
- quarantine candidates;
- federation-relevant failures;
- replay-inconsistent results;
- policy overrides.
Example DAL anchor candidate:
{
"artifact_type": "RuleEvaluationSummary",
"artifact_id": "TGRE-2026-000042",
"artifact_hash": "sha256:8db77c0f...",
"engine_cmi": "vera.TG-RULE.ENGINE.EVALUATOR.1_0_0",
"dal_anchor_required": true
}
20. Replay Behaviour
The Rule Evaluation Engine is replay-native.
Replay requires:
- original enriched signal;
- resolved rule set;
- rule registry versions;
- policy overlays;
- expression engine version;
- engine CMI;
- execution order;
- configuration hash.
Replay equality is determined by:
Replay mismatch triggers an OARM review event.
21. Federation Behaviour
Federation-related rule failures are marked with:
{
"federation_relevant": true,
"source_eco": "ECO-A123",
"target_eco": "ECO-B456",
"federation_profile": "supplier-attestation"
}
The engine SHALL not transmit raw signal payloads across federation boundaries.
Only rule summaries, proof references, hashes, and attestations may be exchanged through AFLE/EGFS unless an explicit federation policy allows broader exchange.
22. AI Integration
The Rule Evaluation Engine may consume AI advisory metadata from DSAIL, but AI cannot determine pass/fail outcomes for deterministic rules.
AI may be used for:
- rule prioritization;
- anomaly-informed rule selection;
- adaptive sampling recommendations;
- explainability enrichment;
- false-positive reduction analysis.
AI SHALL NOT override deterministic registry rules.
Example AI-assisted rule context:
{
"ai_context": {
"model_cmi": "siss.DSAIL-MODEL.MODEL.ANOMALY.2_0_0",
"anomaly_score": 0.82,
"recommendation": "evaluate additional lineage consistency rules",
"explainability_score": 0.91
}
}
23. Security Model
The engine requires:
- authenticated internal service identity;
- authorization to read rule registry entries;
- authorization to read policy overlays;
- signed configuration bundles;
- immutable audit logging;
- replay-safe configuration hashes.
All rule expressions loaded at runtime SHALL be approved and registered in ZAR.
No unregistered executable rule expressions may be evaluated in production.
24. Failure Handling
| Failure | Action |
|---|---|
| Rule registry unavailable | Retry, then fail closed. |
| Policy overlay unavailable | Use cached active policy if valid. |
| Rule expression invalid | Mark rule as failed and escalate. |
| Unknown rule domain | Reject rule load. |
| Unsupported expression language | Reject rule load. |
| Missing mandatory rule set | Abort evaluation. |
| AI advisory unavailable | Continue without AI. |
| DAL unavailable | Continue but mark anchor pending. |
25. Observability
| Metric | Description |
|---|---|
trustgate_rule_evaluations_total | Number of rule evaluations executed. |
trustgate_rules_failed_total | Number of failed rules. |
trustgate_rules_warning_total | Number of warning-level rules. |
trustgate_rule_latency_ms | Rule evaluation latency. |
trustgate_rule_registry_lookup_ms | Rule registry lookup latency. |
trustgate_rule_cache_hit_rate | Cache efficiency. |
trustgate_quarantine_candidates_total | Rule-triggered quarantine candidates. |
trustgate_rule_replay_mismatch_total | Replay mismatches. |
26. Performance Targets
| Metric | Target |
|---|---|
| Average evaluation latency | < 50 ms |
| P95 evaluation latency | < 150 ms |
| Maximum rules per signal | 500 |
| Rule registry lookup latency | < 20 ms cached |
| Replay consistency | 100% |
| Availability | 99.95% |
27. Compliance
The engine supports:
| Framework | Contribution |
|---|---|
| CSRD | Data quality and auditability controls. |
| ESRS | Disclosure validation and evidence quality. |
| ISSB | Sustainability disclosure consistency. |
| ISO 14064-1 | GHG data validation and uncertainty controls. |
| ISO 27001 | Runtime control and integrity verification. |
| EU AI Act | AI advisory separation and explainability. |
28. Developer Implementation Notes
Developers implementing this engine SHALL:
- use the platform-wide
zar.validation_rule_registry; - evaluate only active or explicitly approved experimental rules;
- preserve deterministic rule execution ordering;
- store the rule registry version used for each evaluation;
- store the expression engine version;
- produce replay artifacts for every evaluation;
- never allow AI advisory context to override deterministic rules;
- emit rule result events for both pass and fail outcomes;
- mark federation-relevant findings explicitly.
29. Summary
The TrustGate Rule Evaluation Engine is the deterministic rule execution layer of TrustGate.
It converts enriched runtime signals into explainable rule evaluation results using the platform-wide validation rule registry. Its outputs drive trust scoring, decision routing, quarantine handling, replay preparation, DAL anchoring, federation attestation, AII telemetry, and assurance workflows.
By separating rule evaluation from trust scoring, ZAYAZ preserves a clean assurance architecture:
Validation determines what is wrong.
Scoring determines how much it matters.
Decisioning determines what happens next.