Skip to main content
Jira progress: loading…

TG-QUARANTINE-MANAGER

TrustGate Quarantine Manager 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 Quarantine Manager Engine manages signals that cannot safely proceed through the ZAYAZ assurance pipeline.

It receives quarantine candidates from the TrustGate Decision Engine and converts them into controlled, auditable quarantine records with review status, evidence requirements, remediation paths, replay hooks, and DAL-anchorable audit events.

A quarantined signal is not deleted and not silently ignored. It is isolated from downstream sustainability calculations, disclosures, Carbon Passport assembly, federation export, and regulatory reporting until the required review or remediation has completed.

The engine exists to ensure that low-trust data is handled through a controlled assurance workflow rather than contaminating downstream computations.


2. Position within TrustGate Runtime

Trust Scoring


Decision Engine

├── ACCEPT
├── ROUTE
├── REVIEW
├── ESCALATE
└── QUARANTINE


──────────────────────────────────────────
Quarantine Manager Engine
──────────────────────────────────────────

├── Review Task
├── Evidence Request
├── Replay Trigger
├── Remediation Workflow
├── Release
└── Reject

The Quarantine Manager executes only when the Decision Engine emits a quarantine candidate or when an authorized reviewer manually places a signal into quarantine.


3. Canonical Identity

PropertyValue
MEIDMEID_TRUST_QUARANTINE_MANAGER
CMIvera.TG-QUARANTINE.ENGINE.MANAGER.1_0_0
KINDENGINE
Owner ModuleVerification & Assurance
Runtime TierTier-0 Assurance Runtime
Engine CategoryROUTE
Engine Domaintrust
ZAR RegistrationRequired
Replay SupportNative
DAL AnchoringRequired
Federation AwareYes

4. Runtime Responsibilities

ResponsibilityDescription
Quarantine Record CreationConvert quarantine candidates into immutable quarantine records.
Isolation EnforcementPrevent quarantined signals from entering downstream processing.
Review Task CreationGenerate human review tasks with required evidence and reviewer role.
Evidence ManagementTrack requested, submitted, accepted, and rejected evidence.
Replay TriggeringInitiate replay when policy requires independent reproducibility checks.
Remediation RoutingRoute signals to supplier correction, internal review, or auditor workflows.
Status ManagementManage lifecycle transitions from open to released, rejected, expired, or escalated.
Audit EvidenceEmit quarantine events suitable for DAL anchoring and OARM replay.
AI FeedbackEmit quarantine outcomes to DSAIL for trust calibration.
AII TelemetryProvide quarantine rates and aging metrics for AII.

The engine must never modify the original signal payload. It only manages quarantine state and review metadata.


5. Quarantine Lifecycle

Candidate


Open

├── Evidence Requested
│ │
│ ▼
│ Evidence Submitted
│ │
│ ▼
│ Under Review

├── Replay Required
│ │
│ ▼
│ Replay Completed

├── Escalated

├── Released

├── Rejected

└── Expired
StateMeaning
CANDIDATEDecision Engine has proposed quarantine.
OPENQuarantine record has been created.
EVIDENCE_REQUESTEDAdditional evidence has been requested.
EVIDENCE_SUBMITTEDEvidence has been supplied by source, supplier, or reviewer.
UNDER_REVIEWAuthorized reviewer is evaluating the case.
REPLAY_REQUIREDReplay must complete before release or rejection.
ESCALATEDCase is escalated to assurance, governance, or security.
RELEASEDSignal is approved to re-enter the pipeline.
REJECTEDSignal is permanently rejected for the current processing cycle.
EXPIREDQuarantine exceeded the maximum policy window.

Only terminal states may close the quarantine record.


6. Quarantine Reasons

Reason CodeDescription
LOW_TRUST_SCORETrust score below quarantine threshold.
LOW_CONFIDENCEConfidence below configured minimum.
BLOCKING_RULE_FAILUREOne or more blocking validation or assurance rules failed.
INVALID_IDENTITYECO Number, DID, or identity metadata failed validation.
SIGNATURE_FAILURESignature or cryptographic validation failed.
FEDERATION_CONFLICTCross-ECO attestation or federation metadata conflict.
REPLAY_DRIFTReplay output diverged from original output.
POLICY_VIOLATIONActive policy requires quarantine.
MISSING_EVIDENCERequired evidence is missing.
MANUAL_HOLDAuthorized user manually placed signal on hold.

Reason codes should align with the platform-wide Validation Rule Registry where applicable.


