Model controls as evidence states
A binary task list encourages premature completion. Use a small controlled vocabulary such as VERIFIED_PRESENT, MISSING, PENDING_REVIEW, and NOT_APPLICABLE. “Verified present” means the expected file or record was located and matched to the stated reference. It does not mean a tax form is legally valid, payment details were independently confirmed, a security posture was approved, or contractual language was interpreted.
The NIST supplier due-diligence guide frames due diligence as evidence-informed assessment. CISA's vendor SCRM template likewise supports explicit evidence and partial states. The practical lesson is simple: preserve which reviewer must make which determination.
The eight-control Cedar Analytics register
Our synthetic fixture uses a fictional analytics software vendor, an executed statement of work, an internal policy called POL-VEND-4, and an evidence register with IDs E-01 through E-08. The service can begin only “after onboarding approval”; there is no calendar start date. This deliberately prevents the model from manufacturing a kickoff date.
| Policy control | Evidence in fixture | State | Reviewer or blocker |
|---|---|---|---|
| Executed agreement | E-01: SOW-22 signed by both parties on 2026-08-31 | VERIFIED_PRESENT | Start date remains conditional on approval |
| Tax form received | E-02: W-9 file located | VERIFIED_PRESENT | Presence only; tax validity not determined |
| Payment details independently verified | E-03: details received in Finance vault; verification absent | MISSING | Finance must verify through its approved channel |
| Data-processing review | E-04: draft DPA; signature missing | PENDING_REVIEW | Privacy/legal review and signature remain open |
| Security review | E-05: questionnaire received; review pending | PENDING_REVIEW | Security approver has not decided |
| Named business owner | E-06: Jordan Lee recorded | VERIFIED_PRESENT | Owner still confirms responsibilities |
| Least-privilege access plan | E-07: read-only sandbox request; no production request | PENDING_REVIEW | Scope evidenced; access not granted |
| Documented go-live approval | E-08: no approval record | MISSING | Final gate stays closed |
This artifact is more precise than a conventional checklist because each row answers four different questions: what the policy requires, what evidence exists, what that evidence proves, and who must decide next. It also exposes why the final result is NOT_READY_FOR_GO_LIVE.
Keep sensitive values out while preserving references
The model does not need the bank account, tax identifier, password, API key, or questionnaire response. It needs a non-sensitive reference and state, for example: “Finance vault record E-03 says payment details were received; independent verification status not recorded.” A human with permission can open the vault record. The AI workspace only carries the control boundary.
| Do include | Do not include | Why |
|---|---|---|
| Evidence ID, system, and last-known state | Bank routing or account values | Finance can verify without exposing payment data |
| Tax-form presence and reviewer status | Taxpayer identifier | Receipt is not tax validation |
| Requested role and environment | Password, token, recovery code, private key | Access must flow through IAM or secret management |
| Questionnaire receipt and approval state | Security answers or sensitive architecture detail | The security reviewer keeps the source material |
Use a prompt that cannot approve the vendor
Control-register contract
Base the register solely on the fictional SOW, policy, and evidence ledger.
Create one row for each POL-VEND-4 control.
Allowed states: VERIFIED_PRESENT, MISSING,
PENDING_REVIEW, NOT_APPLICABLE.
Represent absent owner and deadline fields as null.
Do not validate tax status, verify bank details, approve security,
grant access, infer a service date, or approve go-live.
Return final_gate = NOT_READY_FOR_GO_LIVE.Require a specific evidence reference and review flag on every row. Ask separately for blocked_items so the output cannot bury missing approvals in narrative. Never use a prompt such as “finish our onboarding checklist” because the requested outcome itself pushes the model toward completion.
What the test proved—and what it did not
The retained response represented all eight controls, preserved four blockers, listed prohibited data categories, and returned NOT_READY_FOR_GO_LIVE. A local Python gate accepted those source-bounded states. It then rejected three altered copies:
- Go-live opened. Changing only the final gate failed because approval evidence is absent.
- Finance verification invented. Marking payment verification as present failed; the source records receipt, not independent verification.
- Security approval invented. A received questionnaire cannot become an approved review.
The test did not authenticate a vendor, inspect a tax form, access a vault, evaluate questionnaire answers, sign a DPA, provision an account, or contact any party. It proves only that selected fields in the retained fictional response agree with the fixture contract.
Download the control-workflow reproduction archive to inspect the complete prompt and result. The archive also includes the other four workflows, an offline standard-library checker, fifteen negative cases, test metadata, and file hashes. Re-run the checker before adapting it, then change both the fixture and expected rules deliberately.
Operate the register as a gate sequence
Gate A: scope and tier
Classify the supplier type, service, data involved, integration, access environment, geography, and business criticality using your organization's method. The example covers an ICT supplier requesting a read-only sandbox path; it does not define due diligence for construction, healthcare, logistics, labor, or other categories.
Gate B: contract and ownership
Confirm the executed document and accountable business owner. Preserve conditions such as “after onboarding approval” exactly. Do not turn the signature date into a service date or assume the named owner has accepted every operational responsibility.
Gate C: Finance and tax
Keep document receipt separate from validation. Independent payment verification should occur through the Finance process, using trusted contact details and segregation of duties. The AI-generated row can point to the Finance record but cannot perform that verification.
Gate D: privacy, security, and access
Record the privacy and security review outcomes only after the authorized reviewers decide. A least-privilege plan is not an access grant. Require the actual IAM record, environment, role, expiry, approver, and provisioning evidence before changing state.
Gate E: launch decision
Define which earlier controls are mandatory, who may approve exceptions, what residual risks must be accepted, and where approval is recorded. Calculate readiness from those explicit policy rules outside the language model. A generated summary should never be the authority that opens production.
Reviewer handoff
- Open each evidence reference in its authoritative system.
- Confirm the executed agreement and current amendments.
- Ask Finance to record independent verification without exposing values.
- Require privacy and security reviewers to enter their own decisions.
- Compare requested access with the approved environment and role.
- Keep every exception, risk acceptance, and approver traceable.
- Leave the go-live control missing until the designated authority records it.
Where this cluster continues
Requirements discovered before selection belong in an RFP compliance matrix, while the executed agreement controls onboarding. After purchase activity begins, use the three-way purchase match to separate ordered, received, and invoiced quantities. Track ongoing clauses in the contract obligation register. For sensitive source preparation, apply the AI data-protection workflow first.
Release rule
The register is ready for reviewer use when all required controls appear once, each state is backed by a non-sensitive evidence reference, missing decisions remain missing, and reviewer ownership is explicit. The vendor is not ready for go-live until the organization's policy logic and authorized approver—not the model—say so in the controlling system.
