Skip to main content
Jira progress: loading…

TG-VALIDATION-RULE

TrustGate Validation Rule Engine

0. Identity​

Loading identity…

Depends on module:

Decision-grade verification and assurance domain that orchestrates verifier workflows, evidence handling, trust scoring, audit trails, and assurance packaging across CSRD/ESRS and other frameworks. Enables third-party sign-off, dispute handling, and assurance-ready disclosure outputs with replayable provenance.
Domain:
assurance-verification
Category:
trust-assurance
Classification:
module
Lifecycle status:
active
Semver:
1.0.0
Introduced in:
v0.3
Governance
AI risk level:
high
Trust threshold:
0.97
Human review required:
true
Verifier involved:
true
Audit required:
true
Ownership
Primary owner:
Platform
Architecture board:
true
White-label allowed:
true
Entrypoints
Docs:
/verification-assurance
UI:
/app/assurance
API:
/api/assurance
Dependencies
Modules
  • sis
  • input-hub
  • reports-insights-hub
  • zara
  • zaam
Unresolved tokens
  • ALTD
  • DAL
  • EvidenceVault
  • StripeConnect
  • TruliooKYB
  • TrustGate
  • VTE
  • VerifierWorkflowEngine
Engines (declared)
  • VerifierWorkflowEngine
  • DaVE
  • VTE
  • DICE
  • EvidenceVault
  • ALTD
  • DAL
  • TrustGate
  • StripeConnect
  • TruliooKYB
  • AISIM
Micro-engines (from registry)
None
Micro-engines (declared)
None
Signals
USO
  • ASSURANCE.VERIFICATION
  • ASSURANCE.EVIDENCE
  • ASSURANCE.SIGNOFF
  • AUDIT.LINEAGE
  • GOVERNANCE.TRUST
  • IDENTITY.VERIFIER
  • PAYMENT.ESCROW
CSI
  • CSI_VERIFICATION_ASSURANCE
SSSR tags
  • assurance
  • verification
  • verifiers
  • evidence
  • signoff
  • trust-score
  • audit
  • tamper-detection
  • blockchain
  • rfp
  • disputes
  • escrow
  • stripe-connect
Workflows & Outputs
Workflows
  • VerifierOnboardingAndQualification
  • AssuranceRFPAndProposalFlow
  • EvidenceRequestAndCollection
  • EvidenceValidationAndScoring
  • TrustScoreComputationAndPropagation
  • VerifierReviewAndCommenting
  • IssueFlaggingAndDisputeResolution
  • VerifierSignOffAndStamping
  • AssurancePackagingForReports
  • PaymentEscrowAndPayoutOrchestration
Outputs
  • verifier_profiles
  • assurance_requests
  • evidence_packages
  • validation_findings
  • trust_score_updates
  • signoff_stamps
  • assurance_ready_disclosure_packages
  • payment_events
Audit
Ledger:
ALTD
Replay supported:
true
PII policy:
controlled_pii_outside_omr
Tags

1. Purpose​

The TrustGate Validation Rule Engine executes registry-defined validation rules against TrustGate signals before business rule evaluation, policy scoring, trust scoring, decisioning, replay, attestation, and federation exchange.

This engine is the runtime executor for the platform-wide validation rule registry stored under the zar schema, including:

  • zar.validation_rule_registry;
  • zar.validation_rule_domain;
  • zar.validation_rule_category;
  • zar.validation_rule_function.

It separates data validity from trust evaluation.

The Structure Validation Engine answers:

Can this payload be read and interpreted structurally?

The Validation Rule Engine answers:

Is this structurally valid payload allowed to proceed under registered validation rules?

The Rule Evaluation Engine answers:

How should a valid signal influence trust, score, routing, risk, and assurance?

This separation prevents rule sprawl, keeps the TrustGate runtime modular, and allows new validation rules to be added through the registry without changing engine code.

2. Position within TrustGate Runtime​

Signal Parser
      │
      ▼
Structure Validation
      │
      ▼
Signal Normalizer
      │
      ▼
Context Enrichment
      │
      ▼
──────────────────────────────────────────
 Validation Rule Engine
