Skip to content
NTPU AI Learn

GoAI 101 · 6h · Module 6

Government AI Procurement Requirements and Acceptance Decisions

How do you write verifiable requirements, and decide whether a system is acceptable?

Start Section 1
  • Duration60 min
  • LevelCore
  • PrerequisiteNo hard prerequisite
0 / 5 completed
Sync my progressJoin a session to keep progress across devices and share it with your instructor

Info

After you join, your completed lesson numbers are sent to your instructor together with your learner code, so they can see your progress. Use the codes your instructor gave you, and do not enter your name, company secrets or other personal data. Progress is kept with the rest of that session's data.

Learning objectives

  • Rewrite a vague requirement into an entry with a verification method, acceptance criterion, and delivery evidence.
  • Describe data, permission, human approval, logging, and operations requirements, and the 14 acceptance dimensions.
  • Cite an evidence package to give an Accept / Accept with conditions / Reject decision, with reasons and open items.

From business purpose to verifiable requirement

12 min

From business purpose to verifiable requirement

This module reuses a simulated scenario: a (fictional) city government contracts a "petition triage AI" that reads a petition, suggests a category and handling unit, and only dispatches the case after a caseworker approves. If requirements are vague, acceptance can only rest on impressions and demo polish.

The chain from purpose to evidence
  1. Business purpose
  2. Concrete requirement
  3. Verification method
  4. Acceptance criterion
  5. Delivery evidence

Vague wording

"The system shall provide intelligent classification and improve administrative efficiency." No scope, no numbers, and nobody can tell whether it was met.

Verifiable wording

Concrete requirement
For 200 de-identified petition samples supplied by the agency, the system outputs a suggested category and the supporting passage; low-confidence or unclassifiable items must be flagged and handed to a person.
Verification method and criterion
The agency tests on the designated samples; agreement with the human reference answers is at or above the threshold both sides agree on, and 100% of low-confidence cases have a hand-back record.
Delivery evidence
Test report, item-level test records, and a list of handed-back cases.

Info

A good requirement entry answers three questions: how is it verified, who verifies it, and what result counts as a pass. Thresholds must be set by the agency according to business risk; the figures here are teaching illustrations only.
Check yourself

A requirements document says "system responses shall be reasonable and accurate." Which revision best makes it acceptable to verify?

A requirements document says "system responses shall be reasonable and accurate." Which revision best makes it acceptable to verify?

Key takeaway: A requirement is not an adjective: each one must connect to a verification method, an acceptance criterion, and delivery evidence. If no evidence can be named, the requirement is not finished.

Requirement categories and entries

12 min

Requirement categories and entries

Turning earlier modules into requirements does not start from a blank page. The categories below map to work you have already done; each category needs at least one verifiable requirement.

Five core requirement categories with examples (teaching illustrations)
Requirement categoryEarlier output it builds onExample verifiable requirement
Data requirementsData and tool permission tableOnly agency-approved petition data sources may be used; data must be de-identified before input; raw petitions must not be sent to unapproved external services.
Permission requirementsData and tool permission tableThe AI account has read-only access to petition data; any write or dispatch action requires caseworker approval.
Human approval requirementsFlow chart with human gatesLow-confidence, personal-data, or high-impact cases must go to human review; the system must not close a case automatically.
Logging requirementsGovernance and control checklistEvery suggestion retains an input summary, output, sources, approver, and time; retention follows agency rules.
Operations requirementsThree-type test casesRegression tests must be rerun and reported before any model or knowledge update; abnormal events are reported to operations staff within the agreed time.
  • Suggested requirement entry fields: ID, category, requirement, rationale, priority, risk, verification method, acceptance criterion, required evidence, supplier responsibility, agency responsibility.
  • Write supplier and agency responsibilities separately so acceptance and operations do not end in disputes about who must do what.

Warning

This course teaches a way of thinking about turning needs into requirements. It is not legal advice or a contract template. Actual clauses, security requirements, and procurement procedures must follow the laws, policies, and procedures that apply to your agency.

Key takeaway: Data, permission, human approval, logging, and operations requirements are the main way to turn earlier designs into acceptable clauses.

The 14 acceptance dimensions

12 min

The 14 acceptance dimensions

Acceptance cannot rest on a demo. The full acceptance form has 14 dimensions, and each needs matching evidence. In the lecture we focus on the ones most likely to have gaps in this case.