7. Runtime Processing Pipeline

Receive Quarantine Candidate


Validate Candidate


Load Quarantine Policy


Create Quarantine Record


Determine Evidence Requirements


Determine Reviewer Role


Emit Quarantine Event


Create Review / Remediation Task


Block Downstream Processing

8. Processing Algorithm

function quarantine(candidate, policy_context):

validate_candidate(candidate)

policy = load_quarantine_policy(policy_context)

record = create_quarantine_record(candidate, policy)

evidence_requirements = resolve_evidence_requirements(
candidate.reason_codes,
policy
)

reviewer = resolve_reviewer_role(
candidate.severity,
candidate.domain,
policy
)

if policy.requires_replay(candidate):
create_replay_trigger(record)

if policy.requires_escalation(candidate):
create_escalation(record)

emit_quarantine_event(record)

block_downstream_processing(record.signal_id)

return record

The engine must fail closed. If the quarantine candidate cannot be safely evaluated, the signal remains isolated.


9. Quarantine Decision Rules

ConditionRequired Action
Trust score < 0.50Open quarantine record.
Signature failureOpen quarantine and reject federation export.
Invalid ECO NumberOpen quarantine and escalate identity review.
Replay drift > policy thresholdOpen quarantine and trigger OARM replay.
Missing Carbon Passport evidenceRequest evidence from supplier.
Federation conflictEscalate to AFLE/FAGF review.
Manual holdPreserve hold until authorized release.

Quarantine rules must be registered in the Validation Rule Registry or the FAGF policy registry.


10. CSI Contracts

10.1. Input CSIs

CSIRequiredPurpose
comp.TG.INPUT.QUARANTINE-CANDIDATE.v1_0YesQuarantine candidate emitted by the Decision Engine.
comp.TG.INPUT.TRUST-DECISION.v1_0YesDecision outcome and reason.
comp.TG.INPUT.POLICY-CONTEXT.v1_0YesActive quarantine policy.
comp.TG.INPUT.RULE-RESULT.v1_0NoRule failures and severities.
comp.OARM.INPUT.REPLAY-SUMMARY.v1_0NoReplay status and replay drift.
comp.AFLE.INPUT.ATTESTATION-SUMMARY.v1_0NoFederation attestation context.
comp.TG.INPUT.REVIEWER-ACTION.v1_0NoManual reviewer action.
comp.TG.INPUT.EVIDENCE-SUBMISSION.v1_0NoAdditional evidence submission.

10.2. Output CSIs

CSIPurpose
comp.TG.OUTPUT.QUARANTINE-RECORD.v1_0Canonical quarantine record.
comp.TG.OUTPUT.REVIEW-TASK.v1_0Human review task.
comp.TG.OUTPUT.EVIDENCE-REQUEST.v1_0Evidence request object.
comp.TG.EVENT.QUARANTINE-CREATED.v1_0Runtime quarantine creation event.
comp.TG.EVENT.QUARANTINE-RELEASED.v1_0Release event.
comp.TG.EVENT.QUARANTINE-REJECTED.v1_0Rejection event.
comp.DSAIL.INPUT.QUARANTINE-FEEDBACK.v1_0AI learning feedback.
comp.AII.INPUT.QUARANTINE-TELEMETRY.v1_0AII quarantine telemetry.

11. Canonical Input Payload

{
"quarantine_candidate_id": "TGQC-2026-00001472",
"signal_id": "SIG-2026-00001472",
"eco_number": "ECO-B456",
"decision_id": "TGD-2026-00001472",
"decision": "QUARANTINE",
"trust_score": 0.421,
"confidence": 0.582,
"reason_codes": [
"LOW_TRUST_SCORE",
"BLOCKING_RULE_FAILURE"
],
"rule_codes": [
"TG-VAL-0008",
"TG-VAL-0010"
],
"severity": "critical",
"policy_context": {
"policy_bundle": "FAGF-2026.2",
"quarantine_profile": "generic_assurance_quarantine_v1"
},
"created_at": "2026-06-25T12:22:44Z"
}

12. Canonical Output Payload

