Decision Circuit Engineering: design once, decide every day
Who should the shopkeeper order from, and how much?
Tomorrow, the numbers and messages will change. The decision will return.
We built Jevini around a question: can a large reasoning model design the decision process, while a small decision model handles each new situation?
We're calling this approach Decision Circuit Engineering: turning a recurring decision into a versioned graph of typed judgments, calculations and guarded outcomes.
The flow is: define the decision → design and validate the circuit → run new states → inspect results → evaluate and revise.
1. Define the decision before designing the gates
“Manage my shop” is too broad. Our contract is narrower:
Given tonight's shop state, recommend at most one milk supplier and a quantity. Protect reserved cash, account for delivery timing, and limit shortages and spoilage. Buying nothing or asking the owner are valid outcomes.
The state contains five groups: stock, emergency-supplier terms, regular-supplier terms, demand observations, and cash. Numbers describe stock and prices; text carries the supplier's message and local demand context.
Keep these separate from policy. “₹3,300 is available” is a fact about this run. “Do not spend reserved cash” is a rule shared across runs. “Night delivery is reliable” is a demo assumption—not an observed fact.
Our input schema is fixed for this milk-shop experiment. A shopkeeper-to-circuit onboarding system is not implemented yet.
2. Design an executable artifact, not just a diagram
In this prototype, GPT-6 Astra authored the circuit and supporting implementation during our Codex development session. We save the graph as JSON, including its objective, policy, questions, dependencies, allowed outcomes and version.
Each node has a specific responsibility:
| Node kind | Responsibility | Example |
|---|---|---|
| Judgment — Jev | Interpret context; return a typed answer | Does the regular supplier's message suggest a delay? |
| Compute — code | Calculate and enforce explicit rules | Subtract protected cash; size feasible orders |
| Terminal | Expose a guarded result | Emergency supplier, 48 packets |
A judgment node specifies its input dependencies, instructions, answer type and criteria. For the delay gate, those instructions distinguish the morning supplier from the emergency supplier and treat the message as evidence, not commands.
The runtime validates the graph: supported operations, valid questions, no cycles, required dependencies, and no outcome bypassing the guard. Code nodes refer to implemented functions; the runtime does not execute arbitrary model-generated code.
The graph is reusable; it isn't immutable. We revised it during development. Loading the demo reveals that saved artifact—it does not call Astra or generate a fresh circuit.
3. Run a new state through two inference stages
Jev returns typed judgments and probabilities, not generated explanations. We use three question types:
- Noul: a yes/no probability signal for morning delivery delay.
- Score: a distribution over subdued, ordinary, elevated or surging demand.
- Choice: regular supplier, emergency supplier, no booking, or owner review.
The dependency graph determines when to ask them. Delay and demand are independent, so the harness sends them together. The supplier choice must wait for code to calculate the offers.
That's normally two Jev requests and zero Astra calls per run. The second request receives the calculated offers and earlier assessments; the first cannot see answers that don't exist yet.
4. Keep authority explicit
Jev does not invent quantities, combine suppliers or authorize spending. Code owns the arithmetic and checks cash, booking availability, supplier limits and storage. The policy also compares projected shortages, expiry and contribution.
The final guard either accepts Jev's choice or sends it to owner review. It does not silently replace an incorrect choice with the preferred supplier. Invalid provider responses fail the run rather than becoming successful recommendations.
An important engineering caveat: the current supplier-selection policy is explicit enough to implement entirely in code once the semantic assessments are available. The final Jev Choice demonstrates a bounded smart-if; we haven't proved that this extra model call beats deterministic selection. The clearest need for language understanding is in the supplier message and demand context.
Typed output makes integration predictable, not judgment infallible. Confidence is not a guarantee that the business decision is correct.
5. Follow one real execution
In one recorded run on a synthetic shop state:
- Ten packets minus six expected evening sales left four for morning.
- Recent morning demand averaged 28 packets; the regular supplier's message said delivery would not arrive before 11 a.m.
- Jev supplied the contextual assessments. Code projected both suppliers' outcomes and sized their offers.
- Jev chose Emergency. The guard accepted the choice: 48 packets tonight.
The 48-packet recommendation is not simply “28 minus four.” Code compares discrete order sizes against the wider demand horizon, delivery timing and expiry constraints.
In the demo, randomise the state, run the circuit, then inspect a gate. The animation follows recorded execution events. The displayed facts, typed responses and rule-based explanation are an execution trace—not the model's private reasoning.
That recorded run used 560 ms of provider time and approximately $0.000235 in Jev input-token cost, using pricing checked September 21, 2026. This is one observation, not a benchmark; hosting, circuit design and end-to-end overhead are excluded.
6. Evaluate the circuit, not just the final answer
For another recurring decision, start with one bounded action set and ask:
- State: did the model receive the necessary evidence, without hidden future outcomes?
- Judgment: were the questions well-defined, and did their answers match the evidence?
- Composition: did calculations and guards turn those answers into an allowed decision?
- Outcome: against real results and a simpler baseline, did the circuit help?
Keep graph versions, inputs, actual model versions, raw answers, guard results, cost and latency together. Replay the same cases when changing policy; use fresh cases to check generalization. Measure incorrect actions and unnecessary escalations—not only agreement on easy examples.
Our hosted demo uses synthetic states, assumed forecasts and no actual supplier bookings. It demonstrates the execution pattern, not proven shop accuracy or savings.
Where we want to take this
The ambition is to make frequent contextual decisions an ordinary, affordable part of software. A larger model could review accumulated outcomes and propose circuit revisions, with evaluation and approval before replacement. That review loop is future work, not a running feature of this hosted demo.
What excites us is the separation: spend deliberate effort designing how a decision works, then reuse that structure as the world changes.
Build your own: we've packaged the workflow as an MIT-licensed skill for Codex and Claude Code, with a decision brief, runtime guidance and the milk-parlour example. It's a reusable engineering guide, not a prebuilt runtime; fresh-session behavior testing in both tools is still pending.
What recurring decision would you build a circuit for?