MICKAI™ArticlesWhat procurement asks the vendor …
ArticlesFAQPatentsBrainsPress← Home
Article · 3 May 2026

What procurement asks the vendor to prove. Eleven evidence requirements that turn the sovereign-AI checklist into an audit.

The procurement clauses are necessary but not sufficient. A clause without a verifiable evidence requirement collapses into a vendor warranty, which is a marketing commitment with legal language attached. This is the evidence each clause should require: the artefact, the verification procedure, the cadence, and the consequence for absence. Built to live alongside the procurement checklist as the audit annex.

Author
Micky Irons
Published
3 May 2026
UK ProcurementSovereign AIMickaiAI GovernanceAudit

The previous article (mickai.co.uk/articles/the-uk-procurement-checklist-for-sovereign-ai-2026) provided the seven properties and eleven contract clauses for sovereign-AI procurement. This article is the audit annex: for each clause, the verifiable evidence the buyer should require, the procedure to verify it, the cadence at which verification recurs, and the consequence when evidence is absent or fails verification. The clauses without the annex collapse into vendor warranties; the annex is what turns warranties into auditable commitments.

Evidence for Clause 1: Locality and right of refusal

  • Artefact: a sealed, signed inventory of every physical machine the deployed system runs on, including serial numbers, MAC addresses, building location, rack position, and the chain of custody from manufacturer to deployed configuration.
  • Procedure: the Buyer's facilities team performs an annual physical audit. The audit reconciles the inventory against the physical state. Discrepancies are reported within 30 days.
  • Cadence: annual, with right of unannounced spot inspection at any point.
  • Disconnection test: the Buyer disconnects all external network links and verifies the system continues to perform its declared functions for the contracted minimum window. Performed at contract commencement and annually thereafter.
  • Consequence for absence: contract default. Termination right vests immediately.

Evidence for Clause 2: Operator-side audit ownership

  • Artefact: the public keys for every audit-ledger signing operation, with attestation evidence that the corresponding private keys reside in Buyer-controlled hardware.
  • Procedure: the Buyer verifies, on a random sampling basis, that audit records carry valid signatures under the registered public keys, that the signature timestamps are consistent with the audit-record timestamps, and that the keys have not been used outside the attested hardware.
  • Cadence: continuous (the verification is automated and runs against every audit record); spot reconciliation by Buyer security team monthly.
  • Consequence for absence: the audit record is not legally relied upon for the period in question; the Vendor must reconstruct the audit chain at its own cost; the Buyer's liability for actions during that period is capped at the level prior to the audit gap.

Evidence for Clause 3: Hardware-attested actor identity

  • Artefact: TPM 2.0 attestation certificates (or equivalent) for every actor identity issued by the deployed system, with the chain of custody from the hardware manufacturer's attestation root.
  • Procedure: the Buyer's security team verifies, on a random sampling basis, that the attestation chain is valid, that no identity has been issued whose private key has been exported, and that revoked identities have been removed from the system's trust store within the SLA window.
  • Cadence: every identity issuance generates an attestation record verified at issuance; full chain re-verification quarterly.
  • Consequence for absence: the actor identity is treated as untrusted; actions performed under the identity are flagged in the audit ledger and not legally relied upon; the Vendor must re-issue a hardware-attested replacement at its own cost.

Evidence for Clause 4: Cryptographic multi-tenancy

  • Artefact: the per-tenant encryption-key inventory with attestation that no key has been exported and no shared decryption surface exists in the kernel or vendor-side tooling.
  • Procedure: the Buyer commissions an independent third-party cryptographic review at contract commencement and at any major version upgrade. The review reports on the kernel-level access surface and the vendor-side support tool surface.
  • Cadence: at contract commencement, at major version upgrades, and at the Buyer's discretion.
  • Consequence for absence: tenancy isolation is treated as not satisfying the clause; data classified under any tenancy is treated as if exposed to all other tenancies; remediation is at the Vendor's cost.

Evidence for Clause 5: Post-quantum signed audit records

  • Artefact: the public keys for ML-DSA-65 (or successor) signing operations with FIPS 204 conformance evidence.
  • Procedure: the Buyer's automated verifier checks every audit record against the registered public keys; sampling reconciliation by Buyer security team monthly.
  • Cadence: continuous (per record), with quarterly conformance-test runs against the FIPS 204 reference vectors.
  • Consequence for absence: audit records produced under non-conforming signing schemes are not legally relied upon; the Vendor must re-sign the affected records under a conforming scheme at its own cost (note: re-signing is forensically inferior to original signing; this consequence is intentionally severe to disincentivise non-conforming operation).

Evidence for Clause 6: Inverse-action ontology and retroactive rollback

  • Artefact: the action ontology specification, with the inverse declared per action class and the retention policy for the inverse-action records.
  • Procedure: the Buyer issues a test rollback at contract commencement and at quarterly intervals against a non-production resource; the rollback is performed within the SLA window and verified for correctness by the Buyer's operations team.
  • Cadence: quarterly, plus on-demand rollback testing at the Buyer's discretion.
  • Consequence for absence: actions whose inverse is not declared or not stored are flagged as non-rollbackable in the audit ledger; the Buyer reserves the right to refuse to permit such actions in production.

Evidence for Clause 7: Runtime perimeter on every AI agent

  • Artefact: the perimeter component's policy specification, classifier corpus, snapshot retention policy, and trust-domain isolation evidence.
  • Procedure: the Buyer commissions a red-team engagement to test the perimeter against an AI agent attempting to bypass it; the engagement is performed at contract commencement and at major upgrades.
  • Cadence: at commencement, at major upgrades, plus continuous monitoring of perimeter audit records.
  • Consequence for absence: AI agents cannot be permitted in the production environment until the perimeter is in evidence; remediation is at the Vendor's cost.