{
"quarantine_id": "TGQ-2026-00001472",
"signal_id": "SIG-2026-00001472",
"eco_number": "ECO-B456",
"engine_cmi": "vera.TG-QUARANTINE.ENGINE.MANAGER.1_0_0",
"meid": "MEID_TRUST_QUARANTINE_MANAGER",
"status": "OPEN",
"severity": "critical",
"reason_codes": [
"LOW_TRUST_SCORE",
"BLOCKING_RULE_FAILURE"
],
"rule_codes": [
"TG-VAL-0008",
"TG-VAL-0010"
],
"required_actions": [
"human_assurance_review",
"identity_revalidation",
"signature_recheck"
],
"evidence_required": [
"valid_did_document",
"signature_proof",
"source_system_confirmation"
],
"review": {
"required_role": "assurance_reviewer",
"sla_hours": 48
},
"downstream_blocked": true,
"created_at": "2026-06-25T12:22:44Z"
}

13. Quarantine Event

{
"event_type": "trustgate.quarantine.created",
"quarantine_id": "TGQ-2026-00001472",
"signal_id": "SIG-2026-00001472",
"eco_number": "ECO-B456",
"severity": "critical",
"reason_codes": [
"LOW_TRUST_SCORE",
"BLOCKING_RULE_FAILURE"
],
"engine_cmi": "vera.TG-QUARANTINE.ENGINE.MANAGER.1_0_0",
"timestamp": "2026-06-25T12:22:44Z"
}

14. Evidence Request

{
"evidence_request_id": "TGER-2026-00001472",
"quarantine_id": "TGQ-2026-00001472",
"signal_id": "SIG-2026-00001472",
"requested_from": "ECO-B456",
"evidence_types": [
"valid_did_document",
"signature_proof",
"source_system_confirmation"
],
"due_at": "2026-06-27T12:22:44Z",
"status": "OPEN"
}

Evidence requests may be sent to suppliers, internal data owners, auditors, or federation counterparties depending on the quarantine profile.


15. Release Event

{
"event_type": "trustgate.quarantine.released",
"quarantine_id": "TGQ-2026-00001472",
"signal_id": "SIG-2026-00001472",
"released_by": "assurance_reviewer",
"release_reason": "identity_revalidated_and_signature_verified",
"reentry_route": "trustgate.rescore",
"timestamp": "2026-06-26T09:14:03Z"
}

Released signals must normally re-enter the pipeline at the earliest required safe stage. Most releases should re-enter at Trust Scoring or Decision, not directly into downstream reporting.


16. Rejection Event

{
"event_type": "trustgate.quarantine.rejected",
"quarantine_id": "TGQ-2026-00001472",
"signal_id": "SIG-2026-00001472",
"rejected_by": "assurance_reviewer",
"rejection_reason": "signature_verification_failed_after_evidence_review",
"final": true,
"timestamp": "2026-06-26T11:02:19Z"
}

Rejected signals are excluded from the current reporting and assurance cycle unless explicitly re-submitted as a new signal.


17. DAL Integration

The Quarantine Manager produces DAL anchor candidates for:

  • quarantine creation;
  • evidence requests;
  • evidence submissions;
  • reviewer actions;
  • release events;
  • rejection events;
  • escalation events.
{
"artifact_type": "TrustQuarantineEvent",
"artifact_id": "TGQ-2026-00001472",
"artifact_hash": "sha256:8bc22e...",
"engine_cmi": "vera.TG-QUARANTINE.ENGINE.MANAGER.1_0_0",
"meid": "MEID_TRUST_QUARANTINE_MANAGER",
"status": "OPEN",
"created_at": "2026-06-25T12:22:44Z"
}

Final anchoring is performed by the TrustGate DAL Anchor Engine.


18. Replay Behaviour

The engine must be replay deterministic for quarantine creation and lifecycle transition validation.

Replay inputs include:

  • quarantine candidate;
  • decision event;
  • rule result;
  • policy context;
  • evidence request policy;
  • reviewer action metadata;
  • engine CMI.

Replay verification for creation succeeds when:

Hash(QuarantineRecordoriginal)=Hash(QuarantineRecordreplay)Hash(QuarantineRecord_{original}) = Hash(QuarantineRecord_{replay})

Reviewer actions may be replayed as event-sequence verification rather than regenerated decisions.


19. Federation Behaviour

Quarantine records may affect federation trust.

EventFederation Relevance
Signature failureHigh
Invalid DIDHigh
Federation conflictHigh
Carbon Passport evidence missingMedium
Low local trust scoreOptional
Manual holdOptional

Federation exports must respect FAGF and AFLE disclosure profiles.

Sensitive internal review notes must not be exported unless explicitly authorized.


20. AI Integration

The engine emits quarantine outcomes to DSAIL.

