Record which policy was used.
Policy, entity and vendor records are authority; retrieved explanations are context. A changed policy can make an earlier approval stale.
Try changing the policy ↗ · Context code ↗Independent application by Saran Vashisht
A working case for ZeroGrunt 01 / 07
Saurav, I wanted to try the problem in your post. I chose one invoice and built a small way to explore changing context, a lost response, a correction and its evaluation.
Printer maintenance
NORTHSTAR-IN
A fictional invoice for this exercise.
01 / The invoice lab
I picked a familiar expense because the interesting part is what happens when the coding, approver or posting outcome is uncertain. Choose a question to try it.
01 / context
Policy v1 assigns invoices up to ₹2,000 to an operator. The decision uses the entity, vendor and policy versions, not just a retrieved explanation.
Awaiting operator review.
Changing the threshold invalidates approval here. A committed posting would not be changed retroactively.
02 / Engineering decisions
Policy, entity and vendor records are authority; retrieved explanations are context. A changed policy can make an earlier approval stale.
Try changing the policy ↗ · Context code ↗Keep the business identity stable. After a lost response, inspect the receipt before deciding what happened.
Explore recovery ↗ · Relay code ↗ · Store code ↗Start with a one-off fix. A scoped candidate needs a separate testing decision and human activation.
Review a correction ↗ · Rule code ↗Keep rejected cases and scope exclusions visible. A passing control is not evidence that a different candidate improved.
Inspect evaluation ↗ · Evaluation code ↗03 / Selected work
Three projects, chosen for the problems they helped me understand.
I built a browser reconciliation desk and a separate synthetic HTTP integration lab. The lab treats approved inputs, business identity and receipt readback as distinct concerns.
The browser and HTTP lab are separate. Neither is a live customer ERP integration.
Read the contract ↗I built a portal around post-deposit documents, next tasks and staff follow-up. A student submitting a document and staff verifying it are different events.
The later fictional RAG guide is separate from the historical portal.
See the project ↗Stricter retrieval candidates rejected useful requests, so I kept BM25 rather than treating a new approach as an automatic improvement.
A small synthetic comparison: 40 development and 34 held-out cases. It does not prove customer benefit.
See the project ↗04 / How I build with AI
I set the brief and used Codex to build and test this exercise. The code and recorded results are here to inspect; I’m learning to explain the choices and their limits.
My background is in enterprise support and automation, product and operations. Those experiences have made me pay attention to the person who has to resolve an exception when a process stops.
05 / A proposed first month
A proposal, conditional on customer access and context, not an agreed roadmap.
Follow one finance workflow with the people doing the work. Find the real exceptions and handoffs.
Agree on states, source authority and what a person must review before an action.
Deliver one reviewed path, inject failures and evaluate proposed corrections against examples.
Choose metrics with the operator, inspect misses and use the results to decide what comes next.
06 / Continue the conversation
I’d love to discuss the workflow, the tradeoffs, and what I would change with access to a real operator.