Precision is not more detail.It is less consequential ambiguity.
A technology decision becomes precise when its task, boundary, evidence, quality conditions and authority are clear enough to test—and clear enough to recognise when the system must defer, recover or stop.
Open the acceptance contractTurn the performance claim into acceptance conditions.
Performance identifies the outcome, KPI, counter-signals and decision rule. Precision converts that account into requirements that can be designed, tested, operated and revised.
Requirements engineering standards treat requirements as information produced through defined processes across a system or service life cycle—not merely a list of requested features.1 Quality models likewise provide consistent characteristics for specifying and evaluating whether a product is fit for purpose.2
- Performance claim
- Resolve routine needs reliably without displacing avoidable effort.
- Precision question
- Which task, cases, sources, quality conditions and exceptions define “reliably”?
- Acceptance result
- A bounded capability with evidence, ownership and a revision condition.
Specify the capability around the consequence of being wrong.
The illustration is hypothetical. It demonstrates how one vague request—“an AI assistant for customer enquiries”—can become an acceptance contract. The exact controls and thresholds require evidence from the actual context.
Assist an agent with routine product information.
The system retrieves approved material and drafts a response. It does not decide entitlement, create a commitment or close a consequential complaint.
Proceed only when the evidence and operating route are ready.
No single score establishes acceptance. The decision combines task evidence, system quality, human review and consequence.
- Evidence
- Representative cases and documented limitations
- Threshold
- Defined by consequence—not copied from a benchmark
- Reviewer
- Named role with information, time, competence and authority
- Recovery
- Correction, escalation, appeal and incident route
What may the system rely on?
Authoritative records, access controls, freshness, provenance and handling of conflict. Data-quality requirements can be explicitly defined and evaluated.3
What must a person be able to see and do?
Distinguish source material from generated text; expose status, uncertainty and errors; enable correction, escalation and recovery.
What changes the permission to operate?
Missing sources, drift, new uses, recurring exceptions, complaints, incidents or evidence that the control no longer works.
Defines materiality, authority and the decisions that must not be delegated.
Builds the test set, baseline, threshold, segmentation and evidence record.
Specifies sources, interfaces, lineage, access, logs, security and recovery.
Defines the task, evaluation, error distribution, deferral and monitoring.
Specifies comprehension, correction, explanation, appeal and accessibility.
Precision here concerns clarity in decisions and requirements. It is not statistical precision, and it does not imply that more detail is always better.
Define what happens at the edge—not only what stays inside.
AI management and risk standards emphasise organisational context, objectives, risk treatment and continuing improvement.4 AI-specific risk guidance also concerns organisations that develop, deploy or use AI-enabled products and services.5 Precision therefore includes the operating system around the model.
The intended task
Name the user, action, source, output and context. “Answer enquiries” is too broad; retrieval, drafting, routing and deciding are different tasks.
Test the work that is actually proposed.Excluded use
State cases, decisions, data and consequences for which the capability is not authorised. Exclusion must be enforceable, not merely written.
Prevent scope from expanding silently.Deferral and escalation
Appropriate escalation can be the correct result. Distinguish necessary escalation from avoidable failure and define who receives the case.
A lower escalation rate is not automatically better.Correction and recourse
Specify how errors are detected, recorded, corrected and communicated—and how an affected person can challenge or appeal a consequential result.
Recovery is an acceptance condition.“A person will review it” is not yet a control.
NIST guidance calls for identifying features and capabilities that require human oversight and documenting how oversight is provided.6 UK information-regulator guidance similarly recommends standardised review procedures and traceable responsibility.7
A reviewer must be able—not merely present—to change the outcome.
A model confidence score is not, by itself, a dependable operating boundary. The review route must be defined around consequences, information and authority.
See the basis
Relevant source, status, limitations and generated content are distinguishable.
Understand the decision
The reviewer has domain knowledge and understands known system limitations.
Have time to intervene
Workload, interface and timing permit meaningful review rather than ceremonial approval.
Override and recover
The person can change, reject, escalate and initiate correction or recourse.
Acceptance is multidimensional.
Accuracy alone is rarely enough. The relevant characteristics depend on the product, task and consequence. For AI, impact assessment can extend the inquiry to effects on people and society.8
Fit, reliability and security
Functional suitability, reliability, performance efficiency, security, maintainability and compatibility may all create requirements.
Drawn selectively from ISO/IEC 25010—not every characteristic applies equally.Usability and accessibility
Inputs, errors, status messages and recovery must be understandable and operable. WCAG 2.2 supplies normative web-accessibility criteria where applicable.9
Compliance needs testing in the actual interface.Impact, transparency and recourse
Applicable obligations depend on role, use, sector and jurisdiction. High-risk uses may require documented risk management, human oversight and declared accuracy or robustness characteristics.10
Legal classification must be established for the real deployment.Precision gives the decision a reason to proceed—and a reason to change.
- Proceed
- The task, evidence, operating route and consequence support the bounded use.
- Revise
- The requirement, interface, source, threshold or review process does not fit the evidence.
- Restrict
- The capability remains useful only for narrower cases, users, data or conditions.
- Stop
- The benefit no longer justifies the risk, burden or unresolved failure.
This page is an inquiry framework, not legal advice or a compliance determination. Regulation (including the EU AI Act), data-protection duties and sector rules apply according to the actual system, role, people affected, jurisdiction and dates in force.
Make the capability precise enough to be practised—and open enough to improve.
The acceptance contract now identifies the task, boundary, sources, quality conditions, oversight and revision route. Practice can examine whether those requirements survive ordinary work, changing conditions and shared experience.
- The permission
- What may the capability do—and for whom?
- The proof
- What evidence and quality conditions permit operation?
- The return path
- When does authority move, the design change or operation stop?
Sources and notes
The AI-assistant example and acceptance architecture are editorial. Standards and institutional guidance support particular practices; none validates this complete page model or determines compliance for a specific deployment.
- ISO/IEC/IEEE 29148:2018 — Requirements engineering. Specifies processes and information items for requirements-related activities across systems, software and services.↩
- ISO/IEC 25010:2023 — Product quality model. Defines a quality model for ICT and software products. Characteristics must be selected for the actual context.↩
- ISO/IEC 25012:2008 — Data quality model. Supports defining data-quality requirements, measures and evaluation for structured data.↩
- ISO/IEC 42001:2023 — AI management systems. Specifies requirements for establishing, maintaining and continually improving an AI management system in organisational context.↩
- ISO/IEC 23894:2023 — AI risk management. Guidance for organisations developing, producing, deploying or using AI-enabled products, systems and services.↩
- NIST AI RMF Playbook — Map. Suggested actions include identifying capabilities requiring human oversight and training relevant actors. The Playbook is voluntary guidance, not a checklist or certification.↩
- UK ICO — Human review guidance. Institutional guidance concerning standardised review procedures for AI outputs in a data-protection context; applicability depends on the processing and jurisdiction.↩
- ISO/IEC 42005:2025 — AI system impact assessment. Addresses societal and human impacts and complements AI management and risk standards.↩
- W3C, Web Content Accessibility Guidelines 2.2. Normative web-accessibility requirements, including input-error identification and status communication; conformance requires assessment of the implementation.↩
- Regulation (EU) 2024/1689 — Artificial Intelligence Act. The official legal text includes requirements for certain high-risk AI systems concerning risk management, human oversight, accuracy, robustness and cybersecurity. Scope, role, classification and application dates require case-specific legal assessment.↩