──────────────────────────────────────────
      │
      ▼
Policy Resolution
      │
      ▼
Rule Evaluation
      │
      ▼
Trust Scoring
      │
      ▼
Decision Engine

The Validation Rule Engine runs after the signal has enough context to evaluate rules that depend on identity, schema, units, registry references, DAL state, federation state, and policy context.

3. Canonical Identity​

PropertyValue
MEIDMEID_SIGNAL_VALIDATE_RULES
CMIvera.TG-VALRULE.ENGINE.VALIDATION.1_0_0
KINDENGINE
Owner ModuleVerification & Assurance
Runtime TierTier-0 Assurance Runtime
Engine CategoryVALIDATE
Engine Domainsignal
ZAR RegistrationRequired
Replay SupportNative
DAL AnchoringPolicy-based
Federation AwareYes

The MEID identifies the stable logical validation rule engine.

The CMI identifies this specific versioned executable artifact.

4. Runtime Responsibilities​

ResponsibilityDescription
Rule DiscoveryLoad active validation rules from zar.validation_rule_registry.
Rule Scope ResolutionSelect rules based on MEID, CMI, CSI, domain, category, function, tenant, policy, and signal type.
Rule Expression ExecutionExecute validation expressions using approved expression runtimes such as CEL.
Registry ValidationValidate ECO Numbers, DIDs, CSI versions, CMI references, metric types, units, signatures, hashes, and policy references.
Severity HandlingApply severity mappings from info to blocking.
Action MappingConvert rule outcomes into pass, warn, review, quarantine, reject, or abort candidates.
Evidence ProductionProduce rule-level evidence and failure details.
Replay SupportPreserve rule version, input hash, policy context, and execution result for deterministic replay.
DAL Candidate CreationEmit DAL anchor candidates for critical, blocking, federation-relevant, or auditor-requested validation outcomes.
AII and DSAIL TelemetryPublish validation quality signals to AII and DSAIL.

The engine must not calculate a TrustGate score. It only produces validation rule outcomes.

5. Relationship to Other TrustGate Engines​

EngineRole
Signal ParserParses input payloads into canonical signal objects.
Structure Validation EngineValidates syntax, required structure, datatypes, and base schema conformance.
Signal NormalizerCanonicalizes units, timestamps, identifiers, and value representations.
Context Enrichment EngineAdds identity, lineage, governance, replay, federation, AI, and risk context.
Validation Rule EngineExecutes registry-defined validity and admissibility rules.
Rule Evaluation EngineApplies business, assurance, scoring, and policy logic to valid signals.
Trust Scoring EngineComputes the numerical trust score.
Decision EngineConverts score and rule results into operational outcomes.

The Validation Rule Engine is therefore a registry-driven control layer between context enrichment and trust evaluation.

6. Validation Rule Registry Model​

Rules are stored in zar.validation_rule_registry.

Core fields include:

FieldPurpose
rule_idStable internal rule identifier.
rule_codeHuman-readable rule code such as TG-VAL-0008.
canonical_nameRule name.
descriptionRule description.
owning_moduleModule owner, usually vera for TrustGate.
owning_componentComponent owner, such as TrustGate.
rule_domainControlled domain such as SIGNAL, IDENTITY, CRYPTO.
rule_categoryControlled category such as FORMAT, REFERENCE, SIGNATURE.
rule_functionSpecific function such as ECO_NUMBER, DID, CSI_VERSION.
severityRule severity.
actionRequired action on failure.
rule_expressionExecutable validation expression.
rule_expression_languageExpression runtime such as CEL.
input_csiInput CSI the rule applies to.
applies_to_meidOptional MEID scope.
applies_to_cmiOptional CMI scope.
replay_requiredWhether replay evidence is required.
dal_anchor_requiredWhether failed or critical results require DAL anchoring.
federation_relevantWhether the rule affects federation exchange.
tenant_overridableWhether tenant policy may override behavior.
statusLifecycle status.

7. Validation Domains, Categories, and Functions​

The engine uses controlled vocabularies.

7.1. Rule Domains​

Examples:

