Skip to main content

AI governance policy: what it can commit to at the moment of decision

A policy is a promise written before anything runs. A few of its clauses are about what will be true of a particular decision — and those are the ones somebody will eventually ask you to demonstrate.

An AI governance policy is the document that states how an organisation will use AI: which uses are permitted and which are not, who decides, what has to be reviewed before a system goes live, what has to be recorded once it is running, who is accountable when something goes wrong, and how a person affected by an outcome can challenge it. It is usually the artefact the rest of the programme is built to serve.

Most drafting effort goes into scope and prohibition — the clauses that say what may happen. Those are checked the way documents are checked: by reading them, by inspection, and by auditing the programme that carries them out.

A smaller set of clauses is different in kind. They say what will be true of a particular decision: that it was made under an approved rule, that the rule can be identified afterwards, that the account of it was not written up after the outcome was known. Nobody checks those by reading the document. They are checked by producing something about one decision, and this page is about drafting them so that producing it is possible — and about being straight, in the document, about the clauses where it is not.

The clauses that get tested

A policy is written once and met one case at a time. The clauses that survive that meeting well have something in common: they describe an artefact, and the artefact exists.

The clauses that go badly are rarely the ambitious ones. They are the ordinary sentences everybody writes, whose evidence turns out to live in two systems that were never joined.

  • "Made under an approved policy" is the clause most written and least shownThe document is versioned and dated. The decision record rarely carries which version governed it, so the join is made afterwards by inference — a plausible account of which rules applied rather than a record of it.
  • "Reconstructable afterwards" describes an ability, not an artefactReconstruction is work somebody does when the question arrives, from material gathered for other purposes. It can be accurate and still not be the same object as a record written as the decision executed.
  • Review clauses describe a cadence, not a casePeriodic review and sampling scale with reviewer time. Automated decision volume does not, and the clause is silent about the cases the sample never reaches.
  • Challenge and appeal clauses promise something to someone outside the organisationWhatever the process hands a person or their adviser has to stand up away from your systems. A clause that can only be honoured by giving them an account on your infrastructure has not been honoured.
  • Retention clauses decide what is left when the question arrivesA commitment to be able to show something later is a commitment about what is kept, in what form, and for how long. It is usually drafted in a different section by different people from the ones who wrote the commitment it has to serve.

Which clauses a decision-time record can carry

One word is doing two jobs here, and separating them is the first useful thing this page can do. The document this page is about is a policy in the ordinary sense: prose, approved by people, addressed to an organisation. MeshQu's "policy" is a narrower object — a machine-evaluable ruleset, versioned and ratified, that a decision is actually evaluated against. A good document names the ruleset that implements it. The ruleset is not the document, and neither one substitutes for the other.

A Decision Receipt is a signed, replayable record of how a consequential decision was made, created at the moment it happens and independently verifiable afterwards. It records the policy in force, relevant decision context, the outcome and the integrity information needed to determine later whether the signed record has changed.

For a drafter, the useful consequence is that a handful of clauses stop being promises about future effort and become descriptions of an artefact that already exists by the time anyone asks. That is what execution proof means here, and it is where MeshQu sits: the execution-proof layer of AI governance.

  • "Made under an approved rule" becomes a recorded fact rather than an inferenceA snapshot of the ruleset that applied is taken as the decision is evaluated, and its digest is bound into the record's integrity hash. Which version governed a decision is read off the record instead of being reconstructed from two systems that were versioned separately.Receipt Reference §3 (Policy Snapshot), §14 (what is and is not bound)
  • "Reconstructable afterwards" becomes re-runnableReplay re-evaluates the recorded context against the frozen snapshot: the same inputs and the same snapshot produce the same result. A clause drafted around replay describes something a second party can repeat, rather than something your team can assemble.Receipt Reference §15 — snapshot replay, Implemented
  • "Ratified by the right people" travels with the decisionApproval lineage records which policy version was ratified, and that the rules evaluated are the ones that version carried. The ratifier's keys reach the verifier separately from the operator's, which is what keeps that check independent of whoever runs the system.Receipt Reference §15 — approval lineage, Implemented; requires ratifier trust roots supplied out-of-band
  • "Checkable by the person asking" does not mean giving them an accountIntegrity and signature checks run against key material supplied to the verifier, never against a value carried inside the record being checked. A challenge clause can therefore promise a check the challenger performs rather than one you perform for them.Receipt Reference §15 — offline integrity and signature verification, Implemented
  • "We can produce the record for a single decision" has an artefact behind itA self-contained verification bundle carries what a third party needs in order to check one decision. A bundle verification reports ten sub-claims individually rather than collapsing them into one pass or fail, and material that is absent is reported as not applicable rather than as a soft pass.Receipt Reference §10 (Verification Bundle), §15; DEMO_VERIFICATION_BUNDLE in src/lib/fixtures
  • "Records are not quietly rewritten" has a check, and it is two checksThe integrity hash binds the content and the signature covers the hash. It is the two together that make an edit evident, so a clause that promises tamper-evidence should be drafted around both rather than around the signature.Receipt Reference §2 (hash payloads, signing envelope); docs guides/verifying-offline

