SV / ZeroGruntIndependent application by Saran Vashisht

Independent application by Saran Vashisht

A working case for ZeroGrunt 01 / 07

An invoice workflow you can put to the test.

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.

01 / The invoice lab

A printer maintenance invoice, from review to receipt.

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.

Interactive simulation / synthetic data · resets on reload

01 / context

What happens when policy changes?

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.

Current authorityPolicy v1 · Operator up to ₹2,000

Awaiting operator review.

Changing the threshold invalidates approval here. A committed posting would not be changed retroactively.

02 / Engineering decisions

Four choices behind the demo.

01

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 ↗
03

Separate a correction from a future rule.

Start with a one-off fix. A scoped candidate needs a separate testing decision and human activation.

Review a correction ↗ · Rule code ↗
04

Compare the candidate with the baseline.

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

Where this way
of thinking comes from.

Three projects, chosen for the problems they helped me understand.

01 Integration & recovery

Field Relay

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 ↗
02 Operational understanding

Tetr Compass

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 ↗
03 Evaluation & judgment

Listening Party

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

How this was built.

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

Start close
to the work.

A proposal, conditional on customer access and context, not an agreed roadmap.

  1. 01

    Observe

    Follow one finance workflow with the people doing the work. Find the real exceptions and handoffs.

  2. 02

    Define

    Agree on states, source authority and what a person must review before an action.

  3. 03

    Build & challenge

    Deliver one reviewed path, inject failures and evaluate proposed corrections against examples.

  4. 04

    Learn in a bounded pilot

    Choose metrics with the operator, inspect misses and use the results to decide what comes next.

06 / Continue the conversation

Thanks for taking
a closer look.

I’d love to discuss the workflow, the tradeoffs, and what I would change with access to a real operator.