DomainPurpose
SIGNALPayload, schema, datatype, format, and signal validity.
IDENTITYECO Number, DID, controller, and federation identity.
ENGINEMEID, CMI, executable artifact, and runtime compatibility.
METRICMetric type, semantic ID, and framework mapping.
UNITUnit validity and dimensional compatibility.
CRYPTOSignatures, hashes, certificates, and proof verification.
POLICYPolicy version, profile, and governance compatibility.
REPLAYReplay prerequisites and reproducibility.
FEDERATIONCross-ECO exchange and AFLE/EGFS metadata.
AIAI model references, explainability, calibration, and drift.

7.2. Rule Categories​

Examples:

CategoryPurpose
SCHEMARegistered schema validation.
STRUCTUREObject structure validation.
FORMATSyntax and identifier format.
DATATYPEField datatype validation.
REQUIRED_FIELDRequired field validation.
REFERENCERegistry reference validation.
VERSIONVersion compatibility validation.
SIGNATURESignature validation.
HASHHash validation.
POLICYGovernance policy validation.
REPLAYReplay validation.
FEDERATIONFederation validation.

7.3. Rule Functions​

Examples:

FunctionPurpose
JSONJSON validation.
REQUIRED_FIELDSRequired field presence.
DATATYPEDatatype validation.
ECO_NUMBERECO Number validation.
DIDDID validation.
CSI_VERSIONCSI version validation.
CMI_REFERENCECMI reference validation.
MEID_REFERENCEMEID reference validation.
METRIC_TYPEMetric type validation.
UNIT_COMPATIBILITYUnit compatibility validation.
SIGNATUREDigital signature validation.
MERKLE_PROOFMerkle proof validation.
AI_MODELAI model reference validation.

8. Initial TrustGate Validation Rules​

The initial TrustGate validation rule set includes:

Rule CodeCanonical NameDomainCategoryFunction
TG-VAL-0001Invalid JSON StructureSIGNALFORMATJSON
TG-VAL-0002Missing Required FieldSIGNALREQUIRED_FIELDREQUIRED_FIELDS
TG-VAL-0003Invalid ECO NumberIDENTITYFORMATECO_NUMBER
TG-VAL-0004Invalid CSI VersionSIGNALVERSIONCSI_VERSION
TG-VAL-0005Invalid CMI ReferenceENGINEREFERENCECMI_REFERENCE
TG-VAL-0006Unknown Metric TypeMETRICREFERENCEMETRIC_TYPE
TG-VAL-0007Invalid UnitUNITCOMPATIBILITYUNIT_COMPATIBILITY
TG-VAL-0008Invalid ECO NumberIDENTITYFORMATECO_NUMBER
TG-VAL-0009Invalid DIDIDENTITYFORMATDID
TG-VAL-0010Signature Verification FailedCRYPTOSIGNATURESIGNATURE
TG-VAL-0011Invalid DatatypeSIGNALDATATYPEDATATYPE

TG-VAL-0003 and TG-VAL-0008 should be reconciled during registry cleanup if they are duplicate ECO Number rules. Until then, the engine must treat both as valid registered rules but may mark one as deprecated when the registry is updated.

9. Runtime Processing Pipeline​

Receive Enriched Signal
      │
      ▼
Resolve Active Validation Profile
      │
      ▼
Load Applicable Rules from ZAR
      │
      ▼
Validate Rule Registry Integrity
      │
      ▼
Prepare Rule Execution Context
      │
      ▼
Execute Rules
      │
      ▼
Aggregate Results
      │
      ▼
Map Severity and Actions
      │
      ▼
Emit Validation Rule Result
      │
      ▼
Queue DAL Anchor Candidate if Required
      │
      ▼
Publish AII / DSAIL Telemetry

Rules should be executed in deterministic order:

  1. blocking identity and cryptographic rules;
  2. schema and version rules;
  3. registry reference rules;
  4. metric and unit rules;
  5. policy and federation rules;
  6. replay and AI governance rules;
  7. informational quality rules.

10. Processing Algorithm​

