Chomkar Decision Grid

A buyer may need one to three tonnes of produce while individual farms declare only a few hundred kilograms each. Assembling the lot manually makes pricing, route risk, and fairness impossible to audit — and an AI that invents the numbers would be worse, not better.

Who it serves

Agricultural cooperators and coordinators who assemble multi-farm lots against buyer orders, and — as an audience for the method — anyone designing decision systems where a model must never own the arithmetic.

Why it matters

Coordination failures cost smallholder farmers real income. A recommendation system for money-adjacent decisions only deserves trust if every number can be re-derived, every refusal is honest, and a human explicitly approves the outcome.

My exact role

Framework design, the deterministic engine, the test suite, and the AI-assisted development workflow.

Team contributions

Built within the Chomkar product direction at CHNAI LAB; the synthetic scenario design draws on the team's field research.

Research

The volume-gap framing (farms declare 200–600 kg; buyers need 1–3 tonne lots) comes from the team's field research in Kampong Cham. The engineering question researched here: which decision-system patterns let a recommendation be audited by a non-programmer.

Validation so far

Validated against designed scenarios, including deliberate failure cases where the honest output is 'cannot fulfill' with a renegotiation recommendation. All data is synthetic and the repository says so plainly; no real orders, payments, or farmers run through it.

A deterministic, stdlib-only Python engine that models the workflow as Detect → Evaluate → Recommend → Act with an independent audit gate. AI explains the numbers; it never produces them. Every stage checkpoints state, and bilingual Khmer/English reports end with an explicit human-approval checklist.

User workflow

1. Load farmer declarations and a buyer order
2. Evaluate feasible lot combinations with zone-normalized scoring
3. Rank recommendations — or refuse honestly when no lot satisfies the order
4. Run the independent audit that re-derives payouts, allocation limits, coverage, and the winning score
5. Review the bilingual report and give or withhold human approval

System architecture

Deterministic core with an audit gate that recomputes results from raw inputs through separate code paths. Pricing invariants are enforced in three places — pricing code, unit tests, and the audit — so a regression cannot pass silently. Pipeline stages hash their inputs and resume only from changed state.

Methods

Zone-normalized (min-max) scoring for cross-province comparability, designed failure cases as first-class scenarios, invariant-based testing, and human-gated calibration where weight changes are bounded proposals requiring manual approval.

Business value

Demonstrates the trust architecture a real coordination product would need before touching real money: auditable pricing, honest refusal, and approval gates. The commercial hypothesis itself is tested separately under Chomkar OrderLoop.

Contracts & policy considerations

The engine deliberately does not authorize purchases, payments, or deliveries — recommendations are inputs to a human decision, which keeps the accountability boundary clean. A CI linter even prevents money arithmetic from appearing inside report prose.

Data & privacy

All bundled farmer, buyer, price, weather, and route data are synthetic. Testing the schema with real cooperator data would require redaction or documented consent first — that boundary is stated in the repository.

Risks

• Provisional decision weights could be mistaken for field-calibrated ones
• A polished prototype could be misread as an operating platform
• Synthetic scenarios may encode assumptions real deliveries will contradict

Technical decisions

1. Deterministic Python stdlib core; AI explains rather than invents the numbers
2. Detect → Evaluate → Recommend → Act with an independent audit gate as the workflow model
3. Designed failure cases so 'cannot fulfill' is a valid, tested output
4. Synthetic-only data with the limitation stated in the README rather than hidden

Lessons learned

• An audit that re-derives results through separate code paths catches classes of bugs tests alone miss
• Designing failure cases first makes honest refusal a feature instead of an afterthought
• Bilingual reporting is a product requirement, not a translation task — the approval checklist must be readable by the person accountable

What gets validated next

• Test the data schema with a real cooperator using redacted or consented data
• Compare route-risk estimates against observed spoilage and delivery outcomes
• Run usability testing with non-technical cooperative officers