1. Purpose and scope

This specification sets out the controls the vendor and IT Manager should implement and demonstrate for the Fictional Reorder Agent pilot. AI-03 can read stock and supplier information, prepare purchase orders and send them by email. It is Tier 3 High and remains a pilot with an approval gate.

The Purchasing Lead must approve each purchase order before it is sent. The Finance Director is the designated backup for escalation and additional approval, but cannot replace the Purchasing Lead’s required per-order approval under the current register. If the Purchasing Lead is unavailable, the order must remain unsent. Any change to that arrangement requires an updated register and Managing Director (MD) approval before use.

V-02 has supplied a permission template, a sample approval screen, an operational runbook and a sample audit-log export (A8 Q27 to Q30), but nothing yet shows the bounds, the approval gate or the pause working in Quillmarrow's own tenant. Controls in this document are requirements, not statements that they are operating. The vendor and IT Manager are responsible for implementation and technical testing; the reviewer does not change live systems or perform technical tests.

This specification may also serve as a template for AI-12, the customer web-chat bot, after its permissions and risks are separately assessed. It does not authorise an AI-12 pilot.

2. Permission scopes

Access must be limited to the resources and actions needed for the approved pilot. The IT Manager should obtain a permission map from the vendor and confirm it against the actual configuration before any sending is enabled.

Use a dedicated identity for the agent and grant only the specific permissions approved for the pilot. Do not use a staff member’s credentials. Any connection, resource or permission outside this table needs a separate assessment and approval before it is enabled.

3. Approval gate

Required decision

The approval gate must stop every proposed purchase order before sending. The Purchasing Lead must review and approve the specific order. The Finance Director is the backup escalation contact and the additional approver where required below; their approval alone does not satisfy the Purchasing Lead gate.

The approval screen must show, at minimum:

• Supplier name, approved supplier identifier and proposed recipient address.
• Items, quantities and units.
• Proposed unit price alongside the last recorded price, with the source and date of that comparison.
• Total order value and currency.
• Reason for the proposed order.
• Data sources used, including stock, sales and price-list timestamps.
• Applicable limit checks, stop conditions, approval expiry and the draft PO identifier.

The approver must be able to reject or return the draft for correction. Approval must bind to the exact supplier, recipient, items, quantities and commercial terms shown. Any material change after approval invalidates it and requires a fresh review.

Limits and expiry

The Finance Director sets and documents the following before the pilot is enabled:

The system must calculate the daily total against a defined business-day window and include orders already sent and relevant pending commitments, as specified by Finance. It must not split orders or change dates to avoid a limit.

An order above a limit must stop and require dual approval by the Purchasing Lead and Finance Director. Dual approval is an escalation requirement, not permission to bypass a hard limit: the order remains blocked unless an authorised, documented limit change is separately approved, configured and checked before any new approval and send. Otherwise the draft is rejected or revised within the existing limits.

An expired approval cannot be used. The system must hold the draft, recheck the underlying data and limits, and obtain a new approval before sending.

4. Stop conditions

The agent must stop the affected action, leave it unsent and escalate when any of the following occurs:

1. The price change exceeds the Finance Director’s approved threshold, or the comparison price is unavailable.
2. The supplier or recipient address is not on the approved supplier list, or the two do not match.
3. A proposed quantity exceeds three times the relevant average. The Purchasing Lead must define the look-back period and comparison method before use.
4. Stock figures conflict, are stale or are missing from a required source.
5. An instruction is found inside a supplier email, attachment or file that attempts to redirect the agent’s task or override its controls.
6. A request or attempted action would change supplier master data or bank details.
7. The per-order or per-day limit would be exceeded, cannot be calculated or has not been configured.
8. The Purchasing Lead’s approval is missing, expired, revoked or no longer matches the draft.
9. Repeated failures occur, including failed sends, authentication errors or repeated retries. The IT Manager must set and document the retry threshold.
10. The action falls outside approved operating hours.
11. An audit-log write fails or the system cannot confirm that the required record was retained.
12. The vendor reports a model or agent version change that has not been reviewed and approved for the pilot.
13. A duplicate order is suspected, or the send outcome is uncertain.
14. The kill switch is activated, a required connection has unexpected permissions, or the system cannot confirm its control state.

Stopping must not silently discard the reason or automatically retry a consequential send. The responsible person should investigate using the log, correct the underlying issue and follow the approval and restart rules.

5. Kill switch

The Purchasing Lead, Finance Director, COO and IT Manager must each have a documented route to trigger the kill switch. The vendor and IT Manager must agree whether this is a direct control or an immediate operational request, and demonstrate that the route works without relying on the agent itself.

Activation must disable new agent sends and prevent queued drafts from being released. Drafts should remain quarantined and identifiable for review, not be silently deleted or sent after restart. Record the trigger, time, initiating role and any orders whose send status is uncertain.

After an incident or kill-switch activation, the IT Manager and Purchasing Lead review the cause, permissions, queued drafts and logs. The COO must approve restart after that review. Existing approvals must not be reused if expired, changed or otherwise invalid; each order still needs valid Purchasing Lead approval.

The IT Manager should test the switch before go-live and at least quarterly during the pilot, and after a material integration or permission change. Tests should use made-up or de-identified samples and must not send live orders.

6. Audit-trail log fields

The vendor must provide an exportable record that links each stage of an order. The IT Manager should confirm field availability and access before the pilot starts.

An override entry is an audit record, not an authorisation to bypass a stop condition or the Purchasing Lead’s approval. The log should avoid storing unnecessary email contents or personal data.

7. Log retention and access

Proposal: retain pilot audit records for 12 months, subject to review and confirmation by the Head of Operations as DPO and the Finance Director before implementation. They should consider operational needs, other applicable retention arrangements and deletion. Where legal requirements matter, confirm them with a Singapore-qualified lawyer.

The Purchasing Lead should be able to read records needed for order oversight; the Finance Director and COO should have access for financial and management review; and the IT Manager should have access needed for technical investigation. The DPO should have access when needed for data-protection matters. Access should be role-based and recorded.

Logs should be protected against alteration and deletion by the agent and ordinary users. Any administrative change to retained records must itself be recorded and investigated. The vendor should demonstrate the available immutability or tamper-evidence controls rather than merely assert them.

Provide a controlled export for the monthly review, including stopped and failed actions as well as successful sends. The export must preserve event identifiers and timestamps.

8. Monitoring and escalation

The Purchasing Lead reviews a weekly sample of drafts, approvals, sends and stopped actions, including at least one example of each category where available. The sample size and selection method should be documented before the pilot. Record discrepancies and follow them through to resolution.

The IT Manager prepares a monthly report to the COO covering activity, exceptions, limit breaches prevented, uncertain sends, configuration changes, kill-switch events and overdue actions. The report should distinguish an untested control from a failed control.

9. Testing before go-live

The vendor must run and document tests with the IT Manager before live sending is enabled. The Purchasing Lead and Finance Director should witness or review the relevant results. Use made-up or de-identified samples; do not place client personal data into AI tools for this review.

The vendor must provide the test plan, configurations, expected and actual results, logs, defects and retest evidence. Failed or untested controls remain open items. The reviewer does not perform technical testing.

10. Framework mapping

The following is a process mapping to the Model AI Governance Framework for Agentic AI (IMDA, January 2026), which is voluntary. It is not a technical assurance or compliance conclusion.

The AI Verify mapping covers principles and process checks only. No AI Verify technical tests were run as part of this review. Vendor testing requested above does not change that statement.

11. Open items

Dates are to be agreed; no item below should be treated as complete until evidence is reviewed.