function execute_validation_rules(enriched_signal, policy_context):

    profile = resolve_validation_profile(policy_context)

    rules = load_active_rules(
        input_csi = enriched_signal.schema.csi,
        applies_to_meid = "MEID_SIGNAL_VALIDATE_RULES",
        profile = profile
    )

    sorted_rules = sort_rules_by_priority(rules)

    execution_context = build_rule_context(
        enriched_signal,
        policy_context,
        registry_snapshots
    )

    results = []

    for rule in sorted_rules:

        if not rule_is_applicable(rule, execution_context):
            results.append(skipped(rule))
            continue

        result = execute_rule_expression(rule, execution_context)

        mapped_result = map_result_to_action(rule, result)

        results.append(mapped_result)

        if mapped_result.action == "abort":
            break

    aggregate = aggregate_rule_results(results)

    emit_validation_rule_event(aggregate)

    if aggregate.requires_dal_anchor:
        queue_dal_anchor_candidate(aggregate)

    publish_telemetry(aggregate)

    return aggregate

The engine must never silently ignore active applicable rules.

11. Rule Applicability​

A rule is applicable when all required scope conditions match.

Applicability dimensions include:

DimensionExample
Input CSIcomp.TG.OUTPUT.ENRICHED-SIGNAL.v1_0
MEIDMEID_SIGNAL_VALIDATE_RULES
CMIvera.TG-VALRULE.ENGINE.VALIDATION.1_0_0
DomainSIGNAL, IDENTITY, CRYPTO
Signal Typeinvoice, sensor, upload, federation package
Metric Typeenergy.total_consumption
Tenant Policytenant-specific validation profile
Federation Statuslocal-only or federation-relevant
Replay Requirementreplayable or non-replayable
Regulatory ScopeCSRD, ESRS, ISSB, ISO 14064-1

Rules that are not applicable should be recorded as skipped only when policy requires full rule traceability.

12. Rule Execution Context​

The engine builds a context object for rule evaluation.

{
  "signal": {
    "signal_id": "SIG-2026-00001472",
    "eco_number": "ECO-A123",
    "metric_type": "energy.total_consumption",
    "unit": "kWh",
    "value": 12843.2
  },
  "identity": {
    "did": "did:zayaz:ECO-A123",
    "identity_status": "active"
  },
  "schema": {
    "csi": "comp.TG.OUTPUT.ENRICHED-SIGNAL.v1_0",
    "schema_version": "1_0"
  },
  "component": {
    "meid": "MEID_SIGNAL_ENRICH_CONTEXT",
    "cmi": "vera.TG-ENRICH.ENGINE.CONTEXT.1_0_0"
  },
  "governance": {
    "policy_bundle": "FAGF-2026.2",
    "validation_profile": "standard_signal_validation_v1"
  },
  "federation": {
    "federation_relevant": true,
    "region": "EU"
  }
}

The context must be canonicalized for replay.

13. Severity and Action Mapping​

Each validation rule has a severity and action.

13.1. Severity​

SeverityMeaning
infoInformational validation observation.
warningNon-blocking issue requiring visibility.
errorValidation failure requiring review or quarantine.
criticalHigh-impact failure requiring rejection, quarantine, or abort.
blockingProcessing must stop immediately.

13.2. Action​

ActionMeaning
passRule passed.
warnContinue with warning.
reviewContinue only with review requirement.
quarantineCreate quarantine candidate.
rejectReject the signal.
abortAbort due to unsafe runtime or governance state.

The action is policy-controlled but must not downgrade non-overridable critical rules.

14. Aggregation Model​

The engine aggregates individual rule results into a validation summary.

Rule Results
      │
      ▼
Severity Aggregation
      │
      ▼
Action Aggregation
      │
      ▼
Validation Summary

The most severe result determines the default aggregate severity.

Action precedence:

abort
  >
reject
  >
quarantine
  >
review
  >
warn
  >
pass

If any rule returns abort, the aggregate result must be abort.

15. Validation Result Formula​

A simple validation pass ratio may be calculated as:

Vpass=RulesPassedRulesExecutedV_{pass} = \frac{RulesPassed}{RulesExecuted}

