Fourteen modules. Three rings. One registry.

Use GATE to frame who or which party is under review, what was actually recorded and which condition remains open. It does not by itself establish a complete KYC/KYB program, UBO workflow or generally available onboarding service.

Current surface: hosted KYC and party reads; review is feature-flagged; UBO capture is absent in the reviewed state.

• Observed hosted KYC and party UI/read surfaces
• Review path present behind a feature flag, not assumed for every tenant
• UBO capture is absent in the reviewed state and remains a validation requirement
• Designed to pass recorded identity context into screening, policy and case workflows
• Step-up, re-verification and document-evidence behavior require journey-level configuration

PULSE is intended to connect available risk signals to a decision that can be challenged. In the reviewed state, the honest proposition is an exploratory UI with partial rationale—not complete real-time scoring, universal explanation or proven fraud outcomes.

Current surface: Decision Explorer with partial rationale; the ML indicator is a stub, not an active-model claim.

• Observed Decision Explorer and partial rationale UI/read surfaces
• Rules-first decision pattern; any model use is optional and separately validated
• The current ML indicator is a stub and must not be presented as an active model
• Designed actions include approve, step-up, review and hold when configured
• Missing input, threshold or version context stays explicit instead of being inferred

SWITCH makes the proposed route, held traffic and available path context inspectable. A scoped exercise can test the control pattern, but live PSP connectivity, routing performance, resilience and service levels must be proven separately.

Current surface: partial routing-configuration and payment path-trail reads; no live provider or automatic failover is inferred.

• Observed partial routing-configuration UI/read surfaces
• Observed payment path-trail reads for available fixture data
• Designed routing factors include provider state, eligibility, geography, cost and risk context
• Payout, retry and fallback behavior depends on connected providers and validated policy
• No production traffic, provider redundancy or automatic failover is established by the UI

LEDGER can provide a strong finance anchor when the source, posting state and reconciliation context are available. Tax output remains an input-sensitive calculation: jurisdiction, rate source, basis date and intended report must be validated rather than assumed.

Current surface: books are the strongest observed area; tax rates are static and must be shown with their rate-basis date.

• Observed books and finance-oriented UI/read surfaces
• Static tax rates in the reviewed state; always expose the applicable rate-basis date
• Designed to retain tax inputs, basis and output as a dated decision snapshot
• Reconciliation, wallet and export behavior remains workflow- and integration-dependent
• No claim of automatic filing, universal tax correctness or immutable books

SENTINEL is intended to answer which policy and disposition informed an action. The reviewed surface can demonstrate that control pattern, but not current sanctions-list completeness, universal maker-checker, automated enforcement or regulatory compliance.

Current surface: screening and policy reads use a DEMO screening list; list coverage and live feeds are not established.

• Observed screening and policy UI/read surfaces
• Current screening source is a DEMO list and must be labeled as such
• Designed policy context includes geography, product, age and payment-method conditions
• Versioning, approval and rollback depend on the configured governance workflow
• Runtime rule delivery and external screening feeds require integration and validation

PRISM can help a pilot ask whether the same recorded facts produce a useful operating and evidence view. Reproducibility depends on complete source data, definitions, versions and export logic; the current UI does not prove scheduled production reporting.

Current surface: dashboards and generate-now scorecards; scheduled reporting, contractual service-level monitoring and authority-accepted output are not established.

• Observed dashboard UI/read surfaces for available operational data
• Scorecards are generated on demand in the reviewed state, not scheduled automatically
• Designed comparisons require an agreed baseline, definitions and reporting period
• Questionnaires and extracts remain purpose-, role- and source-data-dependent
• No public contractual service-level monitoring, authority-accepted report or customer KPI outcome is claimed