CDP Gatekeeper 6.0
Enterprise Compliance Manifesto
A deterministic, on-premises enforcement layer between the point where an administrative case is created and the infrastructure to which a proposed external action is sent — checking every proposed action, human- or AI-agent-initiated, against the active, approved legal baseline.
CDP Gatekeeper 6.0 is a deterministic, on-premises enforcement layer between the point where an administrative case is created and the infrastructure to which a proposed external action is sent.
Every proposed action — human- or AI-agent-initiated — is checked before it crosses the organisational boundary against the active, approved legal baseline. Execution receives a deterministic GREEN / ORANGE / RED outcome, with an immutable audit trail linking the decision to the exact law, article, rule version, relevant inputs and deterministic reasoning.
A pilot runs for 60–90 days in a live, isolated workflow. Entry fee: US$10,000 or local equivalent, fully creditable against the final licence if the engagement continues. Before launch: one scope owner/contact, a limited number of anonymised real-world cases, and an agreed pilot success definition.
How CDP Gatekeeper 6.0 sits in the IT landscape, and how a proposed action moves through the engine.
The system does not replace ERP, core-banking or transport-management systems. It operates as an enforcement gateway between case preparation and external execution.
Inbound data → 314 pre-mapped Vault fields → CDP Gatekeeper 6.0 (RAM-only) → GREEN / ORANGE / RED → automated M2M dispatch.
Outbound integrations to carriers and port infrastructure are live and tested. Deeper inbound ERP/banking integrations beyond folder-drop or WhatsApp/Twilio intake are customer-specific scope and additional work. CDP does not access the customer ERP or internal Vault.
Checks corrupted data, format deviations, active manipulation and code-injection indicators.
Checks the semantic transaction layer for logical conflicts and structural contamination.
Links the verified dataset to the active legal baseline and assigns GREEN / ORANGE / RED.
If Gate 1 fails, ingestion stops immediately and the data never reaches the legal evaluation layer.
Rule changes are always human-reviewed and four-eyes approved — the engine never guesses at the law.
Daily transactions run autonomously against the active legal baseline. Human four-eyes approval is mandatory when the baseline hash itself changes.
The engine never rewrites its own parsing logic automatically. A detected legislative change places the affected processing in a controlled queue until an authorised compliance specialist has approved the change.
Official statutory texts are fetched read-only for drift detection. Fetched text can update only a human-reviewed, four-eyes-approved rule baseline.
The engine performs read-only pulls of statutory sources to detect drift against configured legal baselines. The current coverage spans nine regulations across five jurisdictions: EU coverage including CBAM, EUDR, REACH, ADR, EC 561/2006 and two low-value-shipment/PID regulations, plus the Netherlands and Indonesia. Five additional customer-configurable jurisdiction slots are available.
Unlike generic AI tools that allow a language model to infer, paraphrase or fill gaps in regulatory text, CDP Gatekeeper 6.0 does not enforce a model’s guess at what the law might mean. Fetched legal text updates only a human-reviewed, four-eyes-approved rule baseline; the engine enforces that approved baseline.
Roadmap principle: as authenticated, structured machine-to-machine regulatory interfaces mature across the industry, the human-in-the-loop step may evolve. The platform is designed so that no rule change is enforced without an unambiguous, verifiable source. The active mode for each rule will always be explicit: human-reviewed today, and only machine-verified later where the source itself is trustworthy and auditable.
Every decision links the exact law, article, rule version, relevant inputs and deterministic reasoning. A read-only audit view provides independent, role-bound access for auditors, compliance officers and CISO functions.
The Board & Regulator Reporting Suite provides aggregated statistics, a legislative time capsule and one-click PDF export from the same verified evidence layer. The time capsule preserves which rule version was active at the moment of a decision.
No vendor cloud access, no phone-home/central telemetry and no remote recovery master key. External BYOK integration keys can be individually revoked by the customer through a wipe action; this does not affect admin, compliance or auditor credentials.
External lookups such as statutory sources are one-way and read-only. Internal business data does not leave the on-premises perimeter.
One core engine, with sector branches that use separate operational dashboards and modules.
What the engine checks proposed actions against, by regulatory area.
This describes what the engine checks proposed actions against. It is not a claim of external certification or a formal compliance seal. The engine enforces only a human-approved legal baseline.
Five free customer-configurable jurisdiction slots are available without changing the core architecture. Five additional UBO lookup slots are available for external ownership checks beyond the built-in coverage.
What the platform fixes, and where its boundaries are drawn on purpose.
Outbound dispatch is a live, tested integration today. Deep inbound ERP/banking plug-ins beyond folder-drop/WhatsApp/Twilio intake are scoped per customer and require additional work.
Where the platform pays for itself — as shared infrastructure and per sector.
The questions CISOs and auditors ask first, answered directly.
One core engine carries cryptography, execution, ledger and security controls. Sector branches use separate operational dashboards and modules.
No. The platform is 100% on-premises. External statutory lookups are read-only and do not transmit internal business data.
The customer owns and builds that integration. CDP provides the Vault specification and does not access internal systems.
No. The master-admin credential is generated once during first initialisation.
Registration, identity and delegated scope are checked before evaluation. A suspect agent can be isolated independently, and the system-wide emergency stop can block state-changing requests.
Yes. Law, article, rule version, inputs, fired rule/gate, deterministic reasoning and outcome are made available together.
Yes. Role-bound credentials are separately validated and the audit view remains read-only.
Yes. Only the affected external BYOK key is wiped; core credentials and the audit ledger remain intact.
AES-256 and SHA-256 provide a substantial security margin against known quantum-acceleration concerns, but this is not the same as a dedicated NIST post-quantum cryptography implementation.
A pilot runs for 60–90 days in a live, isolated workflow. Entry fee: US$10,000 or local equivalent, fully creditable against the final licence if the engagement continues.
Required before launch: one scope owner/contact, a limited number of anonymised cases, and an agreed success definition. The pilot is designed to validate the enforcement workflow, evidence trail, sector branch behaviour and integration boundaries before any long-term structural commitment.
The platform is designed to make the active legal baseline, enforcement status and audit evidence explicit at the moment an action is evaluated.