Evidence for Clause 8: Pre-commit dry-run simulation

  • Artefact: the simulator specification, the snapshot mechanism documentation, the diff format, and the approval-policy configuration.
  • Procedure: the Buyer issues test irreversible actions and verifies that the simulator surfaces the diff before commit; the Buyer verifies that the approval policy honours the configured rules including refusal on missing approval.
  • Cadence: at commencement, at major upgrades, and quarterly.
  • Consequence for absence: irreversible actions are refused in production until the simulator is in evidence.

Evidence for Clause 9: Federation

  • Artefact: the federation protocol specification, the signed federation-record format, and the per-peer policy configuration.
  • Procedure: the Buyer audits the federation log for cross-boundary actions; verifies that each action carries valid hardware-attested identity from the originating peer and is consistent with the Buyer's per-peer policy.
  • Cadence: continuous monitoring; quarterly reconciliation.
  • Consequence for absence: cross-boundary work is suspended until the federation evidence is restored; the Vendor bears the operational cost of the suspension.

Evidence for Clause 10: Third-party hosted dependencies

  • Artefact: the dependency register, the data-flow diagram per dependency, the contractual basis per dependency, the refusal procedure per dependency, and the impact analysis per dependency.
  • Procedure: the Buyer's security team reviews the register at contract commencement and at any change to the dependency set; the Buyer reserves the right to refuse any new dependency.
  • Cadence: on every change to the dependency set, plus annual full review.
  • Consequence for absence: undisclosed dependencies discovered post hoc are treated as material breach.

Evidence for Clause 11: Patent provenance

  • Artefact: the patent register identifying every patent or patent application by jurisdiction and application number, with the mapping from each clause to the supporting patent claim or claim block.
  • Procedure: the Buyer's legal counsel verifies the existence and current status of each patent reference at contract commencement; the Buyer reserves the right to verify at any subsequent point.
  • Cadence: at commencement; on any vendor-initiated change to the patent portfolio relevant to the contract.
  • Consequence for absence: the structural property is treated as not satisfied by construction; the clause defaults to a vendor warranty rather than a structural commitment.

How to use the annex

Paste the annex into the same procurement document as the checklist. Adjust the SLAs and cadences to the specific deployment. Treat the consequence-for-absence column as the contractual remedy that vests automatically; the Buyer should not be required to negotiate consequence at the moment of incident. Vendor proposals should be evaluated on the completeness and credibility of the evidence they offer, not on the elegance of the proposed architecture diagram.

Where this sits

Mickai is the sovereign AI operating system. Twenty-one filed UK patent applications. Six hundred and seventy-five cryptographically signed claims. Sole inventor Micky Irons. Application reference UK00004373277. The annex is contributed to the public discourse for use by any procurement team writing sovereign-AI specs in a regulated UK environment. Mickai is held privately by its founder; the engagement model is direct.

Sovereign means the evidence is verifiable, the cadence is contractual, and the consequence for absence vests at the moment of absence, not after months of negotiation.

Mickai manifesto

Sources

  • Companion article: mickai.co.uk/articles/the-uk-procurement-checklist-for-sovereign-ai-2026 (the checklist this annex extends).
  • Mickai patent portfolio: mickai.co.uk/patents (21 filed UK patent applications, 675 signed claims, application UK00004373277).
  • FIPS 204 (ML-DSA): NIST post-quantum digital signature standard.
  • Previous Mickai articles: mickai.co.uk/articles/the-2026-sovereign-ai-manifesto, mickai.co.uk/articles/authority-at-execution-is-the-control-point.
Originally published at https://mickai.co.uk/articles/what-procurement-asks-the-vendor-to-prove. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles
3 May 2026
The UK procurement checklist for sovereign AI in 2026. Seven properties, eleven contract clauses, one filing reference.
Procurement teams writing sovereign-AI specs in 2026 are working without a usable structural checklist. This is one. Seven properties from the Mickai manifesto operationalised into eleven contract clauses, with the supporting evidence, the audit-trail requirement, and the patent reference any buyer can cite. Designed to be pasted into an actual UK government, NHS, or defence procurement document.
3 May 2026
Authority at execution is the control point. (A reply to Graham Brimage and the AI-governance gap.)
Graham Brimage (FlowSignal) has been arguing that AI governance is a control-point problem, not a layers problem. Authority has to be resolved at execution: independently, deterministically, in real time. Mickai's filed UK patent stack is the structural answer to that thesis. Sentinel intercepts at the syscall layer, hardware-bound identity proves who is acting, ML-DSA-65 signs the proof, copy-on-write simulation surfaces the diff before commit, and federation prevents drift across machine boundaries. This article walks the architecture against Graham's framing.
3 May 2026
Federated fleet coordination. Why sovereign AI scales horizontally across departments without surrendering tenancy.
A single sovereign AI is a workstation. A fleet of cooperating sovereign AIs is the substrate of a Whitehall department, an NHS trust, a defence prime, or a county council. Mickai composes federated fleet coordination on top of the per-machine substrate so a hundred machines can share signed memory, replicate audit ledgers, and arbitrate decisions without any of them ceding tenancy or key custody to a central party. Filed under Patent 17.
3 May 2026
Pre-commit dry-run simulation. Why every action an AI coding agent takes should be simulated before it is committed.
AI coding agents already broke things in 2026. The fixes the industry shipped (better disclaimers, post-hoc rollback) are reactive. Pre-commit dry-run simulation is preventive: the agent's planned action runs against a sandboxed copy of the workspace, the simulator emits the diff, and only after a human or policy approval does the action commit to the real workspace. Mickai's primitive (Patent 13) composes this over every AI coding agent on the host. Sentinel does the runtime gating; Patent 13 does the simulation.