What this does not prove

A page about drafting has an obligation the others do not: anything overstated here gets copied into a document that then has to be honoured. So the limits below are the ones to read before a sentence borrowed from this page ends up in a policy.

  • Verification proves issuance and integrity. It never proves the decision was correct.A passing check says the record was issued under a known key and has not changed since. It says nothing about whether the rule was right, the inputs were true, or the outcome was the one that should have been reached. Correctness stays a separate question, for policy validation and model risk management.
  • Most of a policy is not of this kind, and should not be drafted as though it wereScope, prohibition, procurement, training and incident clauses are evidenced by inspection, evaluation and audit of the programme — different artefacts, at different times. Drafting one as though a decision-time record discharged it produces confident-looking evidence for something nobody measured.
  • A record evidences that a rule was applied. It does not evidence that the rule was any good.Whether the ruleset encodes a defensible standard is a judgement about the ruleset and about the people who ratified it. Nothing in the artefact speaks to it, and a clause that implies otherwise is claiming something the record cannot carry.
  • MeshQu does not write, review or assess a policy documentNothing here is legal or regulatory advice, and no part of this makes a document adequate. What it does is make a subset of a document's commitments evidenceable at the moment they apply.
  • A valid signature alone does not detect an editThe signature covers the integrity hash rather than the content, and the integrity hash is what binds the content. It is the two checks together that make tampering evident.
  • MeshQu does not authenticate the actorThe schema records whether a decision was taken by a human or by an automated system. Who or what acted is context the integrator supplies; the receipt records that it was supplied, not that it was true. An accountability clause drafted on the stronger reading is drafting a promise nobody can keep.
  • Signing establishes non-repudiation, not honestyAn organisation holding its own signing key can sign whatever it chooses to sign. Receipts become load-bearing through the obligation to emit one for every decision in scope, and through external anchoring — both governance choices the document has to make rather than properties of the artefact.
  • A receipt is itself sensitive materialA signed record of a consequential decision about a person is regulated personal data. Retention, access control and disclosure clauses still have to be written and engineered; receipts constrain what is captured, they do not remove the privacy surface.

The authoritative source

The docs page owns the test this page applies to a clause: which commitments are statements of intent, which are evidenceable by a different artefact at a different time, and which can be evidenced at the moment a decision executes — with the full account of what a Decision Receipt does not evidence. This page is about writing the clause; that page is where the distinction it depends on is drawn.

Read Responsible AI: Evidence and Intent

Read next

Elsewhere on this site

  • AI governance frameworks: where execution proof fits

    AI governance frameworks describe how decisions should be made. Execution proof is the separate artefact that shows a particular decision was made that way — produced as it executes, and checkable by someone who was not there.

  • Responsible AI governance: what can be shown about one decision

    Responsible AI governance sets commitments about how AI systems treat people. Which of those can be evidenced for a particular decision, and which can only be asserted, is settled at the moment that decision executes.

  • Policy-as-Code Still Doesn't Solve This

    Policy-as-code engines evaluate decisions consistently. They do not preserve them. The case for capturing each decision at execution rather than asking the engine to reconstruct it later.

  • The Problem Isn't Policy. It's Proof.

    Tier-one banks do not lack AI policy. They lack the ability to prove a single decision when an FCA letter arrives eight months later. Governance is tested one decision at a time.

Next step

If a clause is drafted and nobody can name the artefact that would demonstrate it, that is the conversation worth having. Bring the clause.

Start a conversation
Availability

MeshQu is currently available for research, evaluation and design-partner deployments. Production availability and support commitments are agreed per engagement.