A weighted validation quality score may be calculated as:

Vq=1−∑SeverityWeighti⋅Failurei∑SeverityWeightiV_q = 1 - \frac{ \sum SeverityWeight_i \cdot Failure_i } { \sum SeverityWeight_i }

Where:

  • $SeverityWeight_i$ is the configured weight for the rule severity;
  • $Failure_i$ is 1 if the rule failed and 0 otherwise.

This score is not the final TrustGate score. It is a validation quality input consumed by the Trust Scoring Engine.

16. CSI Contracts​

16.1. Input CSIs​

CSIRequiredPurpose
comp.TG.OUTPUT.ENRICHED-SIGNAL.v1_0YesEnriched signal to validate.
comp.TG.INPUT.STRUCTURE-VALIDATION-RESULT.v1_0YesStructural validation result.
comp.ZAR.INPUT.VALIDATION-RULESET.v1_0YesActive registry-derived validation rules.
comp.FAGF.INPUT.POLICY-CONTEXT.v1_0YesValidation policy and override controls.
comp.SSSR.INPUT.SCHEMA-SNAPSHOT.v1_0ConditionalSchema snapshot for CSI checks.
comp.EGFS.INPUT.IDENTITY-CONTEXT.v1_0ConditionalIdentity and DID context.
comp.DAL.INPUT.VERIFICATION-EVENT.v1_0ConditionalDAL proof and verification context.

16.2. Output CSIs​

CSIPurpose
comp.TG.OUTPUT.VALIDATION-RULE-RESULT.v1_0Full validation rule result.
comp.TG.OUTPUT.VALIDATION-FAILURE.v1_0Individual validation failure record.
comp.TG.OUTPUT.QUARANTINE-CANDIDATE.v1_0Candidate for quarantine when required.
comp.TG.EVENT.VALIDATION-RULES-EXECUTED.v1_0Runtime execution event.
comp.TG.EVENT.VALIDATION-RULE-FAILED.v1_0Rule failure event.
comp.DAL.INPUT.ANCHOR-CANDIDATE.v1_0DAL anchor candidate for critical outcomes.
comp.AII.INPUT.VALIDATION-TELEMETRY.v1_0AII validation telemetry.
comp.DSAIL.INPUT.VALIDATION-FEEDBACK.v1_0AI feedback signal.

17. Canonical Input Payload​

{
  "validation_request_id": "TGVRR-2026-00001472",
  "signal_id": "SIG-2026-00001472",
  "enriched_signal_id": "TGENR-2026-00001472",
  "eco_number": "ECO-A123",
  "input_csi": "comp.TG.OUTPUT.ENRICHED-SIGNAL.v1_0",
  "validation_profile": "standard_signal_validation_v1",
  "policy_context": {
    "policy_bundle": "FAGF-2026.2",
    "tenant_overrides_allowed": false
  },
  "created_at": "2026-06-25T14:30:00Z"
}

18. Canonical Output Payload​

{
  "validation_result_id": "TGVR-2026-00001472",
  "signal_id": "SIG-2026-00001472",
  "eco_number": "ECO-A123",
  "engine_cmi": "vera.TG-VALRULE.ENGINE.VALIDATION.1_0_0",
  "meid": "MEID_SIGNAL_VALIDATE_RULES",
  "status": "passed",
  "aggregate_severity": "info",
  "aggregate_action": "pass",
  "rules_executed": 11,
  "rules_passed": 11,
  "rules_failed": 0,
  "rules_warned": 0,
  "validation_pass_ratio": 1.0,
  "validation_quality": 1.0,
  "policy_context": {
    "policy_bundle": "FAGF-2026.2",
    "validation_profile": "standard_signal_validation_v1"
  },
  "created_at": "2026-06-25T14:30:01Z"
}

19. Validation Failure Payload​