AI may recommend:

  • reviewer prioritization;
  • likely remediation route;
  • evidence type suggestions;
  • expected resolution probability;
  • anomaly clusters;
  • supplier risk escalation.

AI may not:

  • release a signal;
  • reject a signal;
  • override reviewer decisions;
  • bypass quarantine;
  • suppress mandatory evidence requirements.
{
"event_type": "trustgate.quarantine.feedback",
"quarantine_id": "TGQ-2026-00001472",
"reason_codes": [
"LOW_TRUST_SCORE",
"BLOCKING_RULE_FAILURE"
],
"resolution": "released",
"resolution_time_hours": 20.8,
"model_training_allowed": true
}

21. AII Integration

Quarantine metrics contribute to the Assurance Intelligence Index.

{
"eco_number": "ECO-B456",
"period": "2026-Q2",
"quarantine_count": 38,
"quarantine_rate": 0.0035,
"avg_quarantine_age_hours": 18.4,
"release_rate": 0.71,
"rejection_rate": 0.18,
"escalation_rate": 0.11,
"top_reasons": [
"LOW_TRUST_SCORE",
"MISSING_EVIDENCE",
"SIGNATURE_FAILURE"
]
}

22. Failure Handling

FailureSeverityAction
Missing quarantine candidateCriticalAbort
Missing decision referenceCriticalAbort
Missing policy contextCriticalAbort
Invalid status transitionCriticalReject transition
Missing reviewer authorizationCriticalReject action
Missing evidence metadataWarningKeep open
DAL unavailableWarningQueue anchor candidate
AAE unavailableWarningContinue if replay not mandatory
DSAIL unavailableInfoContinue
Federation unavailableWarningContinue local quarantine

The engine must fail closed. Unsafe or incomplete quarantine transitions must not be applied.


23. Observability Metrics

MetricDescription
tg_quarantine_created_totalTotal quarantine records created.
tg_quarantine_open_totalCurrently open quarantine records.
tg_quarantine_released_totalReleased records.
tg_quarantine_rejected_totalRejected records.
tg_quarantine_escalated_totalEscalated records.
tg_quarantine_avg_age_hoursAverage age of open records.
tg_quarantine_sla_breach_totalRecords exceeding SLA.
tg_quarantine_by_reason_totalCount by reason code.
tg_quarantine_replay_trigger_totalReplay triggers caused by quarantine.

24. Performance Targets

MetricTarget
Quarantine creation latency< 50 ms
Evidence request creation latency< 100 ms
Status transition latency< 50 ms
Review task creation latency< 250 ms
Throughput5,000 quarantine events/sec per worker pool
Availability99.99%
Replay determinism100%

25. Security Requirements

The engine must:

  • enforce role-based access control for reviewer actions;
  • verify reviewer identity;
  • verify ECO ownership or authorized review scope;
  • prevent unauthorized release;
  • preserve original payload immutability;
  • redact sensitive evidence before federation export;
  • log all lifecycle transitions;
  • require approval for terminal state changes where policy mandates;
  • record MEID and CMI in all events;
  • prevent direct downstream processing while status is non-terminal.

26. Compliance Alignment

FrameworkQuarantine Manager Contribution
CSRDSupports controlled remediation and auditability of low-quality sustainability data.
ESRSSupports data quality, uncertainty, and control evidence.
ISSB / IFRS S1-S2Supports governance of decision-useful sustainability information.
ISO 14064-1Supports evidence management and verification workflow control.
ISO 27001Supports controlled access and audit logging.
EU AI ActEnsures AI cannot release or reject quarantined records autonomously.

27. Developer Implementation Notes

Developers should implement the Quarantine Manager as a stateful workflow engine with immutable event sourcing.

Recommended design:

  • immutable quarantine event log;
  • current-state materialized view;
  • workflow transition validator;
  • evidence object store;
  • reviewer task integration;
  • DAL anchor queue;
  • OARM replay trigger queue;
  • DSAIL feedback event publisher.

The original signal payload must remain immutable and separately referenced.


28. Summary

The TrustGate Quarantine Manager Engine ensures that low-trust, invalid, incomplete, suspicious, or policy-violating signals are isolated and handled through auditable assurance workflows.

It protects downstream ESG calculations, Carbon Passports, disclosures, federation attestations, and regulatory outputs from contamination by unverified data.

No quarantined signal may re-enter the ZAYAZ assurance pipeline without a valid release event generated by this engine or an equivalent FAGF-authorized workflow.




GitHub RepoRequest for Change (RFC)