Phase 0 Truth Audit

backfillEnvironmentTags applied DEMO tag to 100% of records (1,200+); platform RLS via created_by_id + admin-only user mgmt

Asset: TenantConfig, backfillEnvironmentTags

RoleGuard on admin routes + permissionProfiles (9 role→product maps) + useSmartNavigation filters sidebar by entitlements

Asset: RoleGuard, permissionProfiles, useSmartNavigation

resolveLicence() walks hierarchy for active ProductLicense; nav filtered by entitlements; ProductSwitcher enforces

Asset: productRegistry.js, ProductLicense

productRegistry.js: PROD-BEYOND_COMPLIANCE(platform)→MULEGUARD_ENTERPRISE(suite)→AMLGuard/ScreeningGuard/KYCGuard/PSPM(products)

Asset: productRegistry.js

WorkflowRun entity reused across 4 distinct workflow_ids; runWorkflowsForTrigger is the shared dispatch engine

Asset: WorkflowTemplate, WorkflowRun, runWorkflowsForTrigger

2,090 audit logs + 94 evidence packs active; actor/tenant/correlation fields verified

Asset: AuditLog, EvidencePack

canonicalMetrics backend function returns true counts (no 1000 cap) + status/risk distributions; wired to TruthAudit

Asset: canonicalMetrics, TruthAudit.jsx

BulkImport creates as "received" then auto-screens; manual Receive & Screen dialog added

Asset: BulkTransactionImport, ReceiveTransactionDialog

Schema updated: received/validated/screening/passed/alerted/held/stopped/rejected/released/returned

Asset: Transaction entity

Shared scoring module + screenTransaction: validates→scores→explains; wired to ingestion

Asset: shared/screening.ts, screenTransaction

screenTransaction returns decision + thresholds (alert 30/hold 50/stop 70/reject 85)

Asset: screenTransaction, shared/screening.ts

manageTransactionHold enforces state transitions; UI actions wired on Transactions page

Asset: manageTransactionHold, Transactions.jsx

Detections page: filters, grouped view, status transitions, alert→case wired

Asset: Detections.jsx

Cases workbench: notes, tasks, evidence, workflow, SLA, approval — seeded & verified

Asset: Cases.jsx, 12 seeded cases

Canonical RegulatoryFiling entity + regulatoryFiling lifecycle engine (18-state machine, SoD maker-checker, simulated submission adapter, amendments, audit per transition). End-to-end acceptance test runSarAcceptanceTest re-executed fresh (batch M1_8_20260720): recordDecision(FILING_REQUIRED)→generateDraft(narrative 915 chars, draft_version 8)→validate(READY_FOR_REVIEW, 0 errors)→submitForReview(UNDER_REVIEW)→completeReview SoD(reviewer@test.system)→approveFiling MLRO SoD(mlro@test.system)→submitFiling SIMULATED(REG-SG-1784566160263)→recordAcknowledgement(ACK-SG-1353751305)→case.sar_filed=true. 13/13 scenarios passed, 48 state transitions, 62 audit records, SoD negative test (approver==preparer) correctly blocked. sarAutoDraft delegates to lifecycle (no premature sar_filed). SARFilingsDashboard on authoritative filing records.

Asset: RegulatoryFiling, regulatoryFiling, runSarAcceptanceTest, SARFilingsDashboard, sarAutoDraft

Full suspicious-transaction→alert→case→investigation→evidence→suspicion decision→filing-required decision→draft→validation→review(SoD)→approval(SoD)→SIMULATED submission→acknowledgement→case update→audit trail. Batch M1_8_20260720, 13/13 pass. SIMULATED REGULATOR SUBMISSION clearly labelled — no live regulator connector exists.

Asset: runSarAcceptanceTest (batch M1_8_20260720)

5 sources active (OFAC, UN, EU, UK HMT, OpenSanctions); dailySanctionsSync + syncFromOpenSanctions + updateSanctionsList

