> ## Documentation Index > Fetch the complete documentation index at: https://docs.cardinalweb3.com/llms.txt > Use this file to discover all available pages before exploring further. # Delivery Horizons > See what exists, what is urgent for the investor demo, and what follows next. Cardinal is extending and connecting its working foundation. The roadmap does not require an unnecessary rebuild of SafeSend, SafeReceive, Escrow, the Protection API, or the Customer Portal. ## Roadmap stages The public roadmap progresses from the working transaction-protection foundation toward a governed trust layer. | Stage | Delivery position | Direction | | - | - | - | | Transaction protection | Current foundation | Protection API, deterministic Risk Engine, SafeSend, SafeReceive, Escrow, multisig, and Customer Portal. | | Intelligence and control | Active engineering | Real intelligence sources, Cardinal Address Graph, live transaction simulation, enterprise policies, provenance, usage, and billing. | | Transaction assurance | Next assurance layer | Financial Flight Recorder, verified payload binding, decision integrity, verified counterparties, future exposure, Protected Settlement, and evidence-led Conditional Escrow. | | Autonomous security | Strategic research and development | Transaction Immune System, AI Agent Security, Cognitive Firewall, intent-drift verification, adversarial financial simulation, and blast-radius analysis. | | Security domains | Long-term research and development | Bounded financial authority, granular capabilities, financial-state and future-exposure guards, emergency controls, and interoperable security context. | | Global trust layer | Long-term vision | Enterprise APIs, white-labelled controls for wallets, exchanges, and custodians, plus shared governed defence signals. | Roadmap items describe direction, not a commitment to availability or timing. Provider access, partner scope, security testing, legal review, and audit outcomes determine delivery. ## Status map | Horizon | Scope | | - | - | | Published controlled pilot | Public product gateway; business customer login; deterministic `ALLOW`, `REVIEW`, and `BLOCK`; evidence source and freshness; matched rules; professional report download; property-payment demonstration; Protection API-backed Admin Dashboard; SafeSend testnet; SafeReceive controlled pilot; Escrow testnet interface. | | Immediate operational hardening | Named admin identities, MFA and roles; external monitoring; customer-portal ingestion; Escrow event ingestion; dedicated support intake; approved billing plans; legal and security publication; production data-provider validation. | | 30-day platform | Intelligence graph and ingestion pipeline; deeper provenance; versioned enterprise policies; live simulation provider; lifecycle event ledger; dynamic settlement routing; continuous re-screening foundation; production organisation isolation and roles; centrally persisted customer and payment-request records; Portal controls and audit; Escrow event indexing and security-context integration; dedicated support intake and tenant-scoped case management; approved pricing and treasury settlement. | | Longer term | Cryptographic Transaction Passport; milestone Escrow settlement; pluggable oracle conditions; exchange, custodian, treasury-vault, and wallet integrations; AI and agent authorization envelopes, budgets, approved counterparties, protected-settlement requirements, and emergency controls. | ## Controlled-demo acceptance path The published controlled demonstration shows three deterministic scenarios: 1. Clean incoming funds produce `ALLOW`. 2. Unclear or degraded provenance produces `REVIEW` with an explainable matched rule. 3. High-confidence illicit exposure produces `BLOCK` with source and freshness. Identify whether evidence or simulation is a fixture, heuristic, live source, or degraded result on every relevant screen. Do not claim universal tracing, audited mainnet settlement, or complete production compliance coverage. ## Delivery gates * Approve provider licensing, credentials, retention, and attribution before enabling external data. * Review intelligence before policy, and policy before SafeReceive integration. * Preserve API compatibility or version the contract deliberately. * Link implementation pull requests to the canonical roadmap issue. * Require qualified ownership, tests, testnet verification, and independent security review before material Escrow upgrades or deployment. * Confirm production authentication, tenant isolation, retention, pricing, billing, and treasury controls before onboarding real business customers. * Verify the published support mailbox and connect an approved ticket intake before promising case tracking or response targets. * Validate every named institution or exposure claim against an authorised source and preserve its reference and freshness. See the confirmed status of each Cardinal capability. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.