UK Registered+NCSC Challenge 4 Applicant+UK-Registered Company No. 16456974
01
The AI governance gap
Control crisis
AI drifts faster than humans can detect. By the time a review board convenes, the model has already produced thousands of decisions no one sanctioned.
Hallucination. Bias drift. Runaway algorithms.
Accountability crisis
Logs are mutable and legally fragile. An audit trail the operator can rewrite is not evidence — it is a record of the intention to appear compliant.
No court-admissible evidence.
Quantum crisis
Classical cryptography will break within 10–15 years. Signatures written today must still hold when the machine that can forge them exists.
Audit trails become worthless.
“Post-hoc audits are autopsies, not physicians.”
02
Introducing QSLA-Agent
One architecture governs the loop end to end: every inference is measured, constrained, signed, and rendered as a regulatory artifact before it leaves the system.
Source
AI Agent
→
Sense
Ethics Gate
→
Act
Guardrail Actuator
→
Notarise
QSLA Ledger
→
Report
RIL
↓
Verifies the Ethics Gate
SCBF Safety Certificate
Kill-switch branches from the Ethics Gate+The ledger feeds the Regulatory Interface Layer
Every mandatory check must pass before an action executes. Strong evidence cannot compensate for missing permission; valid permission cannot compensate for an unsafe action.
Real-time control
θ-FILTER and HALL, in-loop
A six-dimensional ethical state vector is sampled every 32 tokens and corrected by a PID controller that issues real-time corrective actions.
Quantum-safe audit
RSA-4096 and Dilithium-3
Every ledger entry carries a classical and a post-quantum signature, so the record is admissible in court today and unforgeable in 2050.
Formally verified safety
SCBF safety certificate
A stochastic control barrier function, verified by SMT solver over 99.9% of the operating domain, giving a probabilistic guarantee rather than a stability claim.
03
Validated results
79.4%
Hallucination reduction
Against five published baselines across six datasets.
95% CI: 76.3–82.7
99.9%
SCBF verified safety domain
After boundary augmentation of the learned barrier function.
2 counterexamples at extreme boundary
<150ms
Kill-switch latency
Average time to deterministic halt, tested on an H100 cluster.
137 ms measured
“QSLA-corrected outputs are rated significantly higher for factual accuracy (p < 0.001) than baseline outputs.”
Preliminary human evaluation · n = 27 raters · 500 outputs
04
What we claim, what we don't
The same evidence that supports a claim marks its limit. Both lists are published, and both are audited by the reproducibility artifact.
We do claim
✓HALL reduces hallucination by 79.4%
✓The SCBF certificate holds over 99.9% of the verified domain
✓The dual-signature ledger is cryptographically sound
✓The artifact is reproducible
✓Human evaluation supports the accuracy improvement
We do not claim
✕Mathematical guarantees for arbitrary AI systems
✕That SCBF is verified over the full state space
✕That the system is production-ready
✕That legal admissibility is automatic
✕That independent validation has been completed
“Trust, but empirically verify.”
05
Built for high-stakes domains
Where an unexplained AI decision is a regulatory event rather than a support ticket.
Government & Defence
Human-in-command quorum, NCSC AI security guidelines, MOD and NHS deployment patterns.
Financial Services
Algorithmic trading kill-switch obligations, FINRA supervision, model risk evidence.
Healthcare
FDA SaMD change control, EMA audit trails, patient-safety halt on clinical AI.
Court-admissible provenance for AI-assisted disclosure, drafting and case analysis.
Autonomous Vehicles
Flight-recorder-grade event logs for NHTSA and FAA investigation workflows.
06
Sovereign AI R&D Procurement Scheme
CAPTEMS LTD is an applicant to the Sovereign AI R&D Procurement Scheme under Challenge 4: Enabling Safe AI Agent Adoption (NCSC).
We propose QSLA-Agent: a quantum-safe, evidence-based risk management framework for autonomous AI agents.
Ready to make your AI provably safe?
Run a 168-day pilot on one high-risk AI system. Measure hallucination reduction, audit coverage, and regulatory readiness.
What you get
+Quantum-safe audit trail for one AI system
+HALL metric hallucination reduction report
+SCBF safety certificate verification
+Regulatory compliance artifact (EU AI Act / NIST RMF)
Cost
£250,000
Timeline
24 weeks
Product
QSLA-Agent
The only AI governance platform that combines real-time hallucination suppression, formally verified safety certificates, and quantum-safe audit trails in a single architecture.
01
How it works
The agent is not observed from the outside. Governance sits inside the inference loop, between the model and its output, and every transition leaves a signed record.
AI Agent
→
Ethics Gate
→
Guardrail Actuator
→
QSLA Ledger
Verifies the Ethics Gate
SCBF Safety Certificate
Branches from the Ethics Gate
Kill-Switch
Reads the ledger
Regulatory Interface Layer
02
Core capabilities
01
Real-time HALL metric
Heuristic Admissibility and Lineage Logic
Retrieval-grounded hallucination detection at 0.11 ms per token, delivering a 79.4% reduction across six datasets and outperforming RECITE, CRAG, Self-Correct, DoLa and ITI. The metric is a first-class signal in the control loop, not a post-run report.
02
θ-FILTER control loop
A six-dimensional ethical state vector under PID control, issuing real-time corrective actions. Drift is corrected as it appears rather than diagnosed after the fact.
03
SCBF safety certificate
A stochastic control barrier function learned from telemetry and checked by an SMT solver, giving the probabilistic guarantee P(unsafe) ≤ δ. 99.9% of the operating domain is verified after boundary augmentation.
Sub-150 ms deterministic halt, authorised by a dual-key human quorum and enforced in a FIPS 140-2 Level 3+ HSM. The stop path does not depend on the model behaving correctly.
06
Regulatory Interface Layer
Auto-generated JSON-LD compliance artifacts mapped to NCSC guidance, NIST AI RMF, the EU AI Act and ISO/IEC 42001 — produced from the ledger, not re-entered by hand.
03
Pricing
Annual licences, priced per governed system. Every tier ships the open-source audit core.
Tier 01
Audit
£250K/year
Quantum-safe ledger
RSA-4096 signatures
Basic Regulatory Interface Layer
Tier 02
Guard
£500K/year
Everything in Audit
Real-time HALL metric
Guardrail Actuator
Consistency and truthfulness checks
Tier 03
Enterprise
£1M+/year
Everything in Guard
Kill-switch
HSM integration
SCBF safety certificate
Multi-jurisdiction RIL
All plans include the open-source audit core, 24/7 monitoring, and named technical support.
Solutions
Governance for the sectors where AI decisions are legally consequential
Each sector arrives with its own regulator, its own evidentiary bar, and its own definition of an unacceptable failure. QSLA-Agent maps to all three.
01
Government & Defence
National security AI carries the highest consequence and the least tolerance for unexplained behaviour. CAPTEMS supplies human-in-command quorum control, non-repudiable audit, and post-quantum signatures aligned to the FY2026 NDAA mandate.
NCSC AI security guidelines · DoD Directive 3000.09 · MOD and NHS deployment patterns
02
Financial Services
Before an AI pays a supplier, QSLA checks that the assistant is authorised, the invoice and supplier details are supported, the payment stays within approved limits, and no other process has already paid it.
Supervisors increasingly expect a demonstrable stop control on any automated trading or credit system, and evidence that model risk was managed continuously rather than reviewed annually. The ledger supplies the evidence; the kill-switch supplies the control.
Algorithmic trading halt obligations · FINRA supervision · SS1/23 model risk management
03
Healthcare
Clinical AI is regulated as a medical device, and every change to its behaviour is a change to the device. The HALL metric suppresses fabricated clinical claims in-loop, while the ledger gives regulators a tamper-evident record of what the model saw and did.
FDA SaMD change control · EMA audit trails · patient-safety halt authority
04
Critical Infrastructure
Grid, water and transport operators are moving control-adjacent decisions to AI while their monitoring obligations tighten. QSLA-Agent runs inside the operational boundary and produces reportable artifacts without exporting sensitive telemetry.
AI-assisted disclosure and drafting only survive challenge if the provenance of every generated passage can be reconstructed. Dual-signed entries establish authorship, retrieval source and time of creation to an evidentiary standard.
Court-admissible provenance · disclosure defensibility · retention under legal hold
06
Autonomous Vehicles
Investigators need a record that cannot be revised after an incident. The ledger behaves as a flight recorder for the decision layer, capturing the ethical state vector and every guardrail intervention at the moment it occurred.
QSLA would help public agencies control how AI recommendations become official decisions. An AI could assess an application, recommend a benefit, review a licence or evaluate a procurement bid; QSLA checks the required authority, evidence and rules before the connected government system carries out the approved action.
Benefits eligibility and payments · licensing · procurement evaluation, award and payment
08
Robotics
The agent proposes a task; an independent governance plane admits a bounded skill; the robot’s local controller keeps immediate physical safety; an evidence service records decisions and observed consequences. The agent never holds a direct credential for arbitrary actuator commands.
QSLA sits between an AI agent and the systems that change networks, manage customer accounts or grant administrative access. The AI proposes; QSLA checks authority, evidence and operating conditions; an execution gateway permits only the approved operation.
QSLA controls the point where an assistant’s answer becomes an action. Recommending a purchase is different from placing an order; drafting an email is different from sending it. The consequential step needs its own authorisation.
Illustrative decisions from the robotics architecture paper. Values are assumptions chosen to explain the admission process, not measurements from a deployed robot.
Case
Decisive condition
Outcome
Warehouse
Conservative clearance is adequate only under the stated assumptions
Bounded navigation after every required check
Manipulation
Changed gripper or incomplete actuator sufficiency evidence
Hold activation or design release
Hospital logistics
Destination sources conflict
Hold until a corrected destination is bound
Design release
New link changes inertia and lacks fatigue evidence
Simulation permitted; manufacturing release held
Sector descriptions above marked as proposed deployments are not claims of validated live implementations.
Not sure which pattern fits?
A 30-minute briefing maps your highest-risk system to the relevant regulatory obligations.
Solutions / Sector
Government & Defence
Quantum-safe AI governance for national security, defence, and public sector AI. NCSC Challenge 4 applicant. DoD Directive 3000.09 aligned.
01
Use cases
Autonomous systems
Human-in-command dual-key quorum for lethal autonomous systems. Rules of engagement encoded as control constraints, with non-repudiable audit of every authorisation and refusal.
Intelligence analysis
Hallucination suppression for generated intelligence reports, with source provenance attached to each assertion and quantum-safe handling of classification markings.
NHS AI governance
Clinical AI audit trails that satisfy FDA SaMD expectations, with a patient-safety kill-switch held by named clinical staff rather than the vendor.
Critical national infrastructure
NERC CIP-015-1 compliance for grid-stability AI, with real-time audit trails generated inside the operational boundary.
The mathematical centrepiece of QSLA, inside a non-compensatory runtime-assurance architecture that separates an agent’s proposal from permission to act.
01
Non-compensatory admission
Before AI acts, check its permission, supporting evidence and operating conditions. Permit the approved action, then record what happened.
QSLA separates an agent’s proposal from permission to act. Every mandatory admission condition must pass. Strong evidence cannot compensate for missing permission; valid permission cannot compensate for an unsafe action.
Agent proposes
→
Contract & authority
→
HALL evidence
→
SCBF safety
→
θ intervention
→
Single-use capability
→
Execute & record
Seven authority predicates
Execution authority is the conjunction of seven independent checks. Each one carries its own failure response.
Identity
Confirms the requesting agent, delegation chain and runtime environment.
On failure: Deny
Purpose
Confirms the operation remains within the authorised objective.
On failure: Deny or escalate
Data
Confirms the permitted data class, residency and transformations.
On failure: Deny
Knowledge
Confirms that relied-upon sources are permitted.
On failure: Withhold capability
Tool
Confirms the requested method and schema.
On failure: Deny
Action
Classifies the consequence as autonomous, approval-bound or prohibited.
On failure: Declared intervention
Lifecycle
Confirms the signed contract is active, unexpired and unrevoked.
On failure: Hard veto
Component responsibilities
Component
Purpose
Bounded-use contract
Defines the agent’s task, permissions, limits and prohibited activities.
HALL evidence verification Heuristic Admissibility and Lineage Logic
Assesses the evidence supporting material claims used in a decision.
SCBF
Evaluates a proposed state transition against declared safety constraints, under specified modelling assumptions.
θ intervention mechanism
Selects whether to continue, constrain, request approval, pause, roll back where possible, or stop.
Capability security
Restricts execution to the exact authorised action.
Concurrency control
Addresses duplicate execution, conflicting operations and stale state.
Evidence ledger
Preserves tamper-evident records; post-quantum signatures protect them against anticipated quantum attacks.
The claimed novelty is this transaction-level composition and enforcement order, not the invention of the underlying barrier, conformal, cryptographic or distributed-systems primitives.
02
HALL evidence states
HALL (Heuristic Admissibility and Lineage Logic) classifies every material claim an action relies on. Each claim is scored for support, contradiction, provenance, recency and completeness, then placed in one of six states.
Verified
Complete, admissible, uncontradicted and fresh evidence supports the claim.
Pass evidence gate
Qualified
Support meets thresholds only under explicitly scoped conditions.
Issue bounded capability
Unverified
Evidence is incomplete or below the support threshold.
Admissible critical evidence directly negates the claim.
Hard veto
Expired
The evidence freshness window has lapsed.
Refresh mandatory
These are evidential classifications, not statements of truth. For a compound operation, every conjunctively linked claim must reach a passing state.
03
How SCBF works
A barrier function is learned from telemetry, verified by an SMT solver, and then enforced in the running loop. Where the certificate fails, we say so.
Step 01
Define the safe set
C = {θ′ : C ≥ 0.85, HALL ≤ 0.85, T ≥ 0.80}
Step 02
Learn the barrier
A neural network h(θ′) is trained on 10⁵ telemetry samples. Architecture: three-layer MLP, 256 hidden units.
Step 03
Verify the certificate
The dReal SMT solver verifies that h(θ′) satisfies the barrier condition. Precision δ = 10⁻⁴ over the domain [−1,1]⁶.
Step 04
Deploy the shield
Real-time enforcement: if h(θ′) < 0, the guardrail actuator intervenes, or the kill-switch fires.
Verification results
Domain region
Violations (before)
Violations (after)
Safe set interior
0
0
Boundary (0.9–0.95)
3
0
Extreme boundary (>0.95)
12
2
Total verified
99.7%
99.9%
Remaining counterexamples (n = 2) sit at |θ′ᵢ| > 0.98. They are published rather than smoothed away.
04
How the θ-FILTER works
Four stages, repeated continuously while the agent is running. Nothing in the loop waits for a human, and nothing in the loop escapes the ledger.
Step 01
Sense
The Ethics Gate computes the state vector θ′ = [B, R, H, C, T, HALL] every 32 tokens — bias, robustness, harm, consistency, truthfulness, and grounded hallucination risk.
Step 02
Decide
A PID controller computes the error term e = θ_ref − θ′ against the charter reference vector.
u(t) = K_p·e + K_i·Σe + K_d·(e − e_prev)
Step 03
Act
The Guardrail Actuator adjusts sampling temperature, retrieval weighting and beam search in response to u(t). If θ′ falls below θ_crit, the kill-switch fires without waiting for the next cycle.
Step 04
Notarise
Every sensed state, control action and intervention is dual-signed and appended to the QSLA ledger, then exposed to the Regulatory Interface Layer as a structured artifact.
Six ordered interventions
θ is an intervention mechanism, not a confidence score that can overrule failed prerequisites. Hard vetoes are evaluated first: expired authority, prohibited purpose, contradicted mandatory claim, unsafe reachable state, invalid capability binding or unavailable stop path.
01
Continue
The capability is signed and released without modification.
02
Constrain
The capability is narrowed: spending limits reduced, network scopes bounded, duration compressed.
03
Human approval
The proposal pauses for an authenticated human co-signature with proof of examination.
04
Pause
Actuation is held in a non-destructive state during verifier outages or sensor degradation.
05
Rollback
The proposal is rejected and compensating transactions reverse intermediate side-effects.
06
Stop
The capability is denied, the agent session revoked and actuators placed in safe-state isolation.
Hysteresis and a persistence window prevent chattering: entry to Continue requires θ ≥ 0.92, exit occurs below 0.88, and a single borderline reading cannot switch actuation.
Independent stop path
A kill switch is a tested transition to a defined safe state, not merely a user-interface button. Activation may revoke active capabilities, deny new preparations, isolate model network paths, freeze high-risk queues, place actuators in fail-safe mode and preserve volatile evidence.
Recovery is more restrictive than restart. The component that caused the stop cannot declare itself recovered without independent evidence.
05
Dual-signature PQC
Each ledger entry is signed twice: once with RSA-4096, which courts, auditors and existing PKI already accept, and once with CRYSTALS-Dilithium-3, a NIST-selected lattice scheme that survives Shor's algorithm.
The pairing is deliberate. Dropping the classical signature would make today's records harder to admit as evidence; dropping the post-quantum signature would make them forgeable within the retention period of most regulated systems.
Classical signature
RSA-4096
Post-quantum signature
Dilithium-3
Hash chain
SHA3-512
Key custody
FIPS 140-2 L3+
Entry schema
JSON-LD
Capability security and concurrency
The agent holds no general credential. Once every predicate passes, the service issues a narrow, expiring, single-use capability bound to the exact operation.
Single-use binding
The capability is bound to the canonical operation digest, principal, expiry and revocation state.
Two-phase consumption
Shared resources are reserved first; the commit atomically consumes the capability in the local store.
Fencing and idempotency
Fencing identifiers and idempotent commit block duplicate execution, conflicting operations and stale state.
Hash-linked receipts
Proposal, decision, intervention and outcome are recorded in a canonical event chain under a hybrid signature policy.
External execution and receipt recording remain separate steps. If a downstream system still accepts unrestricted commands, the admission rule is not enforceable, so gateway design is part of the architecture.
06
Regulatory Interface Layer
The RIL reads the ledger and emits the artifacts a regulator actually asks for: risk register entries, incident timelines, human oversight records, and conformity evidence, each expressed as JSON-LD with a stable mapping to the framework that requires it. Compliance reporting becomes a query rather than a project.
07
Open-source core
The audit core is published under the MIT licence: ledger schema, HALL implementation and RIL templates. A governance layer that cannot be inspected is a governance claim, not a governance control.
Compliance
Four frameworks, one ledger, no re-keying
The Regulatory Interface Layer maps each ledger entry to the control it evidences. The same governed run satisfies a UK security review, an EU conformity assessment and an ISO audit.
01
NCSC alignment
CAPTEMS LTD is an applicant to NCSC Challenge 4. The platform addresses the AI security guidelines end to end: secure design of the governance boundary, continuous risk assessment from the state vector, human oversight with named authority, and incident response driven by ledger evidence rather than reconstruction.
High-risk systems must maintain a risk management system, keep automatic logs, enable human oversight, and demonstrate accuracy and robustness. Each of those obligations has a corresponding artifact generated from the ledger, with the immutability the logging requirement implies but does not supply.
The framework's four functions map cleanly onto the control loop: the charter governs, the Ethics Gate maps and measures, and the Guardrail Actuator manages. The RIL renders each function's outcomes as evidence rather than attestation.
GovernMapMeasureManage
04
ISO/IEC 42001
An AI management system needs documented objectives, operational controls, monitoring and internal audit. The ledger is the monitoring record and the internal audit trail at once, which removes the usual gap between what the management system says and what the model did.
CAPTEMS LTD is an applicant to the Sovereign AI R&D Procurement Scheme under Challenge 4: Enabling Safe AI Agent Adoption (NCSC). The submitted proposal is QSLA-Agent — a quantum-safe, evidence-based risk management framework for autonomous AI agents, with the safety certificate as its verifiable core.
Challenge 4Safe agent adoptionUK sovereign supplyApplicant
Scope note
QSLA is an engineering architecture, not a legal opinion, conformity assessment or management-system certification. Its controls can generate evidence relevant to external obligations, but compliance depends on system classification, jurisdiction, organisational processes, technical documentation and competent assessment. Human involvement must be substantive rather than ceremonial, and QSLA deployment is not equivalent to ISO/IEC 42001 certification.
Request the control mapping
A clause-by-clause mapping document for any of the four frameworks, prepared for your compliance team.
Research
Research & publications
Peer-reviewed research, technical whitepapers, and open-source artifacts.
01
Publications & preprints
10 Oct 2026 · Architecture and Methods Preprint · v1.3
Quantum-Safe Ledger Architecture for Consequential AI: Cross-Domain Design, Formal Conditions and Reproducible Conformance
Akinde, O. (2026). CAPTEMS Ltd; Theta Prime Institute.
Eight sector applications on one lifecycle, a bounded procurement reference implementation, seven JSON Schemas, a signed ML-DSA-65 protection profile and seventy passing conformance tests.
Quantum-Safe Ledger Architecture for Runtime Governance of Tool-Using Artificial Intelligence
Akinde, O. (2026).
QSLA as an independent reference-monitor layer that binds each proposed action to an authenticated principal, declared purpose, versioned contract, evidence state and safe operating boundary before issuing a single-use capability.
QSLA: An Implementable Noncompensatory Runtime Assurance Architecture for Consequential Agentic AI
Akinde, O. (2026). Theta Prime Institute.
The prototype, its six JSON Schema artefacts and a prospective independent-validation programme covering blinded HALL review, SCBF calibration, adversarial testing and archival release.
QSLA Application to Agentic AI-Mediated Robots and Robotic Design
Akinde, O. (2026). Theta Prime Institute.
Separates the proposing agent, an independent governance plane, the local controller and the evidence service, with worked cases in warehouse navigation, collaborative manipulation, hospital logistics and robotic design release.
The six components, the evidence, what QSLA does not claim, and the four deployment tiers. By Olumisimi Akinde.
Regulatory
Governing High-Risk AI Under the EU AI Act
How continuous control and immutable logging satisfy Articles 9–15 in practice. Sir Olumisimi Akinde, 2026.
03
Benchmarks
Results are reproducible from the published benchmark suite. Figures below are averages over six public datasets against an ungoverned baseline of the same model and prompt set.
Measure
Baseline
Governed
Change
Hallucination rate
18.4%
3.8%
−79.4%
SCBF verified safety domain
99.7%
99.9%
+0.2pp
Time to deterministic halt
—
137 ms
—
Per-token governance overhead
—
0.11 ms
—
Reference implementation conformance
Results from the 2026 architecture papers. They establish bounded control conformance and local durability, not field effectiveness, production safety or post-quantum certification.
Median 42.4 µs · p99 141.3 µs, excluding network and signatures
Preprint v2.1
Open Policy Agent comparison
Agreement on all 729 predicate combinations
Cross-domain v1.3
Signing / verification trials
100 of 100 reject every prescribed message mutation
Cross-domain v1.3
Conformance test suite
70 tests pass, incl. multi-process reservation and crash recovery
Cross-domain v1.3
Laboratory RAG simulation
84.8% relative reduction in simulated unsupported-claim admissions
IEEE TAI v2
Twenty-one of twenty-two infrastructure tests passed; the ML-DSA-65 known-answer test was skipped because a provider and vector were unavailable. Independent field evaluation remains necessary.
04
Open-source artifacts
QSLA-MDS: Multi-Domain Benchmark Suite
Benchmarks, Docker images, and charter files for QSLA evaluation.
Every figure published above can be regenerated from a single repository. Seeds, dataset provenance and the verification scripts are included so that results can be checked by people who do not work for us.
CAPTEMS works with academic groups on control-theoretic safety, post-quantum evidence standards, and benchmark design. We provide research licences, datasets and co-supervision for doctoral work in these areas.
About
About CAPTEMS LTD
A UK-registered company building the sovereign AI governance layer for the AI-native era.
Company No. 16456974 · Registered in England and Wales
01
Our mission
To make AI behaviour provable. Governance that arrives after a decision can only describe what went wrong; governance inside the loop can prevent it and prove that it did. We build that layer in the United Kingdom, publish the audit core openly, and hold ourselves to the evidentiary standard we ask regulators to expect.
02
Leadership
Sir Olumisimi Akinde FCGP, FTPI
Founder & Chief Architect
Sir Olumisimi Akinde is the Founder and Chief Architect of the Theta Prime Institute and the originator of Organization Physics — the discipline underpinning the MAICA Canon. His work reframes organizations as living systems governed by natural law, and codifies the standards by which they can be built to endure.
He is the inventor and architect of the Quantum Safe Ledger Architecture (QSLA), a patent-pending AI technology framework that embeds autonomous AI governance at code level and in real time.
As author of the Canon and architect of the Thermostatic Intelligence paradigm, he leads the Institute's mission to forge a global community of Systemic Architects and to advance viability as the first principle of institutional life.
Dr Demi Saseun MBChB, MBA, FTPI
Co-founder & Managing Director
Dr Isaac Demilade Saseun is a technologist, digital-assets specialist, and entrepreneur with over 20 years' experience in enterprise technology consulting, trading, and equities investing. Originally trained as a medical doctor before moving into information technology, he is the co-founder and managing director of CAPTEMS Limited, an AI-governance focused technology start-up with focus on autonomous code-level AI governance and risk management solutions.
An enterprise solutions architect, polymath, and co-researcher in viability, stewardship, and Organization Physics, he serves as Vice President of the Theta Prime Institute and is the author of the Goshen Protocol. His cross-industry consulting career spans financial services, oil and gas, manufacturing, healthcare, and the public sector across seven countries, including the United States, the United Kingdom, South Africa, and Romania.
Keith Stevens
Director
Keith Stevens is a seasoned professional with 20 years of experience across FTSE 100 and Fortune 500 organisations, spanning investment banking, media, FMCG, and venture capital. His engagements include Mizuho, RBS, Trafigura, CME, Interpublic Group, Bain, AT Kearney, Bridgepoint, Sainsbury's, Pret a Manger, and Itsu.
Bringing deep functional expertise across operations, accounting, and HR, he has worked both as an external consultant and in-house subject-matter expert, navigating complex, fast-moving organisations with precision. Known for high emotional intelligence and a collaborative leadership style, he has built and led teams of varying sizes — fostering trust, driving performance, and delivering results at the most senior levels.
03
The Theta Prime Institute
CAPTEMS LTD is the commercial engine of The Theta Prime Institute, a research organisation dedicated to systems ethics, cognitive control, and resilient AI architecture.
We hire control engineers, cryptographers, and people who have sat on the regulator's side of the table. Roles are UK-based with security clearance sponsorship where the work requires it.
Contact
Request a 168-day pilot
See QSLA-Agent in action on one high-risk AI system. 24 weeks. £250,000. Measurable results.
Cost £250,000+Timeline 24 weeks+One governed system
Received
Thank you — your request is logged
Your request has been sent to the CAPTEMS team. A member of the team will reply within two working days to scope the pilot.
I Built a Governance System That Makes AI Provably Safe, Auditable, and Quantum-Resistant. Here's Why It Matters.
By Olumisimi Akinde, FCGP, FTPI
Founder & Chief Architect, The Theta Prime Institute · Inventor of CAPTEMS, MAICA, IVA and QSLA
At a glance
The Problem
AI operates at machine speed; governance operates at human speed. This gap produces a control crisis, an accountability crisis, and a quantum crisis.
The Solution
QSLA — a real-time, cryptographically verifiable, quantum-safe governance layer that embeds safety into the AI computation loop.
The Evidence
79.4% hallucination reduction across 6 datasets; 99.9% SCBF verified safety domain; 137 ms kill-switch latency.
The Honest Truth
QSLA is a deployable prototype, not a finished product. Independent validation is pending. Limitations are documented.
The Ask
Run a 168-day pilot on one high-risk AI system. If it works, expand. If it doesn't, you've lost nothing.
01
The problem no one wants to talk about
We are deploying AI systems that make life-altering decisions — approving loans, recommending treatments, routing traffic, informing defense — at machine speed.
But we govern them at human speed.
An AI model can make millions of decisions per second. But if something goes wrong — a bias creeps in, a hallucination goes unnoticed, a trading algorithm runs wild — our governance systems take hours, days, or weeks to detect and correct it.
By the time we catch the problem, the harm is already done.
This is the governance gap.
It's not a policy problem. It's an engineering problem. And it produces three converging crises:
1
The Control Crisis
AI drifts ethically faster than humans can detect or correct. In 2012, Knight Capital lost $440 million in 45 minutes because a trading algorithm went rogue and no one could stop it fast enough.
2
The Accountability Crisis
AI logs are mutable, incomplete, and legally fragile. When something goes wrong, we can't prove what happened — or why.
3
The Quantum Crisis
Every audit log, compliance report, and chain of custody signed with classical cryptography today is a depreciating asset. Within 10–15 years, quantum computers will break RSA and ECDSA. Our audit trails will become worthless.
02
The solution: QSLA
I've spent years building a governance system that closes this gap.
It's called the Quantum-Safe Ledger Architecture (QSLA).
And it's not a policy. It's not a dashboard. It's not a report.
It's an engineered, cryptographic, and hardware-enforced guarantee system.
03
How QSLA works: the six components
Figure 1. QSLA system architecture. The inference path is governed by the θ-FILTER, HALL and SCBF controls; all events are written to a dual-signed quantum-safe ledger, while the kill-switch and Regulatory Interface Layer provide deterministic intervention and compliance evidence.
1. The θ-FILTER: Real-Time Ethical Control
QSLA wraps your AI model in a closed-loop PID controller — essentially an ethical thermostat.
Every 32 tokens, it measures a six-dimensional ethical state vector:
θ′ = [B, R, H, C, T, HALL]
Component
Meaning
Ideal
B
Bias / fairness
1.0
R
Resilience
1.0
H
Honesty / calibration
1.0
C
Control compliance
1.0
T
Transparency
1.0
HALL
Hallucination Density
0.0
When θ′ deviates from the target, the system automatically corrects — lowering temperature, fetching more evidence, or truncating unsafe outputs.
2. The HALL Metric: Real-Time Hallucination Detection
HALL detects, per token, whether the AI's output is grounded in retrieved evidence or invented.
Figure 2. Reported HALL benchmark results. Across the five benchmarks listed in the source table, hallucination density fell from a reported average of 25.8% to 5.3%, equivalent to a 79.4% average reduction. Results are self-reported and await independent validation.
Dataset
Baseline
QSLA
Reduction
WikiBio-CounterF
23.4%
4.1%
82.5%
MedHall
31.2%
6.5%
79.2%
CodeHall
18.7%
3.7%
80.2%
RAGTruth
27.3%
5.4%
80.2%
HaluEval
24.8%
4.8%
80.6%
Average
25.8%
5.3%
79.4%
3. The SCBF Safety Certificate: Formal Safety Guarantee
This is the mathematical centerpiece.
A Stochastic Control Barrier Function (SCBF) defines a safe set and proves — with a probabilistic guarantee — that the AI never enters an unsafe state.
P(unsafe) ≤ 0.01
Verified over 99.9% of the defined safety domain using the dReal SMT solver.
This isn't marketing. It's mathematics.
4. The Dual-Signature Quantum-Safe Ledger
Every ethics event, control action, and decision trace is written to an immutable ledger.
Each entry is:
+Hashed with SHA-512
+Dual-signed with RSA-4096 (legal today) + CRYSTALS-Dilithium-3 (quantum-safe tomorrow)
+Chained to the previous block
+Timestamped with UTC
+Tagged with regulatory metadata
The result: a Chain of Moral Custody — a complete, tamper-evident, legally admissible history of the AI's ethical life.
5. The Kill-Switch: Deterministic Safety Backstop
When catastrophic ethical collapse is detected, QSLA triggers a hardware-level kill-switch that halts the system in 137 milliseconds (sub-150 ms specification). Resumption requires dual-key human authorization — one from the system, one from a certified Human-Copilot.
Machines do not self-resume.
6. The Regulatory Interface Layer (RIL)
The RIL automatically translates ledger entries into compliance artifacts (JSON-LD) mapped to:
EU AI Act (Articles 9–15)NIST AI RMF 1.0ISO/IEC 42001NCSC AI Security GuidelinesOECD AI PrinciplesUNESCO AI EthicsGDPR
Report generation time: under 5 minutes — vs. multi-day manual audits.
04
The evidence
I'm not asking you to take my word for it. Here's what the data shows:
QSLA operationalizes what I call thermostatic governance.
A thermostat maintains a room at a desired temperature by continuously sensing, comparing, and acting.
QSLA does the same for AI ethics.
Traditional Governance
Thermostatic Governance
Detect-and-report
Detect-and-regulate
Post-hoc audits
Real-time control
Mutable logs
Immutable ledger
Human-speed oversight
Machine-speed regulation
Classical cryptography
Quantum-safe cryptography
Policy documents
Engineered guarantees
Proclaimed trust
Proven trust
The difference: a thermostat controls heat. QSLA controls ethical viability.
06
What QSLA does not claim
I believe in being honest about limitations. Here's what QSLA does not claim:
✕Mathematical guarantees for arbitrary AI — The SCBF is verified over a specified domain, not the full state space.
✕HALL measures truth — It measures retrieval grounding. If evidence is wrong, HALL is wrong.
✕Real-time bias and resilience — These require labels rarely available at inference; they're computed offline in batch.
✕Legal admissibility is automatic — A dual-signed ledger requires regulator engagement and pre-certification.
✕Independent validation is complete — All results are self-reported. University partnership is pending.
✕Production-ready at scale — QSLA is a deployable prototype, not a proven product at scale.
07
Deployment pathways
QSLA is offered in four tiers:
Figure 3. QSLA deployment pathway. Each tier adds capability and assurance, progressing from a quantum-safe audit trail to air-gapped sovereign governance.
Tier
Target
Core Deliverable
Annual Price
QSLA Audit
SMEs, developers
Quantum-safe audit trail
£250,000
QSLA Guard
Mid-size enterprises
+ HALL + guardrails
£500,000
QSLA Enterprise
Large enterprises, government
+ SCBF + kill-switch + HSM
£1,000,000+
QSLA Sovereign
National governments, defense
Air-gapped, sovereign
£2M–£10M+
Each tier builds on the previous one. Start small. Expand as your governance needs mature.
08
Why this matters
We are at an inflection point.
AI systems are becoming more autonomous, more powerful, and more pervasive. But our governance systems are stuck in the 20th century — post-hoc, manual, and legally fragile.
QSLA changes that.
It makes AI:
+Provably safe — through formal safety certificates
+Provably auditable — through immutable, quantum-safe ledgers
+Provably accountable — through dual-key human quorum
It doesn't ask you to trust. It gives you the tools to verify.
09
What's next
I'm inviting four groups to engage:
For Government
Run a 168-day pilot on one high-risk AI system. Measure hallucination reduction, audit coverage, and regulatory readiness.
For Regulators
Engage with QSLA as a reference implementation for AI auditability. Help shape the standard.
For Enterprises
Start with QSLA Audit. Expand to QSLA Guard. Lock in with QSLA Enterprise.
For Researchers
Validate, replicate, and improve. The reproducibility artifact is available.
“Trust, but mathematically verify — and be honest about what cannot yet be verified.”
In the age of autonomous AI, trust cannot be a policy. It must be engineered.
QSLA is how we make trust a measurable, verifiable, and permanent asset.
Olumisimi Akinde, FCGP, FTPI Founder & Chief Architect, The Theta Prime Institute Inventor of the CAP-TEMS Framework and QSLA
If this resonates, I'd welcome your thoughts, critiques, and collaboration. The governance gap is not a problem any one person or organization can solve alone. Let's build the trust infrastructure for the AI age — together.
Whitepaper · Regulatory
Governing High-Risk AI Under the EU AI Act
How Continuous Control and Immutable Logging Satisfy Articles 9–15 in Practice
Sir Olumisimi Akinde, FCGP, FTPI
Founder and Chief Architect, Theta Prime Institute · 2026
01
Introduction: the verification gap
1.1 The regulatory obligation
Articles 9 through 15 of the EU AI Act establish requirements for high-risk AI systems that are, in principle, clear and comprehensive. Providers must:
+Establish and maintain a continuous, iterative risk management system (Article 9)
+Ensure data governance practices that address bias, representativeness, and quality (Article 10)
+Prepare and maintain technical documentation sufficient to demonstrate compliance (Article 11)
+Design systems with automatic logging capabilities that record events throughout their lifetime (Article 12)
+Ensure operational transparency sufficient for deployers to interpret and use outputs appropriately (Article 13)
+Design systems for effective human oversight, including appropriate human-machine interfaces (Article 14)
+Achieve appropriate levels of accuracy, robustness, and cybersecurity throughout the lifecycle (Article 15)
These requirements share a common thread: they demand not merely that a system be designed correctly, but that its ongoing operation remain demonstrably within declared bounds. Article 9 explicitly requires a "continuous iterative process" that runs "throughout the entire lifecycle" of the system. Article 12 requires automatic logging "over the lifetime of the system". Article 15 requires consistent performance "throughout their lifecycle".
The regulatory language is continuous. The traditional compliance toolkit is episodic.
1.2 The verification gap
High-risk AI systems are typically developed under controlled conditions, tested against curated datasets, and certified through conformity assessments that occur at a single point in time. Once deployed, they operate in dynamic environments where data distributions shift, edge cases emerge, and model behaviour can drift.
The verification gap is the distance between what a provider can claim about a system's behaviour and what a regulator can independently verify about that behaviour in production. A provider may claim continuous risk management; a regulator cannot observe the system's internal state. A provider may claim that logging is sufficient for traceability; a regulator cannot confirm that logs have not been altered. A provider may claim that human oversight is meaningful; a regulator cannot determine whether operators are genuinely engaged or merely rubber-stamping automated recommendations.
Article 9(2)(c) explicitly acknowledges this gap by requiring evaluation of "other risks that may arise, based on the analysis of data collected through the post-market monitoring system". Post-market monitoring is not an afterthought; it is a statutory requirement. Yet without architectural mechanisms to capture, preserve, and expose operational evidence, post-market monitoring becomes a retrospective exercise in documentation rather than a continuous process of verification.
1.3 The architectural response
This paper proposes that the verification gap is best closed not through additional documentation requirements, but through architectural mechanisms that make compliance observable, continuous, and verifiable. Two capabilities are essential:
+Continuous control: A closed-loop governance mechanism that senses the system's ethical and operational state, compares it to declared bounds, and applies proportionate correction in real time. This directly satisfies the "continuous iterative process" requirement of Article 9 and the "consistently throughout their lifecycle" requirement of Article 15.
+Immutable logging: A tamper-evident, cryptographically chained record of every material event, decision, control action, and human intervention. This directly satisfies Article 12's automatic logging requirement and provides the evidentiary foundation for Articles 11, 13, and 14.
The Quantum-Safe Ledger Architecture (QSLA) provides a reference implementation of both capabilities, demonstrated through the θ-FILTER control loop and the dual-signature evidence ledger. This paper draws on QSLA's architecture to illustrate how each Article can be satisfied in practice.
02
Article 9: Risk management system
2.1 The regulatory requirement
Article 9 requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system. The system must be "a continuous iterative process planned and run throughout the entire lifecycle" of the AI system, "requiring regular systematic review and updating". The process must include:
+Identification and analysis of known and reasonably foreseeable risks to health, safety, and fundamental rights
+Estimation and evaluation of risks arising from both intended use and reasonably foreseeable misuse
+Evaluation of risks based on post-market monitoring data
+Adoption of appropriate and targeted risk management measures
Article 9(5) further requires that residual risk associated with each hazard, and overall residual risk, be judged acceptable.
2.2 The compliance challenge
The central challenge of Article 9 is its temporal scope. Risk management is not a one-time assessment; it is an ongoing process that must operate across the entire lifecycle of the system. Traditional risk management frameworks—periodic audits, annual reviews, static risk registers—are structurally incapable of satisfying this requirement because they operate at intervals rather than continuously.
A system that passes a risk assessment at deployment may drift into unacceptable risk states days or weeks later. A model that performs reliably on validation data may degrade when confronted with distributional shift. A risk mitigation measure that was effective at launch may become insufficient as the operational environment evolves.
The verification gap is acute here: a provider can document a risk management process, but a regulator cannot observe whether that process is actually operating. The difference between a risk management system and a risk management document is precisely the difference between continuous control and periodic reporting.
2.3 The continuous control solution
Continuous control addresses Article 9 by embedding risk management into the runtime behaviour of the system itself. The θ-FILTER architecture, as implemented in QSLA, provides a closed-loop control mechanism that:
+Senses the system's ethical and operational state continuously (every 32 tokens in the QSLA reference implementation)
+Compares the observed state to declared bounds established during the Ethical Charter process
+Applies proportionate corrective action when deviation is detected
+Records every measurement, comparison, and intervention in the immutable ledger
This architecture directly operationalises the Article 9 requirement for a "continuous iterative process." The risk management system is not a document; it is a control loop. The process is not periodic; it is continuous. The output is not a report; it is a stream of control actions and recorded evidence.
The θ-FILTER's control law is a PID controller:
u(t) = Kp·e(t) + Ki·Σ e(j) + Kd·[e(t) − e(t−1)]
where e(t) = θref − θ′(t) is the error between the reference ethical state and the observed state. The proportional term responds to current deviation; the integral term corrects persistent error; the derivative term dampens oscillations. Gains are tuned to ensure stability, with the constraint 0 < Kp < 2 derived from Lyapunov analysis.
2.4 Risk identification and evaluation
Article 9(2)(a)–(b) requires identification and analysis of known and reasonably foreseeable risks. In QSLA, this is operationalised through the θ′ vector, which captures six dimensions of ethical and operational risk:
Component
Risk Domain
Measurement
B
Discriminatory outcomes
B = 1 − DPD
R
Brittleness under adversarial inputs
R = 1 − degradation
H
Overconfident errors
Calibration against entropy target
C
Rule violations
Guardrail detector scores
T
Missing provenance
Metadata completeness
HALL
Factual grounding failures
Multi-signal evidence-grounding estimator
Each component is continuously monitored. When any dimension crosses a declared threshold, the θ-FILTER triggers corrective action. The thresholds themselves are established through a structured Ethical Charter process, documented in Block_0 of the ledger, and subject to periodic review—satisfying Article 9's requirement for "regular systematic review and updating."
2.5 Residual risk and acceptability
Article 9(5) requires that residual risk be judged acceptable. QSLA addresses this through the SCBF (Stochastic Control Barrier Function) safety certificate, which provides a formal, probabilistic guarantee that the system remains within a declared safe set:
P(unsafe) ≤ δ
with δ = 0.01 in the reference implementation. The safe set is defined by constraints on control compliance (C ≥ 0.85), hallucination density (HALL ≤ 0.85), and transparency (T ≥ 0.80).
Critically, the SCBF certificate is conditional: it holds only under stated assumptions about model accuracy, bounded noise, and operating domain. These assumptions are documented explicitly, and counterexamples—states where the guarantee fails—are recorded as residual risk. This intellectual honesty is not merely good practice; it is a direct response to Article 9's requirement that residual risk be considered acceptable, not merely asserted to be zero.
2.6 Immutable logging for risk management
Every risk management action—every threshold breach, every corrective intervention, every escalation—is recorded in the immutable ledger. The ledger entry includes:
+The observed θ′ vector
+The computed error e(t)
+The control action u(t)
+The specific guardrail action applied (PASS, CORRECT, TRUNCATE, or KILL)
+The timestamp and the ledger block hash
+Dual signatures (RSA-4096 and ML-DSA-65)
This creates a complete, tamper-evident history of the risk management process. A regulator can verify not only that a risk management system exists, but that it was actually operating at any given moment. Post-market monitoring data is not collected retrospectively; it is generated continuously and preserved immutably.
03
Article 10: Data and data governance
3.1 The regulatory requirement
Article 10 establishes requirements for training, validation, and testing datasets used in high-risk AI systems. The datasets must be "subject to data governance and management practices appropriate for the intended purpose" and must address:
+Assumptions about what the data are supposed to measure
+Assessment of data availability, quantity, and suitability
+Examination for biases that could affect health, safety, or fundamental rights
+Measures to detect, prevent, and mitigate biases
+Identification of data gaps
Article 10(3) requires that datasets be "relevant, sufficiently representative, and to the best extent possible, free of errors and complete".
3.2 The compliance challenge
Article 10 is predominantly a development-time requirement. Unlike Articles 9, 12, and 15, which extend throughout the lifecycle, Article 10 focuses on the data used to develop the system. However, the requirement for bias examination and mitigation has operational implications: a model trained on representative data may still produce biased outcomes when deployed in a different context or as the population evolves.
The verification gap here is the distance between the documented data governance practices and the actual behaviour of the deployed system. A provider can document that training data was examined for bias; a regulator cannot verify that the bias mitigation measures remain effective in production.
3.3 The continuous control and immutable logging solution
QSLA addresses Article 10 through two mechanisms:
+Retrieval-Source Manager (RSM): The RSM version-stamps every evidence chunk with its source, effective date, version number, and transformation history. Every chunk is hashed and logged to the ledger. This provides traceable provenance for the data used in retrieval-augmented generation, directly satisfying Article 10(2)(b)–(c) on data origin and preparation operations.
+Continuous bias monitoring: While Article 10 focuses on training data, the B (Bias) component of the θ′ vector provides continuous monitoring of outcome bias in production. The demographic parity difference (DPD) is computed in batch and compared to declared thresholds. When bias is detected, the θ-FILTER triggers corrective action. This links the development-time data governance requirements of Article 10 to the operational risk management requirements of Article 9.
The immutable ledger preserves the complete data lineage: from source document through chunk creation, transformation, embedding, retrieval, and use in a decision. A regulator can trace any output back to the authoritative source that supported it.
04
Article 11: Technical documentation
4.1 The regulatory requirement
Article 11 requires that technical documentation be drawn up before a high-risk AI system is placed on the market and kept up to date. The documentation must demonstrate that the system complies with the requirements of Section 2 and must contain at least the elements set out in Annex IV.
Annex IV requires a general description of the system, detailed information on its development process, performance metrics, risk management measures, and—critically—a description of the mechanisms included in the system that allow deployers to collect, store, and interpret logs in accordance with Article 12.
4.2 The compliance challenge
Technical documentation is traditionally a static artifact: a PDF or set of documents produced at development time and updated infrequently. The challenge is that Article 11 requires documentation to be "kept up-to-date" and to demonstrate ongoing compliance—not merely compliance at a point in time.
The verification gap is the distance between the documented system and the deployed system. A technical file may describe a system that no longer exists in practice.
4.3 The immutable logging solution
QSLA transforms technical documentation from a static artifact into a living record. The immutable ledger contains:
+The Ethical Charter (Block_0), which documents the system's declared operating domain, thresholds, and weights
+Every configuration change, model update, and threshold calibration
+Every control action and intervention
+The complete chain of custody from genesis to present
This ledger constitutes the technical documentation in the Article 11 sense: it demonstrates compliance, it is kept up to date (by construction), and it provides the information necessary for conformity assessment. The Regulatory Interface Layer (RIL) can generate jurisdiction-specific documentation packages from the ledger on demand, in machine-readable formats suitable for regulatory submission.
The key innovation is that documentation is derived from operation, not separate from operation. The ledger is not a report about the system; it is the system's verifiable memory.
05
Article 12: Record-keeping
5.1 The regulatory requirement
Article 12 is the most directly architectural of the seven articles. It requires that high-risk AI systems "technically allow for the automatic recording of events (logs) over the lifetime of the system". The logging capabilities must enable recording of events relevant for:
+Identifying situations that may result in the system presenting a risk
+Facilitating post-market monitoring
+Monitoring the operation of the system
For remote biometric identification systems, additional requirements apply: recording of usage periods, reference databases, input data that led to matches, and the identities of persons verifying results.
Article 12 imposes an architectural requirement: the system must be designed with logging capability as an intrinsic property. Logging is not a feature to be added; it is a condition of being a high-risk AI system.
5.2 The compliance challenge
The challenge is not merely to generate logs, but to generate logs that are:
+Automatic: generated as an integral output of the decision pipeline, not manually entered
+Tamper-evident: resistant to alteration or deletion
+Traceable: sufficient to reconstruct the system's operation at any point in time
+Lifetime: maintained throughout the system's operational life
Conventional logging systems—application logs, database audit trails, syslog—fail on at least one of these dimensions. They may be automatic but not tamper-evident. They may be tamper-evident but not complete. They may be complete but not architecturally intrinsic.
5.3 The immutable logging solution
QSLA provides an architectural implementation of Article 12 through the dual-signature evidence ledger. Every material event generates a ledger block with the following structure:
Field
Description
block_id
Sequential identifier
prev_hash
SHA-512 hash of previous block
event_type
Classification (E_HALL, E_SAFETY, E_KILL, etc.)
agent_id
System identifier
theta_vector
Observed θ′ state
hall_score
Hallucination density estimate
control_action
PASS, CORRECT, TRUNCATE, or KILL
timestamp
ISO 8601 timestamp
s_rsa
RSA-4096 signature
s_dilithium
ML-DSA-65 signature
merkle_root
Merkle root for efficient verification
The ledger is append-only: entries cannot be modified or deleted. Each block contains the hash of the previous block, creating an unbroken chain back to genesis. Any alteration would break the chain and be immediately detectable.
The ledger is dual-signed: every block carries both a classical (RSA-4096) and a post-quantum (ML-DSA-65) signature. This ensures that the evidence remains verifiable both today, under current legal frameworks, and in the future, beyond the quantum horizon.
The ledger is automatic: blocks are generated as an integral output of the θ-FILTER control loop. Logging is not a separate process; it is the process.
The ledger is lifetime: the append-only structure ensures that the complete history is preserved from genesis to present, satisfying the Article 12 requirement for recording "over the lifetime of the system."
5.4 Traceability and verification
Article 12 requires logging capabilities sufficient to ensure traceability. QSLA provides a seven-stage audit protocol that any qualified party can execute:
1.Event selection: Query the ledger for a specific event or time period
2.Cryptographic integrity: Verify hash and dual signatures
3.Control accuracy: Re-compute HALL and θ′ from logged inputs
4.Chronological integrity: Walk the PrevHash chain to genesis
5.Human oversight: Verify human signatures and response times
6.Regulatory compliance: Map event to applicable regulatory clauses
7.Report generation: Produce a signed, court-ready audit report
This protocol is reproducible: a second auditor can independently repeat the audit and obtain the same result. It is verifiable: the cryptographic evidence is self-authenticating. It is complete: the chain of custody extends from genesis to the present event.
06
Article 13: Transparency and provision of information
6.1 The regulatory requirement
Article 13 requires that high-risk AI systems be "designed and developed in such a way to ensure that their operation is sufficiently transparent to enable users to interpret the system's output and use it appropriately". The system must be accompanied by instructions for use containing "concise, complete, correct and clear information that is relevant, accessible and comprehensible to users".
The instructions must include:
+The identity and contact details of the provider
+The characteristics, capabilities, and limitations of performance
+The level of accuracy, robustness, and cybersecurity
+Known or foreseeable circumstances that may affect performance
+Technical capabilities for interpreting output
+Human oversight measures
+Expected lifetime and maintenance requirements
6.2 The compliance challenge
Transparency is not merely about providing documentation. It is about ensuring that users can interpret the system's output—that the information provided is sufficient for meaningful understanding. The verification gap is the distance between the provision of information and the achievement of understanding.
6.3 The continuous control and immutable logging solution
QSLA addresses Article 13 through:
+Provenance completeness (T metric): The T component of the θ′ vector measures the completeness of provenance metadata accompanying each output. It tracks whether supporting evidence chunks, model version, confidence scores, and feature attributions are present. A low T score triggers corrective action, ensuring that outputs are accompanied by sufficient information for interpretation.
+Explainable authority: The RIL can generate explanation reports showing the evidence chunks, HALL score, control action, and human oversight records for any decision. This provides the "technical capabilities... for interpreting the output" required by Article 13(3)(b)(vii).
+Instructions for use as a living document: Rather than a static PDF, the instructions for use can be generated from the ledger, reflecting the current configuration, thresholds, and performance characteristics of the system. This ensures that the information provided is accurate and up to date.
07
Article 14: Human oversight
7.1 The regulatory requirement
Article 14 requires that high-risk AI systems "be designed and developed in such a way that they can be effectively overseen by natural persons during the period in which the AI system is in use". The objective of human oversight is to prevent or minimise risks to health, safety, and fundamental rights.
Article 14(3) requires that oversight measures be proportionate to the risks, level of autonomy, and context of use. Article 14(4) specifies that human overseers must be able to:
+Understand the system's capabilities and limitations
+Be aware of automation bias
+Correctly interpret outputs
+Decide not to use the system or to override its outputs
+Intervene in or interrupt the system's operation
For remote biometric identification systems, Article 14(5) requires that no action be taken on the basis of an identification unless it has been separately verified and confirmed by at least two natural persons.
7.2 The compliance challenge
Human oversight is often the weakest link in AI governance. The requirements are clear in principle: humans must understand, monitor, and be able to intervene. In practice, human overseers may lack the information, time, or authority to exercise meaningful oversight. Automation bias—the tendency to over-rely on automated recommendations—further erodes the effectiveness of human review.
The verification gap is acute: a provider can document that human oversight measures exist, but a regulator cannot observe whether those measures are actually effective.
7.3 The continuous control and immutable logging solution
QSLA addresses Article 14 through:
+Dual-key human quorum: The kill-switch and resumption protocols require dual-key authorization—one signature from the system (Ethics Gate) and one from a human (Human-Copilot). Machines do not self-resume. This directly implements Article 14(5)'s requirement for human verification of critical decisions.
+Intervention window: The system is designed for human intervention. The kill-switch can halt execution within 137 ms (hardware) or 500 ms–2 s (software). Manual override is always available.
+Automation bias mitigation: The system displays HALL scores, confidence levels, and supporting evidence, prompting human reviewers to engage critically rather than passively accept automated recommendations.
+Human oversight records: Every human intervention—every override, every resumption approval, every exception—is recorded in the ledger with dual signatures. This creates a verifiable record of human oversight that can be examined during audits.
The immutable ledger preserves the complete history of human oversight: who intervened, when, on what basis, and with what authority. This transforms human oversight from a claimed capability into a provable one.
08
Article 15: Accuracy, robustness and cybersecurity
8.1 The regulatory requirement
Article 15 requires that high-risk AI systems "achieve an appropriate level of accuracy, robustness, and cybersecurity, and that they perform consistently in those respects throughout their lifecycle". The article addresses:
+Accuracy levels and metrics, declared in instructions for use
+Resilience to errors, faults, and inconsistencies
+Resistance to attempts to alter outputs through exploitation of vulnerabilities
+Technical redundancy and fail-safe measures
Article 15(4) requires that systems be "as resilient as possible regarding errors, faults or inconsistencies that may occur within the system or the environment in which the system operates".
8.2 The compliance challenge
The requirement for "consistently throughout their lifecycle" is the key challenge. A system that achieves high accuracy at deployment may degrade over time. A system that is robust to adversarial inputs in testing may be vulnerable to novel attacks. A system that is cybersecure at launch may develop vulnerabilities as the threat landscape evolves.
8.3 The continuous control and immutable logging solution
QSLA addresses Article 15 through:
+Continuous accuracy monitoring: The H (Honesty) component of the θ′ vector measures confidence calibration. The R (Resilience) component measures robustness against adversarial inputs. Both are continuously monitored. When R degrades or H falls below threshold, corrective retraining is triggered.
+SCBF safety certificate: The Stochastic Control Barrier Function provides a formal probabilistic guarantee that the system remains within a declared safe set. The barrier condition:
L_f h + L_g h · u + ½ Tr(σᵀ ∇²h σ) ≥ −α(h)
ensures that the system cannot leave the safe set under any allowed control action. The certificate is verified using the dReal SMT solver over a declared operating domain.
+Adversarial robustness: The R component measures performance degradation on adversarial inputs. The reference implementation achieves a false positive rate of 1.1% on adversarial inputs (reduced from 14% baseline).
+Cybersecurity through dual signatures: Every ledger entry is dual-signed with RSA-4096 and ML-DSA-65. Tampering with the ledger would require breaking both signature schemes simultaneously—a computationally infeasible task.
+Lifetime consistency: The immutable ledger records every control action, every model update, and every retraining event. The complete history of the system's performance is preserved, enabling longitudinal validation.
09
Integration: how the Articles work together
Articles 9 through 15 are not independent requirements. They form an integrated framework for governing high-risk AI:
Article
Requirement
QSLA Mechanism
9
Continuous risk management
θ-FILTER, SCBF certificate
10
Data governance
RSM, continuous bias monitoring
11
Technical documentation
Evidence ledger, RIL
12
Record-keeping
Dual-signature immutable ledger
13
Transparency
T metric, explainable authority
14
Human oversight
Dual-key quorum, intervention window
15
Accuracy, robustness, cybersecurity
Continuous monitoring, SCBF, dual signatures
The integration is architectural, not additive. The θ-FILTER that satisfies Article 9 is the same mechanism that generates the logs that satisfy Article 12. The ledger that satisfies Article 12 is the same ledger that provides the technical documentation for Article 11. The dual signatures that satisfy Article 15's cybersecurity requirement are the same signatures that ensure the integrity of the Article 12 logs.
Continuous control and immutable logging are not separate compliance activities; they are two aspects of a single governance architecture.
10
Conclusion: from documentation to verification
The EU AI Act's Articles 9 through 15 establish a demanding set of requirements for high-risk AI systems. The common thread is continuity: risk management must be continuous, logging must cover the lifetime, accuracy must be consistent, human oversight must be effective throughout operation.
Traditional compliance approaches—periodic audits, static documentation, retrospective reporting—are structurally incapable of satisfying these requirements. They operate at intervals; the regulation demands continuity.
Continuous control and immutable logging provide the architectural foundation for genuine, verifiable compliance. Continuous control ensures that the system remains within declared bounds, detecting and correcting deviation as it occurs. Immutable logging ensures that every material event, decision, and intervention is recorded in a tamper-evident, cryptographically verifiable chain of custody.
Together, they close the verification gap. A regulator is no longer limited to examining documents about the system; they can examine the system's own verifiable memory. A provider is no longer limited to claiming compliance; they can prove it.
The path forward is to build systems that cannot lie, cannot run away, and cannot hide.
The technology exists. The architecture is proven. The regulatory obligation is clear.
11
References
Ames, A.D., Coogan, S., Egerstedt, M., Notomista, G., Sreenath, K. and Tabuada, P. (2019) "Control barrier functions: theory and applications", European Control Conference. arXiv:1903.11199
Akinde, O. (2026) "Quantum-Safe Ledger Architecture (QSLA): Real-Time Hallucination Suppression and Safety Certification for Retrieval-Augmented Generative AI." IEEE Transactions on AI.
European Parliament and Council (2024) Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence. Official Journal of the European Union.
Summaries prepared for review. Final wording is subject to legal counsel before publication.
01
Privacy policy
CAPTEMS LTD is the data controller for information submitted through this site. We collect only what a pilot request requires — name, work email, organisation, role, and the problem description you provide — and we process it on the basis of legitimate interest in responding to a business enquiry.
Enquiry records are retained for 24 months. We do not sell personal data or use third-party advertising trackers. You may request access, correction or erasure at any time by writing to hello@captems.com.
02
Terms of service
This website is provided for information. Nothing on it constitutes a warranty of regulatory compliance, legal advice, or an offer capable of acceptance. Platform performance figures are averages from the published benchmark suite and will vary with model, data and deployment. The SCBF certificate is verified over a stated domain, not the full state space, and the system is not represented as production-ready.
Licence terms, service levels and liability are governed by the executed agreement for each deployment. These terms are governed by the laws of England and Wales.
03
Cookie policy
We set one strictly necessary cookie to maintain your session and, with consent, a privacy-first analytics cookie that records page views without personal identifiers or cross-site tracking.
No advertising, profiling or social embed cookies are used. Consent can be withdrawn at any time without loss of functionality.
04
Ethical charter
We will not supply governance technology to a deployment designed to remove meaningful human authority over the use of force, or to conceal a system's behaviour from a lawful regulator.
The audit core stays open so that our claims can be checked by people who do not work for us. Where a customer's charter conflicts with this one, we decline the engagement.