Asset: SanctionsSource, dailySanctionsSync, syncFromOpenSanctions

SanctionsEntity with current_status, source_id, aliases, identifiers; 5,000+ ACTIVE records loaded

Asset: SanctionsEntity

unifiedScreeningOrchestrator: 18-step pipeline (canonical→normalize→transliterate→tokenize→alias→phonetic→match→weight→policy→decision); fuzzyMatchSanctions for lightweight calls

Asset: unifiedScreeningOrchestrator, fuzzyMatchSanctions

screenTransaction now screens counterparty_name against SanctionsEntity; hit → HOLD + SanctionsMatch record + alert linked; verified with exact 100% match test

Asset: screenTransaction, shared/screening.ts (screenAgainstSanctions)

SanctionsMatch entity (pending_review/confirmed/false_positive/cleared); SanctionsMatchReview component on Sanctions page

Asset: SanctionsMatch, SanctionsMatchReview

sanctionsHitAutoCase creates Case (type=sanctions, priority by confidence) + AISuggestion + audit log; idempotent per match

Asset: sanctionsHitAutoCase

runContinuousRescreening + runTargetedDeltaRescreen + continuousWatchlistOrchestrator; ScreeningProfile tracks next_screening_due

Asset: runContinuousRescreening, continuousWatchlistOrchestrator

generateSanctionsImpactReport + generateSanctionsSyncReport + SanctionsReportMenu; coverage report with source versions/freshness/gaps

Asset: generateSanctionsImpactReport, SanctionsReportMenu

runScreeningGuardAcceptance executed batch M2_9_20260721: 11/11 scenarios pass. Journey: create screening source (sanctions) + typology source → separation asserted (screening≠knowledge) → SIMULATED FETCH (checksum_match=true, publication_status=published) → quarantine path (quarantined source NOT counted as published) → publish 2 ACTIVE SanctionsEntity → customer screen (exact match, score 100) → match review→disposition (confirmed) → rescreen (replay run, match persists) → audit. State counts computed: configured/connected/fetched/quarantined/published/publishedEntities/failed/referenceDocuments. Fetch is SIMULATED on ACCEPT_ test sources (no live network). Quarantined data explicitly excluded from published coverage.

Asset: runScreeningGuardAcceptance (batch M2_9_20260721)

kycCreateProfile + kycCreateCustomerAndDraftProfile create profile (draft→submitted) linked to Customer; KYC page create modal wired

Asset: kycCreateProfile, KYCCreateModal

kycSubmitProfile runs real sanctions screening (unifiedScreeningOrchestrator) + pepScreening; results stored as KYCCheck records — no stubbed PASS

Asset: kycSubmitProfile, kycRunChecks, pepScreening

kycCalculateRisk: any sanctions or PEP "FAIL" forces risk_tier=critical regardless of score; verified sanctioned name → 100/critical

Asset: kycCalculateRisk

kycApproveProfile enforces submitted→approved transition with approver + audit log; KYCApproveDialog UI wired

Asset: kycApproveProfile, KYCApproveDialog

kycApproveProfile auto-creates Case (type=aml, priority by tier) for high/critical approvals; verified critical approval → AML case generated

Asset: kycApproveProfile, autoCreateAmlCase

KYCDocument + KYCParty (ownership edges) + kycAddParty; tabs on KYC profile page

Asset: KYCDocument, KYCParty, KYCPartiesTab

kycScheduleReviews sets next_review_date by risk tier; KYCRemediationTab tracks overdue reviews

Asset: kycScheduleReviews, KYCRemediationTab

KYCRemediationTask + KYCEvidencePack entities; KYCReview records capture decisions

Asset: KYCRemediationTask, KYCEvidencePack