The 14 acceptance dimensions and typical evidence
DimensionQuestion to askTypical evidence
FunctionDoes it do the core task?Functional test report
WorkflowDo the flow and human gates work as designed?Flow test records
Accuracy / QualityDoes output quality meet the bar?Sample results compared with reference answers
Knowledge / RAGDo cited sources have origin, version, and currency?Source list, version records
PermissionIs access least-privilege?Permission settings screen or config
Security / PrivacyAre sensitive data and injection attacks controlled?Security checks, de-identification records
Tool UseAre tool calls within authorized scope?Tool call records
Human ApprovalAre high-impact actions approved by a person?Sample approval records
Logging / TraceabilityCan we reconstruct who did what afterwards?Log samples, traceability drill
Error HandlingIs there a fallback when something fails?Failure case test results
ReliabilityIs it stable across repeated runs?Repeated test results
Version ControlAre version changes managed?Version and change records
Regression TestIs it re-verified after updates?Regression test report
Operations & MaintenanceWho operates it after go-live and how are incidents handled?Operations manual, reporting process
  • The first 4 (Function, Workflow, Accuracy / Quality, Knowledge / RAG): is the system doing the right thing.
  • The middle 4 (Permission, Security / Privacy, Tool Use, Human Approval): is the system properly controlled.
  • The last 6 (Logging / Traceability, Error Handling, Reliability, Version Control, Regression Test, Operations & Maintenance): what happens when things go wrong, and can it be sustained over time.
Check yourself

An acceptance team checks only "Function" and "Accuracy / Quality" before signing off. What is the main problem?

An acceptance team checks only "Function" and "Accuracy / Quality" before signing off. What is the main problem?

Key takeaway: All 14 dimensions stay on the acceptance form and are checked one by one; the lecture highlights key gaps, but no row on the form may be left blank.

Evidence package and acceptance decision

12 min

Evidence package and acceptance decision

Simulated evidence package (fictional scenario)

The supplier delivers: a functional test report (classification agreement met the agreed threshold), results for 50 edge cases, a permission settings screen (AI account read-only), and log samples. Missing: failure-case tests for handing low-confidence items to a person, a regression test report after a model update, and operations and incident-reporting documents.

Dimension-by-dimension judgment (excerpt)
DimensionEvidence statusJudgment
FunctionReport is complete and can be re-checkedMet
PermissionSettings screen shows read-onlyMet
Error HandlingNo failure-case test resultsEvidence missing
Regression TestNo regression test reportEvidence missing
Operations & MaintenanceNo operations or reporting documentsEvidence missing
  • Accept: all key dimensions are supported by evidence; the system may go live.
  • Accept with conditions: core dimensions are met and a few items can be fixed by a deadline; state the conditions, deadline, owner, and the evidence that clears each condition.
  • Reject: a key dimension (such as permission control or human approval) is missing or carries serious risk; return for rework and re-accept.

Warning

The judgment in this example is Accept with conditions, but if the gap were in human approval or permission control it should be Reject. Acceptance is decided by the agency's responsible staff, not by the AI or a supplier's promise, and a test that was not actually run and retained cannot count as evidence.
Check yourself

The supplier's demo runs smoothly and a manager wants acceptance "today." What is the best approach?

The supplier's demo runs smoothly and a manager wants acceptance "today." What is the best approach?

Key takeaway: An acceptance decision is evidence plus reasons plus open items; Accept with conditions must state the conditions, deadline, owner, and the evidence that clears them.

Practice and application

12 min

Practice: rewrite a requirement and make an acceptance judgment

This practice fills the "procurement requirements" and "acceptance decision" fields of the integrated Canvas, reusing the case data you entered in earlier modules. Use only simulated or de-identified data; do not enter secrets, real personal data, or unauthorized sensitive information.

  1. Rewrite one vague requirement
    Turn the vague requirement provided into an entry with requirement text, verification method, acceptance criterion, and required evidence.
  2. Read the provided evidence package
    Check it against the 14 dimensions and mark items with evidence, missing evidence, and insufficient evidence.
  3. Make the acceptance decision
    Choose Accept / Accept with conditions / Reject, state the reasons, and cite the evidence.
  4. List open items
    Name what is still needed, the owner, and the deadline; record unresolved items in the Canvas open issues field.

Info

This practice builds one complete requirement and one evidence-based judgment as a reusable method; it is not a full procurement document. A human always remains the final accountable decision maker.
Check yourself

When writing the reasons for an acceptance decision, which of the following should NOT appear?

When writing the reasons for an acceptance decision, which of the following should NOT appear?

Key takeaway: One verifiable requirement plus one evidence-based judgment is a reusable method for procurement and acceptance.

Save as PDF

What next?