Skip to main content
Jira progress: loading…

TG-REPLAY-ENGINE

TrustGate Replay 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 Replay Engine produces the deterministic replay artifacts required to reconstruct, verify, and audit TrustGate processing outcomes.

It is responsible for packaging the exact inputs, configuration, schemas, policies, engine versions, lineage references, and output hashes needed to independently re-execute a TrustGate assessment.

The engine supports the ZAYAZ Operational Assurance and Replay Mechanisms (OARM) by ensuring that every TrustGate score, decision, quarantine event, attestation, and DAL anchor candidate can be reproduced using the same data and software versions that existed at the time of original execution.

Replay is not a debugging convenience. In ZAYAZ, replay is a core assurance primitive.


2. Position within TrustGate Runtime

Parser


Structure Validation


Normalizer


Context Enrichment


Rule Evaluation


Policy Resolution


Trust Scoring


Decision / Quarantine


──────────────────────────────────────────
Replay Engine
──────────────────────────────────────────

├── Replay Manifest
├── Replay Input Bundle
├── Output Hashes
├── Engine Version Map
├── Policy Snapshot
└── DAL Anchor Candidate

The Replay Engine may execute:

  • after a TrustGate decision;
  • after quarantine creation;
  • on auditor request;
  • on DAL verification failure;
  • on DSAIL drift detection;
  • on FAGF policy mandate;
  • on AFLE federation verification request.

3. Canonical Identity

PropertyValue
MEIDMEID_TRUST_REPLAY_COORDINATOR
CMIvera.TG-REPLAY.ENGINE.COORDINATOR.1_0_0
KINDENGINE
Owner ModuleVerification & Assurance
Runtime TierTier-0 Assurance Runtime
Engine CategoryREPLAY
Engine Domaintrust
ZAR RegistrationRequired
Replay SupportNative
DAL AnchoringRequired
Federation AwareYes

The MEID identifies the stable logical replay engine.

The CMI identifies this specific versioned implementation.


4. Runtime Responsibilities

ResponsibilityDescription
Replay Manifest CreationCreate the canonical manifest describing what must be replayed.
Input Bundle AssemblyCollect input objects, hashes, policies, schemas, and engine versions.
Determinism VerificationVerify whether all required replay prerequisites are present.
Output Hash RegistrationRecord original output hashes for future replay comparison.
Engine Version MappingCapture the exact CMIs used during original processing.
Policy Snapshot CapturePreserve active policy, rule, and scoring configuration references.
USO Lineage BindingBind replay artifacts to the operational lineage graph.
DAL Anchor PreparationProduce DAL anchor candidates for replay manifests and results.
OARM InterfaceProvide replay artifacts to OARM and AAE for independent execution.
Drift Event EmissionEmit replay drift events when replayed outputs diverge.

The engine must not modify original TrustGate outcomes.


5. Replay Types

TrustGate supports several replay types.

Replay TypePurpose
FULL_PIPELINE_REPLAYRe-executes the full TrustGate pipeline from parsed signal to decision.
SCORE_REPLAYRecomputes only the Trust Score and confidence.
DECISION_REPLAYRecomputes only the decision outcome.
QUARANTINE_REPLAYReplays quarantine creation or lifecycle transition.
ATTESTATION_REPLAYReconstructs trust attestation payloads.
FEDERATION_REPLAYReconstructs cross-ECO exchange evidence.
AUDITOR_REPLAYReplay package prepared for external assurance review.

Replay type is determined by policy, auditor request, or system trigger.


6. Replay Determinism Model

Replay verification is based on deterministic output equality.

A replay succeeds when:

Hash(Outputoriginal)=Hash(Outputreplay)Hash(Output_{original}) = Hash(Output_{replay})

A replay fails when:

Hash(Outputoriginal)Hash(Outputreplay)Hash(Output_{original}) \neq Hash(Output_{replay})

Where output hash must be computed over a canonicalized serialization format.

The Replay Engine must therefore preserve:

  • canonical input hash;
  • canonical output hash;
  • CMI versions;
  • policy version;
  • CSI versions;
  • schema versions;
  • rule versions;
  • timestamp normalization rules;
  • external lookup snapshots;
  • deterministic random seed, where relevant.

