TLDR
Executive briefThe supplier says the product did not change
- Contract the accepted configuration as a moving identity envelope spanning model, prompt, retrieval, tools, data, policy, people, controls and evidence.
- Classify change by its possible consequence for outcomes, authority, population, rights, security, cost and reversibility, not by the supplier's release label.
- Start notice and preservation clocks before root cause is known; contain the service while keeping the evidence required to reconstruct what happened.
- Make evidence duties reciprocal and usable through protected access, reproducible summaries and independent verification rather than blanket confidentiality claims.
- Escalate from restoring control to rollback, substitution, transition or termination; credits supplement a remedy but never replace operational recovery.
A reseller reports that its commercial service is unchanged. The endpoint name is the same, the product page is the same and the invoice is the same. Yet a customer-support assistant now refuses a class of legitimate requests that it accepted last week. The reseller later learns that an upstream provider replaced a model version behind an alias. The buyer's ordinary change clause asks whether the product materially changed. The contract gives no shared definition of the accepted system, no version evidence, no clock for preserving the old configuration and no practical right to test or roll back.
The dispute is not really about whether a release was major or minor. It is about control. An AI service is a configuration of models, prompts, retrieval sources, tools, policies, data pipelines, safety layers, human authority and upstream dependencies. Behaviour can move when any one of those elements changes, even if commercial packaging remains stable. The same elements determine which logs, test cases and decisions are needed to distinguish model failure from misuse, integration error, population drift, buyer workflow change or silent supplier modification.
An agreement cannot predict every release or incident. It can operate a disciplined decision system. The AI Contract Control Loop in this paper uses five linked schedules to identify the accepted configuration, route changes, preserve incident evidence, govern protected access and move through remedies that restore control. The loop gives routine improvement standing authority when evidence shows that it remains inside the accepted envelope. It applies stronger gates when consequence, uncertainty or irreversibility rises. The objective is not contractual bulk. It is an executable allocation of notice, evidence, authority, containment and continuity.
This paper begins after selection. Paper 121 defined the operating capability being bought. Paper 122 designed the competition. Paper 123 mapped lock-in. Paper 126 defined probabilistic service levels, and Paper 127 tested supplier claims. The present task is narrower and more operational: bind the surviving promises and residual uncertainty into lifecycle duties that still work after signature. Paper 129 will test portability before commitment. Here, the focus is when and how those rights become executable during the contract.
AI Contract Control LoopReplace static pages with five connected schedules
A conventional statement of work, service schedule and liability clause often divide ownership by document rather than event. A behavioural change touches one schedule, an incident another and exit a third. Evidence falls between them. The AI Contract Control Loop is this article's synthesis. It turns five schedules into one operating route. Every material event starts with configuration identity, passes through a typed change or incident pathway, carries an evidence bundle, reaches a named authority and closes only when the agreed control state is verified.
The Configuration Schedule records the accepted identity envelope and the conditions under which the system is permitted to operate. The Change Event Schedule classifies routine, bounded, behavioural, material, emergency, security and regulated changes, then assigns notice, evaluation, approval and rollback duties. The Incident Evidence Schedule starts detection, qualified notice, containment, preservation, update, analysis, remediation and closure clocks. The Evidence Access Schedule states what each party must provide, the access tier, retention period and independent route when direct disclosure is inappropriate. The Remedy and Continuity Schedule maps loss of control to cure, scope constraint, human review, rollback, substitution, affected-party action, transition or termination.
These are schedules because they must remain structured, versioned and usable by operating teams. Their fields can sit in annexes, a joint register or an authorised control system. The contract text should define precedence, obligations and remedies. The live schedules should hold the operational facts and approvals. A supplier should not need a deed of variation to correct an immaterial infrastructure defect. A buyer should not discover through an incident that the retrieval corpus, human decision boundary or evidence retention period had changed outside the signed record.
| Schedule | Minimum live record | Decision it controls | Closure receipt |
|---|---|---|---|
| Configuration | Purpose, population, components, authority, limits, evaluation and owner | Is this still the accepted system? | Current approved identity and expiry |
| Change event | Proposed delta, consequence, evidence, notice, gate and rollback | Can the change proceed, and under whose authority? | Acceptance, constraint or rejection record |
| Incident evidence | Detection, notice, preservation, scope, updates, cause and remediation | What can continue while facts are incomplete? | Independently verified control restoration |
| Evidence access | Provider and buyer evidence, protection tier, retention and assessor | Can the event be reconstructed without uncontrolled disclosure? | Accessible, reproducible evidence package |
| Remedy and continuity | Control loss, cure, rollback, substitution, restitution, transition and exit | Which practical control state must be restored? | Tested restoration or completed transition |
Configuration Identity EnvelopeDecide whether the changed service is still the accepted system
A brand name is not a system identity. Neither is a model family, an endpoint alias or a software bill of materials by itself. The Configuration Identity Envelope is this article's synthesis for keeping behavioural, technical and operating identity together. It describes what may vary without reopening acceptance and what cannot change without evidence and authority. The envelope is intentionally outcome-led: it specifies the accepted operating boundary more tightly than hidden implementation trivia.
Start with purpose, decision, consequence and affected populations. Record the provider and model family, but also the prompt, retrieval, tool and policy versions that shape behaviour. Add data rights, retention, geography and lineage; human authority, escalation and fallback; performance, cost and control limits; permitted variation and prohibited behaviour; evaluation set, monitoring window and evidence version; and the accountable owner, approval date and expiry. A version hash without these conditions can reproduce software while failing to reproduce the accepted service.
The envelope needs three kinds of field. Fixed fields cannot move without explicit buyer acceptance, such as purpose, prohibited decisions, regulated geography or the maximum authority of an automated action. Bounded fields may move under standing authority if evidence shows that the change remains within defined tolerances, such as a prompt repair that preserves evaluated behaviour. Observed fields describe the operating context, including population mix, input quality, reviewer capacity and cost. A change in an observed field may come from the buyer rather than the provider, yet it can still push the system outside its safe envelope.
Identity is therefore a joint control. The provider must identify its configuration and upstream dependencies. The buyer must identify how the service is actually used, the populations reached and the human decisions surrounding it. When either party detects a mismatch, the contract should require a control-board event rather than a debate about blame. Responsibility can be allocated after the service is contained and the evidence is preserved.
| Layer | Identity field | Allowed movement | Evidence receipt |
|---|---|---|---|
| Purpose and population | Use, decision, consequence, eligible and excluded groups | Explicit acceptance for scope or consequence change | Use register, population slices and approval |
| Technical chain | Model, provider, prompt, retrieval, tools, policy and upstreams | Standing authority only inside tested tolerances | Version manifest, lineage and comparison tests |
| Data boundary | Rights, provenance, retention, location and transformations | No silent rights or jurisdiction change | Data receipt, entitlement and deletion state |
| Authority and controls | Human role, tool permissions, escalation, fallback and prohibited acts | No increase in decision or action authority without acceptance | Policy version, access record and control test |
| Performance and evidence | Limits, cost, evaluation set, monitoring window and evidence version | Metrics and denominators change only through a disclosed gate | Frozen test, monitoring comparison and owner sign-off |
Change Consequence RouterRoute what the change can alter, not what the release note calls it
Supplier labels are useful technical metadata but weak contractual classifications. A vendor may call a release a maintenance update because little code changed. For a buyer, the same update may alter who receives a refusal, which personal data crosses a border or whether a tool can commit an action. Conversely, a substantial infrastructure refactor can remain within the envelope when interfaces, behaviour, evidence and control are preserved. The Change Consequence Router is this article's synthesis for separating engineering size from contractual effect.
Every proposed or discovered change is tested against eleven consequence dimensions: outcome, population, authority, data, controls, security, explainability, interoperability, cost, reversibility and regulatory status. The highest material dimension sets the route. A routine change has no credible effect outside the envelope and carries an ordinary record. A bounded change has a plausible effect but passes pre-agreed evidence and rollback conditions under standing authority. A behavioural or material change requires revalidation and explicit buyer acceptance. A regulated change also invokes the applicable legal or policy gate. An emergency or security change may proceed before full evaluation when delay creates greater harm, but it starts an incident-style preservation and retrospective acceptance clock.
The contract should define who proposes, who classifies, who can challenge and who decides. The supplier provides the technical delta, upstream notice, affected functions, test evidence, known uncertainty and rollback state. The buyer provides intended-use, population, downstream consequence, operational capacity and regulatory context. A joint panel can route ordinary cases. Named buyer authority should decide material acceptance. Security personnel need temporary power to constrain or patch in an emergency, with a narrow scope, recorded reasons and a fixed evidence deadline.
Silence is itself a routing fact. If the supplier cannot identify the upstream version, cannot reproduce the evaluation or cannot determine which customers were affected, the change is not safely bounded. It moves to constraint or incident response until evidence is restored. This rule makes uncertainty operational without pretending that missing evidence proves supplier fault.
| Route | Trigger | Authority and evidence | Operating posture |
|---|---|---|---|
| Routine | No plausible movement outside fixed or bounded fields | Supplier records delta; standing authority applies | Continue with ordinary monitoring |
| Bounded | Potential effect remains within tested tolerance | Comparison evidence, known-good rollback and named owner | Approve with increased observation |
| Behavioural or material | Possible outcome, population, authority, data, control or cost change | Revalidation and explicit buyer acceptance | Hold, shadow, limit or pilot |
| Emergency or security | Delay creates immediate security or safety exposure | Emergency authority plus preservation and retrospective test clock | Patch narrowly, constrain functions and verify |
| Regulated | Legal classification, substantial modification or mandated duty may change | Legal, risk and accountable operational approval | No ordinary release until the gate clears |
Incident Evidence ClockNotify and preserve before certainty arrives
Many incident clauses choose one notification deadline and then wait for root cause. That is the wrong sequence for an AI service whose configuration, prompts, outputs, external calls and human decisions may be transient. An early notice can be qualified without being vague. It should say what is known, what is not known, which configuration and populations may be affected, what containment is active, what evidence is preserved and when the next update will arrive. The clock begins on detection of a defined signal, not after the supplier completes its internal legal characterisation.
The Incident Evidence Clock is this article's synthesis. At detection, the responsible party opens an immutable event record and captures the configuration identity. Qualified notice follows at the agreed consequence-based interval. Containment preserves logs, freezes relevant versions, protects affected records and prevents destructive remediation. Updates refine scope, population, consequence, uncertainty and workarounds. Causal analysis distinguishes originating failure, contributing conditions and failed controls across provider and buyer boundaries. Remediation includes correction, restitution, replay where lawful, recurrence controls and affected-party support. Closure requires independent or buyer-authorised verification and retention through the relevant claims, regulatory and organisational-learning periods.
The contract should use several clocks rather than one promise. A severe event may require rapid qualified notice, immediate preservation, frequent updates and a later causal report. A lower-consequence anomaly may use a longer update interval but the same evidence discipline. Stop conditions matter. If a tool can continue to create irreversible effects, containment may mean suspending that action while preserving read-only assistance. If the issue affects one population slice, aggregate service availability cannot justify ordinary operation for that group.
Evidence preservation must survive supplier remediation. Replacing a model, rebuilding an index or deleting a compromised tool image can erase the very state needed for explanation and remedy. The schedule should define snapshots, chain of custody, time synchronisation, log completeness, export format, permitted redaction and independent escrow. It should also prevent the buyer from demanding irrelevant information about other customers. Proportional preservation is narrower and more useful than unlimited discovery language.
| Event | Minimum content | Clock principle | Authority |
|---|---|---|---|
| Detect and open | Signal, time, reporter, configuration, possible consequence | Immediate immutable record | Either party |
| Qualified notice | Known facts, uncertainty, population, containment and next update | Before root cause; scaled by consequence | Incident lead |
| Preserve and contain | Logs, versions, prompts, data lineage, tool calls and human actions | Before destructive repair | Technical and evidence custodians |
| Analyse and remediate | Origin, contributors, failed controls, correction and affected-party action | Updates continue while analysis develops | Joint response team |
| Verify and close | Retest, monitoring window, recurrence control, residual risk and retention | No supplier-only closure | Buyer or independent verifier |
Evidence Reciprocity MatrixMake disclosure protected, mutual and decision-useful
A one-sided audit right can fail in both directions. The provider may hold model, system, change, upstream and incident evidence but lack the buyer's input quality, use context, human decisions and discovered downstream effects. The buyer may demand raw logs without protecting trade secrets, shared infrastructure or other customers. The provider may call every relevant artefact proprietary. Both positions make causal reconstruction weaker.
The Evidence Reciprocity Matrix is this article's synthesis. The provider supplies configuration manifests, change deltas, evaluation and monitoring records, dependency provenance, incident timelines, control operation and remediation evidence. The buyer supplies authorised-use records, input and population context, human-review decisions, local integrations, reported harms, workarounds and changes in workflow. Each item has a purpose, minimum field set, protection tier, format, retention period and accountable custodian.
Access can be layered. Routine summaries should be reproducible from retained underlying evidence. Sensitive material can move through a secure data room, clean room, redacted extract, confidential independent assessor or regulator. A summary that cannot be independently reconciled to source evidence is a statement, not an audit mechanism. Equally, an unrestricted demand for source code or unrelated tenant data is not made proportionate merely by calling it an audit.
Remedy and Continuity LadderRestore control before calculating credits
A service credit can recognise unavailable capacity or missed response times. It cannot reconstruct an affected decision, restore a known-good model, constrain unsafe authority or make a buyer portable. The remedy should follow the control that was lost. The Remedy and Continuity Ladder is this article's synthesis for escalating by consequence, evidence obstruction, recurrence and reversibility.
The first rung is intensified monitoring and a time-bound cure while ordinary operation remains justified. The second constrains scope, population, action authority or data access and may require human review. The third rolls back to a known-good configuration or substitutes an approved model, tool or retrieval source. The fourth corrects affected records, supports affected people, replays cases where lawful and funds reasonable independent verification. The fifth activates continuity: export data and configuration, operate the fallback, switch a component and obtain transition assistance. The final rung terminates use while preserving evidence, deletion proof, open-incident cooperation and claims support.
Escalation should not depend only on breach severity. A moderate problem with complete evidence, tested rollback and prompt cure may remain low on the ladder. Repeated late notices, contradictory records or missing logs can justify continuity action because the buyer can no longer verify restoration. A severe but well-contained event may use a high operational rung without immediate termination. The control board records why the selected rung is proportionate and who can move it down after verification.
Continuity rights must be technically rehearsed. The agreement names export formats, configuration artefacts, evaluation cases, retained logs, dependencies, credentials, data deletion, knowledge transfer, transition capacity and charges. Rollback identifies a known-good state and a tested procedure, not merely a contractual verb. Substitution identifies interface, performance and evidence requirements. Termination retains access to the event record long enough to resolve affected cases. A right that cannot be exercised under incident pressure is decorative.
| Rung | Control action | Evidence to enter | Evidence to leave |
|---|---|---|---|
| 1 · Observe and cure | Increase monitoring; correct within a fixed period | Bounded consequence and complete evidence | Cure test and stable monitoring window |
| 2 · Constrain | Limit population, data, feature or action; add human review | Control uncertainty or localised effect | Verified control and approved scope |
| 3 · Roll back or substitute | Restore known-good version or replace a component | Material movement outside envelope | Comparison test, reconciliation and owner acceptance |
| 4 · Correct and verify | Repair records, support affected people, replay and independently assess | Consequential or disputed effects | Restitution record and recurrence control |
| 5 · Transition | Export, fallback, knowledge transfer and managed replacement | Persistent failure, deprecation or unverifiable restoration | Operational successor and evidence handover |
| 6 · Terminate and retain | Stop use, delete as required and preserve claims evidence | Failed cure, prohibited state or intolerable dependency | Exit completion, deletion proof and retained incident access |
Ten contract testsRun the schedules against events that ordinary clauses miss
Each case below is a negative control for the agreement. The receipt names configuration identity, change class, evidence due, clock, affected control, reciprocal duties, interim posture, remedy rung, verification authority and closure condition. If teams cannot populate those fields before signature, the clause is unlikely to become useful during a real event.
1. Silent upstream model replacement changes refusals
Identity and class: The accepted reseller service includes the upstream model version, refusal policy, eligible support population and evaluation evidence. Replacement behind a stable alias is a behavioural material change, regardless of the reseller's commercial label. Evidence and clock: Preserve old and new version identifiers, prompts, refusal traces, routing logs, upstream notices and population-slice comparison. Qualified notice begins when the reseller detects the divergence, not when the upstream explains it. Duties and posture: The provider discloses the dependency and coordinates evidence; the buyer supplies affected cases and workflow changes. Constrain the refused category or route it to staff. Remedy and closure: Rung three rollback or substitution applies. The buyer's verifier closes only after matched regression, affected-case reconciliation and stable monitoring.
2. Retrieval corpus rights, provenance and jurisdiction change
Identity and class: The envelope names the retrieval corpus, licence, provenance, refresh process, residency and allowed uses. Adding a source whose rights or processing jurisdiction differs is a material data and regulatory change. Evidence and clock: Supply the corpus delta, entitlement, lineage, location, removal mechanism and outputs influenced. Notice precedes ingestion where practicable; preservation captures the index and access state. Duties and posture: The provider proves sourcing and isolation, while the buyer confirms purpose, permitted use and local data contributions. Quarantine the new source and continue on the accepted index if safe. Remedy and closure: Rung two constraint, followed by deletion and re-indexing if required. Legal and data owners verify rights, absence from the active index and affected-output treatment before closure.
3. Supplier delays notice while seeking root cause
Identity and class: Repeated unexplained tool calls affect the accepted authority and monitoring fields. Treat the signal as an incident even though causal class remains open. Evidence and clock: Open the immutable record, preserve call traces, identities, prompts, responses and receiving-system receipts, then issue qualified notice with known facts and uncertainty. Duties and posture: The provider supplies system and upstream facts; the buyer supplies operator actions and downstream state. Disable the affected tool while retaining read-only assistance. Remedy and closure: Rung two constraint applies, plus independent review if evidence was lost during delay. The buyer incident authority closes after cause, contributing conditions, affected cases, restoration test and a verified change to the notice process.
4. Subcontracted tool vulnerability and incomplete chain records
Identity and class: The tool, version, permissions and subcontractor are part of the technical chain. A vulnerability with uncertain deployment scope is an emergency security change and incident. Evidence and clock: Preserve inventories, tool images, SBOM or component records, credentials, network traces and subcontractor communications. Notice states that scope is incomplete. Duties and posture: The prime coordinates its chain and exposes gaps; the buyer provides local connection and identity logs. Revoke credentials, isolate the tool and use the tested fallback. Remedy and closure: Rung three substitution may follow emergency patching. Security authority and an independent assessor verify inventory completeness, containment, credential rotation and recurrence controls. Missing chain evidence keeps the service constrained.
5. One population drifts while the aggregate remains green
Identity and class: Population slices and performance bounds are configuration fields. Material deterioration for one language group is a behavioural incident even when the aggregate service level passes. Evidence and clock: Preserve slice definitions, denominators, evaluation-set versions, monitoring windows, input changes and human outcomes. Notify on the slice threshold. Duties and posture: The provider supplies predictions and system changes; the buyer supplies population mix, workflow and reviewer evidence. Route the affected group to a validated alternative while other groups continue if independently safe. Remedy and closure: Rung two constraint and rung four correction apply. The capability owner closes after slice-specific revalidation, affected-case review and a stable monitoring window.
6. Logs are called proprietary and reconstruction is blocked
Identity and class: Evidence access and retention are part of the accepted control, not an optional audit courtesy. Inability to reconstruct a consequential event is evidence obstruction and control failure. Evidence and clock: Preserve the complete record while the access dispute is resolved. Provide minimum reproducible fields through the agreed secure room or independent assessor. Duties and posture: The provider protects unrelated secrets and maps records to conclusions; the buyer limits use and supplies its local logs. Constrain the disputed function. Remedy and closure: Escalate from rung two to rung five if the agreed access route remains unusable. Independent verification, not a provider summary alone, is the closure condition.
7. Emergency security fix must precede full evaluation
Identity and class: A library flaw creates credible immediate exposure, while the proposed patch may alter output formatting. This is an emergency security change that should proceed under narrow authority. Evidence and clock: Snapshot the current version, record the vulnerability basis, patch delta, smoke tests, known uncertainty and rollback state. Start retrospective evaluation and notice clocks at deployment. Duties and posture: The provider patches and monitors; the buyer activates enhanced review and reports integration effects. Keep high-consequence actions constrained until comparison tests finish. Remedy and closure: Rung two is precautionary, not punitive. Security and capability owners accept ordinary service only after the vulnerability is closed, behavioural tests pass and any affected records are reconciled.
8. Routing update lowers inference price but raises total cost
Identity and class: The envelope includes routing policy, latency, correction workload and whole-service cost limits. A cheaper model route that increases refusals, retries and human work is a material cost and behaviour change. Evidence and clock: Supply route distributions, version identity, token and tool use, retry rates, queue demand, correction time and matched outcome evidence. Notice occurs before broad rollout. Duties and posture: The provider exposes inference and routing records; the buyer supplies labour and delayed-outcome cost. Use a capped shadow or bounded population. Remedy and closure: Rung three rollback applies if total cost exceeds the envelope. Finance and capability owners close on a matched whole-cost window, not on lower unit price.
9. Model deprecation creates a finite transition
Identity and class: The accepted model version and supported substitutes are named. Deprecation is a material lifecycle change even without current failure. Evidence and clock: The provider supplies end date, migration path, feature differences, evaluation support, export needs and fallback capacity within the contractual notice period. Duties and posture: The provider maintains service and transition assistance; the buyer makes test data, owners and decisions available. Freeze discretionary expansion and validate the substitute in parallel. Remedy and closure: Rung five transition begins early. The buyer accepts the substitute after full configuration comparison, or exits after data, configuration, evidence and open-case handover. The deadline does not erase unresolved incidents.
10. Repeated missing evidence makes restoration unverifiable
Identity and class: Several incidents have late updates, inconsistent versions and incomplete logs. Each event may be moderate, but recurrence and evidence obstruction mean the contracted control system is failing. Evidence and clock: Preserve all available records, gap explanations, prior cure promises and continuity assets. A new joint incident starts because ordinary assurance can no longer establish the operating state. Duties and posture: The provider must reconstruct or disclose the limit; the buyer must provide its records and avoid unsupported accusations. Constrain consequential use and activate fallback. Remedy and closure: Credits are inadequate. Rung five transition or rung six termination applies. Only an independent reconstruction and verified new evidence process can justify return; otherwise closure is completed exit with retained claims evidence.
AI Contract Control BoardTurn the agreement into the next executable decision
The AI Contract Control Board is this article's synthesis. It does not calculate a universal contract-risk score. It resolves the current event into one of five materially different outcomes: approve a bounded change under standing authority; require revalidation and explicit buyer acceptance; constrain or roll back while evidence is restored; trigger joint incident response and preserve evidence; or exercise transition or termination rights. Each route produces the same structured receipt so that a decision can be challenged, revisited and closed.
Use the named scenarios to test every route, then change the inputs. The output shows the configuration identity, change class, evidence due, clocks, missing or contradictory evidence, reciprocal duties, current constraint, remedy rung, continuity readiness, owners and next contractual event. The board is an operating aid, not legal advice or a substitute for the signed allocation of authority.
Strong rival and operating practiceDo not freeze useful change with contractual theatre
The strongest rival is serious. Detailed clauses cannot stop a fast-moving model. Excessive approval gates can turn safe maintenance into breach, delay security fixes and freeze beneficial improvement. Suppliers cannot disclose shared infrastructure, other customers' data or every proprietary implementation detail. Buyers often lack the technical capacity to use the evidence they request. An over-specified configuration can create paperwork while teams continue to make real decisions through informal channels.
The answer is typed change, proportional evidence and executable rights. Define purpose, population, authority, prohibited behaviour and control outcomes more tightly than implementation trivia. Permit changes under standing authority when comparison evidence demonstrates that they remain within the envelope. Increase evidence, buyer acceptance and independent verification as consequence, uncertainty and irreversibility rise. Use secure rooms and assessors when raw disclosure is inappropriate. Contract for reproducibility and challenge, not unlimited visibility.
Operational preparation matters more than clause volume. Before production, the parties should simulate a bounded release, a silent upstream change, a severe incident, an evidence-access dispute, a rollback and a partial exit. They should time qualified notice, retrieve a version manifest, export the agreed logs, invoke the assessor and restore a known-good state. A failed rehearsal is valuable because it identifies the right to repair while there is still time and leverage.
Governance should also distinguish law, policy, guidance, standards analogy and commercial synthesis. The EU AI Act and Canada's directive establish or illustrate lifecycle responsibilities in their applicable domains. OMB and UK playbooks inform public-sector acquisition and contract practice. NIST, CISA and NCSC supply risk, incident and supply-chain guidance. Model Cards and FactSheets show documentation patterns, while procurement research exposes limits in supplier self-reporting. The named constructs in this paper are a synthesis for contracting; they are not presented as legal requirements or official standards.
The practical test is simple. When a configuration changes or an incident begins, can the parties identify the accepted system, preserve the relevant state, decide what may continue, exchange protected evidence, restore control and exit if restoration cannot be verified? If the answer depends on goodwill, the contract has described cooperation without securing it. A functioning AI agreement keeps evidence and authority close enough to the event that the buyer can act before the facts disappear.
Evidence spineSources checked 3 September 2026
- US OMB, M-25-22: Driving Efficient Acquisition of Artificial Intelligence in Government.
- European Union, Regulation (EU) 2024/1689, Artificial Intelligence Act.
- UK Government, Guidelines for AI Procurement.
- UK Government, Digital, Data and Technology Playbook.
- UK Government, Contract Management Playbook.
- NIST, Artificial Intelligence Risk Management Framework.
- NIST, AI RMF Playbook.
- NIST, Generative Artificial Intelligence Profile.
- NIST, SP 800-61 Rev. 3.
- CISA, Secure by Demand Guide.
- CISA, NSA and ODNI, Securing the Software Supply Chain: Guide for Customers.
- UK NCSC and partners, Guidelines for Secure AI System Development.
- UK NCSC, Mapping Your Supply Chain.
- Treasury Board of Canada Secretariat, Directive on Automated Decision-Making.
- Mitchell et al., Model Cards for Model Reporting.
- Arnold et al., FactSheets: Increasing Trust in AI Services.
- Hickok, Public Procurement of Artificial Intelligence Systems.
- Kuehnert et al., Disclosure or Marketing?.
About this paperA contract that moves with the system
The AI Contract Control Loop, Configuration Identity Envelope, Change Consequence Router, Incident Evidence Clock, Evidence Reciprocity Matrix, Remedy and Continuity Ladder and AI Contract Control Board are this article's synthesis. They connect lifecycle contracting, incident response, evidence rights and operational resilience without treating a supplier label, one notification deadline, a blanket audit clause or service credits as control.