{
  "validation_failure_id": "TGVF-2026-00001472",
  "signal_id": "SIG-2026-00001892",
  "eco_number": "ECO-B456",
  "rule_code": "TG-VAL-0010",
  "rule_id": "VRR-TG-0010",
  "canonical_name": "Signature Verification Failed",
  "rule_domain": "CRYPTO",
  "rule_category": "SIGNATURE",
  "rule_function": "SIGNATURE",
  "severity": "critical",
  "action": "reject",
  "field": "proof.jws",
  "message": "Digital signature could not be verified against the referenced DID verification method.",
  "federation_relevant": true,
  "dal_anchor_required": true,
  "created_at": "2026-06-25T14:30:01Z"
}

20. Validation Rules Executed Event​

{
  "event_type": "trustgate.validation.rules_executed",
  "validation_result_id": "TGVR-2026-00001472",
  "signal_id": "SIG-2026-00001472",
  "eco_number": "ECO-A123",
  "rules_executed": 11,
  "rules_failed": 0,
  "aggregate_action": "pass",
  "engine_cmi": "vera.TG-VALRULE.ENGINE.VALIDATION.1_0_0",
  "timestamp": "2026-06-25T14:30:01Z"
}

21. Quarantine Candidate​

When a rule action requires quarantine, the engine emits a quarantine candidate.

{
  "quarantine_candidate_id": "TGQC-2026-00001892",
  "signal_id": "SIG-2026-00001892",
  "eco_number": "ECO-B456",
  "source": "validation_rule_engine",
  "reason_codes": [
    "SIGNATURE_FAILURE"
  ],
  "rule_codes": [
    "TG-VAL-0010"
  ],
  "severity": "critical",
  "required_action": "human_assurance_review",
  "created_at": "2026-06-25T14:30:01Z"
}

22. DAL Integration​

The engine produces DAL anchor candidates for:

  • blocking rule failures;
  • critical validation failures;
  • federation-relevant failures;
  • signature failures;
  • invalid DID failures;
  • invalid ECO identity failures;
  • auditor-requested validation outcomes;
  • validation registry changes when executed in assurance mode.

Example:

{
  "artifact_type": "TrustValidationRuleResult",
  "artifact_id": "TGVR-2026-00001892",
  "artifact_hash": "sha256:bc88d1...",
  "engine_cmi": "vera.TG-VALRULE.ENGINE.VALIDATION.1_0_0",
  "meid": "MEID_SIGNAL_VALIDATE_RULES",
  "aggregate_action": "reject",
  "created_at": "2026-06-25T14:30:01Z"
}

Final anchoring is performed by the TrustGate DAL Anchor Engine.

23. Replay Behaviour​

The engine must be replay deterministic.

Replay inputs include:

  • enriched signal;
  • validation profile;
  • rule registry snapshot;
  • rule domain/category/function snapshots;
  • policy bundle;
  • schema snapshot;
  • identity snapshot;
  • DAL verification snapshot if used;
  • expression runtime version;
  • engine CMI.

Replay verification succeeds when:

Hash(ValidationRuleResultoriginal)=Hash(ValidationRuleResultreplay)Hash(ValidationRuleResult_{original}) = Hash(ValidationRuleResult_{replay})

The engine must not use live registry values during replay. It must use the snapshot that was active at original execution time.

24. Federation Behaviour​

Federation-relevant rules affect AFLE and EGFS exchange.

Rules marked federation_relevant = true may block:

  • outbound attestation exchange;
  • inbound federation package acceptance;
  • Carbon Passport trust reference exchange;
  • cross-ECO replay reference acceptance;
  • external auditor evidence package publication.

Federation-safe validation outputs may include rule codes and severity, but sensitive internal diagnostic detail must be redacted according to the federation profile.

25. AI / DSAIL Integration​

Validation outcomes provide important learning signals.

DSAIL may consume:

  • repeated rule failures;
  • rule failure clusters;
  • validation drift;
  • false positive/false negative reviewer outcomes;
  • federation validation failures;
  • metric-specific failure patterns;
  • source system quality patterns.

AI may recommend:

  • rule tuning;
  • sampling changes;
  • supplier review;
  • schema migration support;
  • policy review.

AI may not:

  • suppress validation rules;
  • downgrade non-overridable severity;
  • modify validation facts;
  • alter registry rule definitions without governance approval.

26. AII Integration​