7. Replay Manifest

The replay manifest is the canonical description of a replayable TrustGate execution.

Example:

{
"replay_id": "TGR-2026-00001472",
"replay_type": "FULL_PIPELINE_REPLAY",
"signal_id": "SIG-2026-00001472",
"eco_number": "ECO-A123",
"uso_id": "USO-98122",
"original_decision_id": "TGD-2026-00001472",
"created_by_engine": "vera.TG-REPLAY.ENGINE.COORDINATOR.1_0_0",
"meid": "MEID_TRUST_REPLAY_COORDINATOR",
"replayable": true,
"created_at": "2026-06-25T12:34:10Z"
}

8. Replay Input Bundle

The replay input bundle contains all deterministic replay prerequisites.

{
"replay_id": "TGR-2026-00001472",
"input_bundle": {
"raw_signal_hash": "sha256:11b0c2...",
"parsed_signal_hash": "sha256:904ad1...",
"normalized_signal_hash": "sha256:ab88e0...",
"enriched_signal_hash": "sha256:7010ca...",
"validation_result_hash": "sha256:4cb902...",
"rule_result_hash": "sha256:20aa9e...",
"policy_context_hash": "sha256:332fd4...",
"score_result_hash": "sha256:11de3f...",
"decision_hash": "sha256:2f93ad..."
}
}

The bundle references immutable artifacts. It does not duplicate sensitive raw data unless policy explicitly permits.


9. Engine Version Map

Every replay manifest must record the engine CMIs used during the original execution.

{
"engine_versions": {
"parser": "vera.TG-PARSE.ENGINE.SIGNAL.1_0_0",
"structure_validator": "vera.TG-VALIDATE.ENGINE.STRUCTURE.1_0_0",
"normalizer": "vera.TG-NORM.ENGINE.NORMALIZER.1_0_0",
"context_enrichment": "vera.TG-ENRICH.ENGINE.CONTEXT.1_0_0",
"rule_evaluator": "vera.TG-RULE.ENGINE.EVALUATOR.1_0_0",
"policy_resolver": "vera.TG-POLICY.ENGINE.RESOLVER.1_0_0",
"trust_scorer": "vera.TG-SCORE.ENGINE.CALCULATOR.1_0_0",
"decision_engine": "vera.TG-DECISION.ENGINE.ROUTER.1_0_0"
}
}

If any required CMI is unavailable, replay status must be NOT_REPLAYABLE.


10. Runtime Processing Pipeline

Receive Replay Trigger


Resolve Original Execution


Collect Engine Versions


Collect Input Hashes


Collect Policy Snapshot


Collect Schema Snapshot


Validate Replay Preconditions


Create Replay Manifest


Create Replay Bundle


Emit Replay Artifact


Queue DAL Anchor Candidate

The engine prepares replay. OARM or AAE performs independent re-execution.


11. Processing Algorithm

function prepare_replay(trigger):

original_execution = resolve_execution(trigger.signal_id)

engine_versions = collect_engine_cmis(original_execution)

input_hashes = collect_input_hashes(original_execution)

policy_snapshot = collect_policy_snapshot(original_execution)

schema_snapshot = collect_schema_snapshot(original_execution)

preconditions = validate_replay_preconditions(
engine_versions,
input_hashes,
policy_snapshot,
schema_snapshot
)

manifest = create_replay_manifest(
trigger,
original_execution,
preconditions
)

bundle = create_replay_input_bundle(
manifest,
input_hashes,
engine_versions,
policy_snapshot,
schema_snapshot
)

emit_replay_created_event(manifest)

queue_dal_anchor_candidate(manifest, bundle)

return manifest

12. Replay Preconditions

PreconditionRequired
Original signal reference existsYes
USO lineage existsYes
Required CMIs exist in ZARYes
Required CSIs exist in SSSRYes
Policy snapshot existsYes
Original output hash existsYes
DAL anchor exists or candidate existsYes
External lookup snapshots availableConditional
AI model version availableConditional
Federation attestation availableConditional

Failure of a mandatory precondition prevents replay.


13. CSI Contracts

13.1. Input CSIs

