2026-09-10 · article
A decision before the model call
A worked example of choosing a decision design before adding an LLM to a public-procurement workflow.
This reconstructed example shows the decision design behind a public-procurement system built and demonstrated on 109 real notices.
The situation
Relevant notices arrive across public portals and national sources. A person can spend the day reading work that does not fit, then still miss something that does. An LLM can read and rank the notices, but a final no-bid decision can carry a real commercial cost.
The decision
Could the system make final bid or no-bid calls? Or should it narrow the field and leave the accountable decision with a person?
Decision design: Use the machine to identify clear noise and rank possible fits. Keep every possible bid with a human. Record the rules, evidence, threshold, and approval that produced the final outcome.
Why this path fit
The cost of missing a relevant tender was higher than the cost of a human reviewing a short list. The system could remove obvious mismatches, but it could not make the business accountable for a hidden rejection.
The build has three layers:
- Score: rules plus a model read the notice against the client catalogue.
- Approve: a human reviews any notice that might fit.
- Control: the system writes the evidence and decision to an append-only record.
What a session would test
The same reasoning applies before an app or automation is built. What is the decision? Who owns it? What happens when the system is wrong? Which data and rules must be visible? Those answers define whether AI helps and what the smallest useful system looks like.
The system is described in more detail in the public use case. This note does not claim that the structure suits every procurement process. It shows how the downside of a decision shaped one system.
Have an idea or project that needs a decision first? Bring one decision to a prepared external assessment and leave with a written recommendation. View the decision session.