runKYCAcceptance executed batch M3_9_20260720: 12/12 scenarios pass via service-role admin harness — onboarding→draft→document upload→verify→CDD checks (sanctions/PEP/adverse-media/IDV all PASS)→risk low→submit→maker-checker approval SoD (maker≠checker)→activate profile+customer (next_review 24mo)→periodic review cycle→ongoing monitoring rescreen→tenant isolation (accept_kyc)→audit. NOTE: exercised via service-role harness, NOT the kyc:write/submit/approve permission-gated UI path (kycCreateCustomerAndDraftProfile still 403s for the runner — a permission-scope config gap, not a lifecycle gap). The underlying KYC state machine, CDD, SoD, activation, review, monitoring, isolation and audit are real and verified.

Asset: runKYCAcceptance (batch M3_9_20260720)

runKYBAcceptance executed batch M3_10_20260720: 13/13 scenarios pass via service-role admin harness — corporate onboarding→profile draft (corporate)→parties (corporate entity + 2 UBO shareholders + director/signatory)→ownership graph (2 OWNS edges, 60/40)→UBO determination ≥25% = 2 UBOs→one-person-multiple-roles WITHOUT duplicate party records (Jane Director = 1 record, signatory via control_flags)→corporate docs (3 VERIFIED)→CDD/EDD checks (entity + per-UBO: sanctions/PEP/adverse-media/registry, 8 checks all PASS)→risk medium→submit→4-eyes approval SoD (maker≠checker)→activate (next_review 12mo)→periodic review→audit + tenant isolation (accept_kyb). NOTE: via service-role harness (kyc:* UI path still 403 for runner — config gap, not lifecycle gap).

Asset: runKYBAcceptance (batch M3_10_20260720)

runDetection evaluates pass_through, smurfing, cash_out, sleeper, vpn_onboarding, dedup_ring, velocity against active Rule entities

Asset: runDetection, Rule

computeAccountFeatures: inflow/outflow ratio, rapid cashout, unique counterparties, channel concentration, VPN ratio, shared devices, balance retention

Asset: runDetection (computeAccountFeatures)

calculateRiskScore sums rule.risk_score_contribution; mapped to low/medium/high/critical bands

Asset: runDetection (calculateRiskScore)

Creates Alert with typology, rules_triggered, amount_involved, SLA due date; verified 93 accounts → 19 alerts, 1 critical (ACC-MULE-005 @100)

Asset: runDetection → Alert

runRiskEngine scores any entity with full reason codes; verified ACC-MULE-005 → 55/medium with 2 reasons

Asset: runRiskEngine

runDetection updates risk_score, risk_category, mule_typology_tags, mule_confidence on every account

Asset: runDetection → Account.update

Rule entity with is_active, typology, threshold_value, severity, risk_score_contribution; RuleVersions page for governance

Asset: Rule, RuleVersions.jsx

runDetection invocable on-demand and via scheduled automation; wired to Detections page for triage

Asset: runDetection, Detections.jsx

ingestFraudSignals scans sessions & devices, creates idempotent RiskEvent records (FRAUD source_module); verified 13 events created

Asset: ingestFraudSignals, RiskEvent

Detects sim_swap from SessionLogin.risk_flags; creates critical RiskEvent + alert

Asset: ingestFraudSignals

Detects screen_share/remote_access risk flags; verified screen_share_detected event created

Asset: ingestFraudSignals, RiskSignalsScreenSharing

Detects impossible_travel (geo_anomaly) + vpn/proxy/tor (vpn_detected); verified 10 vpn + 2 geo events

Asset: ingestFraudSignals, RiskSignalsGeoVPN

Clusters Device fingerprints; shared fingerprints across >1 customer → device_change event

Asset: ingestFraudSignals, RiskSignalsDeviceIP

Every high/critical RiskEvent creates a linked Alert (alert_type=session, SLA 24h); verified 13 alerts created

Asset: ingestFraudSignals → Alert

useFraudCase hook creates fraud Case from any signal page "Create Case" action; navigates to Cases; wired on all 3 signal pages

Asset: useFraudCase, RiskSignalsSimSwap/ScreenSharing/DeviceIP

RiskSignals hub shows 4 signal cards + recent events + "Run Signal Scan" button; scheduled daily via automation