CSIRequiredPurpose
comp.TG.INPUT.REPLAY-TRIGGER.v1_0YesReplay request or trigger event.
comp.TG.INPUT.TRUST-DECISION.v1_0ConditionalDecision to replay.
comp.TG.INPUT.TRUST-SCORE.v1_0ConditionalScore to replay.
comp.USO.INPUT.LINEAGE-GRAPH.v1_0YesOperational lineage graph.
comp.ZAR.INPUT.ENGINE-VERSION-MAP.v1_0YesEngine version map.
comp.SSSR.INPUT.SCHEMA-SNAPSHOT.v1_0YesSchema snapshot.
comp.FAGF.INPUT.POLICY-SNAPSHOT.v1_0YesPolicy snapshot.

13.2. Output CSIs

CSIPurpose
comp.TG.OUTPUT.REPLAY-MANIFEST.v1_0Canonical replay manifest.
comp.TG.OUTPUT.REPLAY-BUNDLE.v1_0Replay input bundle.
comp.TG.EVENT.REPLAY-CREATED.v1_0Replay artifact creation event.
comp.TG.EVENT.REPLAY-DRIFT.v1_0Replay drift event.
comp.OARM.INPUT.REPLAY-ARTIFACT.v1_0OARM replay artifact.
comp.AII.INPUT.REPLAY-TELEMETRY.v1_0Replay telemetry for AII.

14. Replay Created Event

{
"event_type": "trustgate.replay.created",
"replay_id": "TGR-2026-00001472",
"replay_type": "FULL_PIPELINE_REPLAY",
"signal_id": "SIG-2026-00001472",
"eco_number": "ECO-A123",
"replayable": true,
"engine_cmi": "vera.TG-REPLAY.ENGINE.COORDINATOR.1_0_0",
"timestamp": "2026-06-25T12:34:10Z"
}

15. Replay Result Event

When OARM or AAE completes execution, the Replay Engine may record the returned result.

{
"event_type": "trustgate.replay.result",
"replay_id": "TGR-2026-00001472",
"result": "PASS",
"original_output_hash": "sha256:2f93ad...",
"replay_output_hash": "sha256:2f93ad...",
"verified": true,
"completed_at": "2026-06-25T12:35:04Z"
}

16. Replay Drift Event

{
"event_type": "trustgate.replay.drift",
"replay_id": "TGR-2026-00001472",
"signal_id": "SIG-2026-00001472",
"drift_type": "DECISION_MISMATCH",
"original_value": "ACCEPT",
"replay_value": "REVIEW",
"severity": "critical",
"requires_investigation": true,
"timestamp": "2026-06-25T12:35:04Z"
}

Replay drift must trigger assurance review unless policy explicitly classifies the drift as expected and non-material.


17. DAL Integration

Replay manifests, bundles, and results produce DAL anchor candidates.

Example:

{
"artifact_type": "TrustReplayManifest",
"artifact_id": "TGR-2026-00001472",
"artifact_hash": "sha256:44b7df...",
"engine_cmi": "vera.TG-REPLAY.ENGINE.COORDINATOR.1_0_0",
"meid": "MEID_TRUST_REPLAY_COORDINATOR",
"replay_type": "FULL_PIPELINE_REPLAY",
"created_at": "2026-06-25T12:34:10Z"
}

Replay result hashes should also be anchored when verification completes.


18. OARM and AAE Integration

The Replay Engine is a TrustGate-side producer of replay artifacts.

OARM and AAE act as independent replay executors and assurance verifiers.

SystemRole
TrustGate Replay EngineCreates replay artifacts and manifests.
OARMDefines operational replay workflow and auditor-facing replay mechanisms.
AAEExecutes autonomous replay and consistency checks.
DALAnchors replay artifacts and replay outcomes.
VIZZDisplays replay status, drift, and investigation workflow.

The Replay Engine must not self-certify replay pass/fail without independent execution.


19. Federation Behaviour

Federated replay packages may be created for AFLE and EGFS verification.

Federated replay packages must include:

FieldRequired
ECO NumberYes
DIDYes
Replay ManifestYes
Engine Version MapYes
Original Output HashYes
DAL ReferenceYes
Policy ReferenceYes
Sensitive Data Redaction MapConditional

