02 / IN PRACTICE
Procurement exceptions with the reasons on record
GembaOS is a zero-trust governance runtime for enterprise AI agents: policy-decided access, single-use clearance tokens bound to exact parameters, and accountable human approvals, running on-premises or in a private VPC. This scenario is the procurement exception: an employee needs a purchase outside the rules (one vendor, off the catalog, over budget), and the question is who agreed, on what, and why.
When is an off-catalog purchase an exception, and who decides?
The playbook decides the route from facts GembaOS reads on the requisition: the amount, the budget still available, how many quotes are attached, and whether the vendor is already onboarded. Under the officer’s limit, within budget, with three quotes and a known vendor, the procurement officer alone signs. Anything else adds the finance director. Each signer picks a consult finding from a closed list before signing, so the next signer signs over a conclusion, not over an email thread.
| Before | With GembaOS | |
|---|---|---|
| The request | A form, then a chain of emails about it | One work item with the requisition as read and the requester’s own words |
| More quotes | “Can you send two more?” in a reply | A document round on the requester’s ticket, with a due date |
| Legal on the vendor terms | A forwarded contract, answered whenever | Legal signs right after the officer when the officer’s finding asks for it |
| The decision | “Approved” in someone’s inbox | One approval request with every signer’s finding and reason |
| Marking the exception | Updated by hand afterward | Written once under a clearance token, after the requisition is read again |
What happens when the officer needs one more quote?
| Step | Who | What is recorded |
|---|---|---|
| 1. Request | The employee names their requisition and says why | Their words; only their own requisition can be named |
| 2. Route | The runtime reads the requisition and drafts the request | The facts (amount, remaining budget, quotes, vendor onboarded, days until needed) and the route |
| 3. Finding | The procurement officer signs “needs more quotes” | The finding returns the request and opens a round for quotes |
| 4. Quotes | The requester uploads them on the ticket | The round, the files, when they arrived |
| 5. Resubmit | The same request, read again | What changed since the officer last looked: new files, the round answered |
| 6. Sign | The officer (“justified, terms to legal”), legal, finance | The signature chain with three findings |
| 7. Execute | The runtime, under the clearance | The requisition compared with what the signers saw, then the exception marked once |
Where is the control point?
The findings and the route. A signer cannot skip a finding, and a finding cannot be one the playbook did not define. “Needs legal review” puts legal on the route; “terms need changes” returns the request to the handler. The requester sees their own request, the documents asked of them and the answer, never the signers’ notes. The exception is marked on the requisition only after the requisition is read again and still matches what was signed.
GembaOS does not look for split purchase orders. What it does is keep each request’s facts in front of every signer, and keep the record of who signed which request.
What does it look like?
What do we need to start?
- Your purchasing rules as they are today: what counts as an exception, and who signs which kind.
- Read access to requisitions and one call that marks the exception, through the REST or SQL adapter.
- The findings each role signs with, in your own words.
- Employee sign-in through your identity provider, so the requester is who they say they are.
Related: claims that take weeks, cross-team workflows, the glossary.
Questions this note answers
Who approves a single-source purchase exception?
The people your authority table names for it. In the shipped playbook the procurement officer signs every exception with a finding; above the limit, off the vendor list or short of quotes, the finance director signs too, and legal when the officer asks for it.
What happens when the officer needs more quotes?
The officer signs with the finding "needs more quotes". The request goes back, and the requester is asked for quotes on their ticket. When they arrive, the same request is resubmitted with the new files and the round on it.
Does GembaOS catch split purchase orders?
It does not look for them. It routes each request on its own facts (amount, remaining budget, quotes, whether the vendor is onboarded), and every signer sees those facts before signing.
Last updated: · GembaOS v0.2