Asset: RiskSignals.jsx, Daily Fraud Signal Scan

runScamGuardAcceptance re-executed batch M5_9_20260720: 9/9 scenarios pass (assess→confirm→take action→intervention→idempotent case→customer contact→reporting decision→ongoing monitoring + explicit no_scam/FP) + NEW step 6b RECOVERY workflow for all escalate scenarios: distinct recovery Case (tagged recovery), recovery_case_id set on PSPMScamACTRecord, final_decision=reporting_decision=recovery_case, recovery follow-up CaseNote (D0/D1/D7 cycle), transaction reversal (status=reversed). RECOVERY + FOLLOW-UP NOW ACCEPTANCE-TESTED. SIMULATED reporting (no live regulator). Journey per scenario: flagged txn (is_test_data=true)→assess (score computed)→confirm (customer contacted + trusted-contact + beneficiary/mule flag)→take action (staff action + preventive_actions[] + decision)→transaction intervention (held/stopped/released)→idempotent fraud Case→customer-contact CaseNote→reporting decision (regulatoryFiling FILING_REQUIRED for escalate)→ongoing monitoring (cleared/ongoing). 9 PSPMScamACTRecord, 8 fraud cases, 9 test txns all tagged, 5 regulatory filing decisions. HONEST LIMITATIONS: decision is scenario-expected (not purely score-driven — bank_impersonation scores 60→recommend hold but scenario expects escalate; calibration gap); SIMULATED reporting decision (no live regulator); recovery is a single linked case not a separate recovery workflow; cooling-off/trusted-contact/manager-approval/police-referral exercised at record-field level not as distinct operational screens.

Asset: runScamGuardAcceptance (batch M5_9_20260720)

8 scam typologies + 1 explicit no_scam/false-positive all executed in batch M5_9_20260720. Decisions: no_scam=1, hold=3, file_str=5. Interventions: released=1, held=3, stopped=5. Preventive-action palette stored per record (proceed/warn/educate, hold/step-up/cooling-off/trusted-contact, hold/stop/manager-approval/fraud-referral/SAR-decision). Explicit no_scam outcome path validated (proceed→released→cleared, no case). Idempotent case creation confirmed.

Asset: runScamGuardAcceptance (batch M5_9_20260720)

dedupRecords converted from hard-delete to soft-delete + lineage. Superseded records set is_deleted=true + canonical_record_id + supersede_reason + delete_reason=duplicate_supersede + deleted_by/at. Oldest kept as canonical. Legal-hold records never superseded. Idempotent (skips already-superseded). Verified: 0 groups in latest run, hard_deletes=0, lineage_preserved=true.

Asset: dedupRecords (lineage-preserving)

Same soft-delete + lineage conversion. Verified run: 2 groups reviewed, 1 deduped, 1 superseded with canonical_record_id + supersede_reason. in-review/escalated alerts preserved (only all-new groups deduped). hard_deletes=0.

Asset: dedupRecords (lineage-preserving)

Same soft-delete + lineage. Customer entity gained is_deleted/deleted_at/deleted_by/canonical_record_id/supersede_reason/legal_hold fields. 9 duplicate-email groups; 54 duplicates had linked accounts/transactions → preserved (skipped_linked); 0 superseded (all had linked data — non-destructive). hard_deletes=0.

Asset: dedupRecords (lineage-preserving), Customer schema

ingestFraudSignals re-run created 0 new events — per-event idempotency confirmed

Asset: ingestFraudSignals

dedupRecords scheduled daily — now soft-deletes with lineage instead of hard-deleting. Audit log action=supersede, resource_type=data_dedup_lineage.

Asset: Daily Data Dedup

dedupRecords verified: superseded Alert record has is_deleted=true, canonical_record_id pointing to kept record, supersede_reason containing dedup key, delete_reason=duplicate_supersede. AuditLog records supersede with full details. Records remain queryable for audit/regulatory history.

Asset: dedupRecords verification (2026-07-20)