Raw sensitive payloads must not be exported unless allowed by FAGF policy and federation profile.


20. AI Integration

Replay results are high-value DSAIL learning signals.

The engine emits:

  • replay pass/fail;
  • replay drift type;
  • drift magnitude;
  • affected engine;
  • policy context;
  • signal domain;
  • remediation outcome.

AI may use replay outcomes to recommend:

  • trust model recalibration;
  • increased sampling;
  • rule tuning;
  • supplier risk updates;
  • policy review.

AI must not suppress replay drift events.


21. AII Integration

Replay telemetry contributes to the Assurance Intelligence Index.

{
"eco_number": "ECO-A123",
"period": "2026-Q2",
"replay_count": 1240,
"replay_success_rate": 0.998,
"replay_drift_rate": 0.002,
"critical_drift_count": 1,
"avg_replay_latency_seconds": 8.4
}

22. Failure Handling

FailureSeverityAction
Missing original executionCriticalAbort
Missing USO lineageCriticalAbort
Missing CMICriticalMark not replayable
Missing schema snapshotCriticalMark not replayable
Missing policy snapshotCriticalMark not replayable
Missing output hashCriticalAbort
Missing external lookup snapshotWarningConditional replay
OARM unavailableWarningQueue replay artifact
DAL unavailableWarningQueue anchor candidate
AI unavailableInfoContinue

The engine must never claim replayability when mandatory replay prerequisites are missing.


23. Observability Metrics

MetricDescription
tg_replay_manifest_created_totalReplay manifests created.
tg_replay_not_replayable_totalReplay requests that cannot be replayed.
tg_replay_result_pass_totalSuccessful replay results.
tg_replay_result_fail_totalFailed replay results.
tg_replay_drift_totalReplay drift events.
tg_replay_latency_secondsEnd-to-end replay execution latency.
tg_replay_missing_cmi_totalMissing engine version references.
tg_replay_missing_policy_totalMissing policy snapshots.

24. Performance Targets

MetricTarget
Replay manifest creation latency< 100 ms
Replay bundle assembly latency< 250 ms
Replay precondition validation< 150 ms
Throughput2,000 replay artifacts/sec per worker pool
Replay determinism100% where prerequisites exist
Availability99.99%

25. Security Requirements

The engine must:

  • restrict replay requests to authorized services and users;
  • preserve sensitive data boundaries;
  • enforce federation redaction profiles;
  • validate CMIs against ZAR;
  • validate policy snapshots against FAGF;
  • record every replay request;
  • prevent tampering with original output hashes;
  • prevent replay artifact mutation after creation;
  • record MEID and CMI in every output;
  • emit replay audit logs.

Replay artifacts must be immutable after creation.


26. Compliance Alignment

FrameworkReplay Engine Contribution
CSRDSupports verifiable reconstruction of reported data decisions.
ESRSSupports auditability, methodology transparency, and traceability.
ISSB / IFRS S1-S2Supports investor-grade assurance controls.
ISO 14064-1Supports GHG data verification and reproducibility.
ISO 27001Supports controlled audit logs and integrity evidence.
EU AI ActSupports replayable AI-influenced decisions and model traceability.

27. Developer Implementation Notes

Developers should implement the Replay Engine as an immutable artifact assembler and replay coordinator, not as a self-contained replay executor.

Recommended design:

  • replay manifest builder;
  • replay precondition validator;
  • input hash collector;
  • engine CMI resolver;
  • policy snapshot resolver;
  • schema snapshot resolver;
  • DAL anchor candidate queue;
  • OARM replay handoff;
  • replay result listener;
  • drift event publisher.

Replay bundles should reference immutable artifacts wherever possible rather than duplicating sensitive source data.


28. Summary

The TrustGate Replay Engine ensures that every TrustGate assessment can be reconstructed and independently verified.

It creates the replay artifacts required for OARM, AAE, DAL, auditors, regulators, and federation participants to validate that TrustGate outcomes were produced deterministically from known data, known software, known policy, and known schema versions.

No TrustGate assessment should be considered assurance-ready unless it has an associated replay manifest or a documented policy exception.




GitHub RepoRequest for Change (RFC)