VIII · Mēden agan · Nothing in excess
The system is the advantage.
Models are increasingly interchangeable for bounded tasks.
The lowest-cost model that reliably clears your quality bar, task by task.
In practice
What it means for your system.
For bounded tasks, several models can do the work. The lasting advantage is the system around them: the architecture, the data, and the evaluations.
- Each task uses the lowest-cost model that clears your quality bar.
- Evaluations turn a model change into a measured decision.
- Your rules, records, and test cases stay yours, whichever model runs.
The word for it
Systēma
σύστημα
Systēma is Greek for “a whole put together from parts.” The advantage lives in how the parts work together.
Why it matters
The model is a tenant. The system is the house you own.
For bounded tasks, such as sorting, extracting, or drafting, several models can meet the same standard. Paying for the most capable model on every task spends money where it adds nothing.
The value that lasts sits around the model: your architecture, your rules, your records, and your evaluations. Those assets stay with you when a model changes.
Evaluations make model choice a measured decision, made task by task. The spend follows the difficulty of each task, and your owner approves each choice.
Read it accurately
Scope of the rule.
- Model capability still sets the ceiling.
- Model capability still sets what a task can achieve. The rule asks that each task use the model it needs, measured on your own cases.
- Each task runs on the model it needs.
- Different tasks can run on different models. Each is chosen against that task’s own quality bar and cost.
- It applies most to bounded tasks.
- The rule concerns bounded tasks with a clear quality bar. Tasks that need broad reasoning may call for a more capable model, and the evaluation shows when.
How it is measured
Every rule is something you can check.
The lowest-cost model that reliably clears your quality bar, measured task by task.
In an engagement
Where the rule is applied.
The rule is checked at each stage of the work, from the first design to the system in operation.
In the design
The AI Workload Evaluation looks first at whether AI fits the workload. Where it fits, each task in the design gets its own quality bar.
In the build
Test cases are built from your reviewed work for each task. Model choice is then measured on those cases, task by task.
At acceptance
Each task is accepted with the lowest-cost model that reliably clears its bar. Your owner approves the model that runs each task.
In operation
Cost per accepted result is tracked for each task. A new candidate model is measured on the same cases before any change.
Check your own system
Five questions to ask this week.
Each one has a yes or no answer. A no marks where to start.
- Is each task in your workflow judged against its own quality bar?
- Do you know the cost per accepted result for each task?
- Could you swap the model on one task and measure the effect on your test cases?
- Are your test cases built from your own reviewed work?
- Does a named person approve which model runs each task?
Delivered through
The services that apply this rule.
Mēden agan
Nothing in excess.
No more model, spend, or autonomy than the work requires.
Apply the rule
Check it against your own system.
Questions
Is the AI Workload Evaluation a comparison of models?
No. The free evaluation looks at one workload and whether AI fits it, with a practical next step. Model selection comes later, measured on your own test cases.
Does the lowest-cost model mean lower quality?
No. A model qualifies only after it clears the bar your team set for that task. Cost decides only among the models that pass.
What happens when a model is retired or its terms change?
Because the system sits around the model, another candidate can be tested on the same cases. Your owner approves the replacement before it runs.
How do we check this rule on our own system?
For each task, ask which model runs it and what it costs. It should be the lowest-cost model that reliably clears your quality bar, measured task by task.
Do we need our own test cases to choose a model?
Yes, for a measured choice. Cases drawn from your reviewed work show how each candidate performs on the tasks you run.
How is quality measured on a task?
Against a bar your team sets, using test cases with known correct results. A model qualifies when it reliably meets that bar across those cases.