What RM6263 actually asks the vendor to prove, and the substrate that proves it

Crown Commercial Service published RM6263 as the AI framework for UK public buyers. It sits beside G-Cloud and the Digital Outcomes framework, and from 2025 onwards it is the default route by which a NHS trust, a police force, a council, a defence prime, or a central-government department procures artificial intelligence at scale. The framework cites the AI Playbook for Government, the AI Strategy, and the National Cyber Security Centre's AI security expectations.

The clauses in RM6263 are written as procurement-language translations of those policy documents. The structural problem the framework leaves to the buyer is whether the vendor can answer each clause with engineering evidence or whether the vendor will answer with a policy attestation and a self-declared statement of compliance.

This article walks the clause families, names what the buyer has to insist on, and identifies the Mickai Sovereign Intelligence Operating System primitive that supplies the engineering evidence each clause expects.

Clause family A: data sovereignty and residency

RM6263 asks the vendor to evidence where the data lives, who controls the encryption keys, and what the contractual basis is for any data leaving the buyer's perimeter. The AI Playbook for Government adds that the buyer is expected to retain control over training, fine-tuning, and inference data.

The structural test is whether the vendor can supply the encryption keys' custody arrangement in writing, with a hardware attestation that the private halves are held inside the buyer's own equipment. The vendor who answers with cloud-tenant isolation has not satisfied the test. The vendor who answers with TPM-2.0-bound keys held on the buyer's deployment has.

The Mickai SIOS holds every audit, retrieval, and policy key on TPM 2.0 hardware on the operator's deployment. The custody arrangement is documented under the Open Audit Record filing and the hardware-attested identity primitive, both at the UK IPO under the Mickai portfolio.

Clause family B: auditability and explainability

RM6263 asks for an audit trail sufficient to reproduce decisions, identify training data, and surface the basis for any individual output. The Information Commissioner's AI and data protection guidance expects the same record on the controller side.

The structural test is whether the audit record is signed at the moment of generation, against a key the buyer controls, in a format the buyer or the regulator can verify without trusting the vendor.

Mickai's Audit Ledger writes every action under FIPS 204 ML-DSA-65 with the buyer's hardware-bound key, retains the retrieval set the action was conditioned on, retains the model version and the policy version at the moment, and exposes a browser-resident WebAssembly verifier. The verification step does not require the vendor to be online, alive, or trusted.

Clause family C: model assurance and continual evaluation

The framework asks the vendor to evidence pre-deployment evaluation, the assurance evidence from any model providers, and the basis on which the deployed model is monitored in operation. AISI evaluation expectations sit underneath this clause family.

The structural test is whether the vendor can present evaluation results as cryptographically signed evidence the buyer or AISI can re-run against the same model snapshot, against the same evaluation corpus, on the buyer's deployment.

Mickai treats every evaluation as a signed action. The model snapshot, the evaluation corpus, the prompts, the outputs, the scoring, and the policy applied are written to the Audit Ledger under the buyer's key. AISI or the buyer's own evaluation team can re-run the evaluation against the signed snapshot and verify the result independently of the vendor.

Clause family D: security, integrity, and supply chain

RM6263 incorporates the NCSC AI security expectations: known-provenance components, signed dependencies, runtime integrity, and an answer for the AI-agent threat surface. The Five Eyes joint statement on autonomous AI agent security sits adjacent.

The structural test is whether every action the deployed AI can take is mediated by a perimeter the AI does not control, classified by destructiveness, snapshot-protected before commit, and signed for post-event verification.

Mickai's Sentinel primitive is the runtime perimeter on every agent process. Sentinel runs in a separate trust domain, mediates at the syscall layer, classifies destructive actions, snapshots affected resources, and signs the action record. The primitive is on the public register under the Mickai filings.

Clause family E: vendor lock-in and continuity

The framework asks the vendor to evidence how the buyer exits if the vendor fails, is acquired by a foreign owner, or changes its terms. The AI Playbook adds the expectation that critical AI workloads remain functional under degraded supplier conditions.

The structural test is whether the deployed system continues to perform its declared function when the buyer disconnects every external network link to the vendor.

Mickai is designed to run with the cable pulled. Inference, retrieval, audit-ledger writes, and long-term memory all operate on the operator's hardware, against the operator's keys. The seventy-two-hour disconnection test is a primitive of the substrate, not a continuity-of-service annex.

Clause family F: governance, accountability, and right to audit

The framework expects an executive accountable for the AI, a published governance contract, and a right of audit the buyer can exercise without notice. The EU AI Act, applicable to UK suppliers selling into EU markets, adds the regulator-side audit-on-demand expectation.

The structural test is whether the governance contract is enforced at runtime as code, not as a documented policy that the operator hopes the vendor will follow.

Mickai's Policy primitive compiles the governance contract into runtime gates that mediate every action. The contract is published. The gates fire on every action. The audit record captures the gate state at the moment.

What the buyer should add to the next RM6263 call-off

The structural acceptance test is straightforward. The buyer holds the audit keys. The audit records are signed at the moment of decision under FIPS 204 ML-DSA-65. The verification is performed against the buyer's published key. The runtime perimeter is on every agent. The disconnection test is part of the acceptance criteria. The vendor identifies the patent application reference covering each structural property.

A vendor unable to identify the patent provenance for one or more of the structural properties is not, for the purpose of an RM6263 call-off, satisfying the property by construction. The Mickai SIOS is the substrate that supplies the engineering evidence each clause expects, with the supporting filings on the public register at the UK IPO.

The framework is correct. The substrate to satisfy it exists. The buyer can write the call-off accordingly.