Validation telemetry contributes to AII integrity and transparency dimensions.

{
  "eco_number": "ECO-A123",
  "period": "2026-Q2",
  "validation_rules_executed": 184400,
  "validation_failure_rate": 0.0062,
  "critical_failure_rate": 0.0004,
  "signature_failure_rate": 0.0001,
  "identity_failure_rate": 0.0002,
  "validation_quality_avg": 0.991
}

27. Failure Handling​

FailureSeverityAction
Missing enriched signalCriticalAbort
Missing validation profileCriticalAbort
Rule registry unavailableCriticalAbort
Rule expression invalidCriticalAbort or skip if rule inactive
Expression runtime unavailableCriticalAbort
Invalid rule vocabularyCriticalAbort
Missing identity snapshotWarning/CriticalPolicy-dependent
DAL unavailableWarningQueue anchor candidate
DSAIL unavailableInfoContinue
AII unavailableWarningQueue telemetry
Tenant override invalidCriticalIgnore override and log

The engine must fail closed for mandatory validation.

28. Observability Metrics​

MetricDescription
tg_valrule_executed_totalValidation rules executed.
tg_valrule_passed_totalRules passed.
tg_valrule_failed_totalRules failed.
tg_valrule_warning_totalRules producing warnings.
tg_valrule_quarantine_totalRules producing quarantine candidates.
tg_valrule_reject_totalRules producing rejection actions.
tg_valrule_abort_totalRules producing abort actions.
tg_valrule_latency_msRule execution latency.
tg_valrule_registry_load_msRegistry lookup latency.
tg_valrule_by_code_totalRule execution count by code.

29. Performance Targets​

MetricTarget
Rule registry load latency< 30 ms cached
Average rule execution latency< 2 ms per rule
Full rule profile latency< 50 ms
P95 full profile latency< 120 ms
Throughput20,000 validation profiles/sec per worker pool
Replay determinism100% with registry snapshots
Availability99.99%

30. Security Requirements​

The engine must:

  • execute only approved rule expression languages;
  • sandbox expression execution;
  • prevent arbitrary code execution;
  • validate rule definitions before activation;
  • enforce registry status values;
  • prevent unauthorized tenant overrides;
  • preserve rule version and registry snapshot;
  • record MEID and CMI in every output;
  • prevent sensitive data leakage in failure messages;
  • produce audit events for critical failures;
  • enforce immutable replay snapshots.

31. Compliance Alignment​

FrameworkValidation Rule Engine Contribution
CSRDSupports controlled validation of sustainability data before disclosure.
ESRSSupports data quality, completeness, traceability, and auditability.
ISSB / IFRS S1-S2Supports investor-grade data control and validation evidence.
ISO 14064-1Supports GHG data validation and assurance workflows.
ISO 27001Supports registry governance, access control, logging, and integrity.
EU AI ActPrevents AI from overriding governed validation rules.
W3C DID / VCSupports identity and proof validation for assurance artifacts.

32. Developer Implementation Notes​

Developers should implement the Validation Rule Engine as a registry-driven, deterministic, sandboxed rule executor.

Recommended design:

  • rule profile resolver;
  • registry snapshot loader;
  • rule applicability filter;
  • deterministic rule sorter;
  • CEL expression runtime adapter;
  • rule result mapper;
  • severity/action aggregator;
  • validation failure publisher;
  • quarantine candidate publisher;
  • DAL anchor candidate publisher;
  • AII telemetry publisher;
  • DSAIL feedback publisher;
  • replay snapshot binder.

Rule definitions must be validated before activation in ZAR. Invalid active rules are platform governance defects and should trigger FAGF review.

33. Summary​

The TrustGate Validation Rule Engine is the governed runtime executor for platform validation rules.

It executes ZAR-registered validation logic against enriched TrustGate signals and produces deterministic, replayable, audit-ready validation outcomes.

This engine is the clean boundary between structural validity and trust evaluation. It ensures that only rule-compliant, registry-verified, identity-aware, and policy-compatible signals can proceed to TrustGate business rule evaluation and scoring.



GitHub RepoRequest for Change (RFC)