Good systems reduce ambiguity before they ask for more intelligence

Most systems spend their intelligence on questions the system could already answer. Which file owns this concept, which rule applies here, whether this result is acceptable. When that context is missing, every run rebuilds it from scratch and every rebuild is a chance to drift.

That is the part of AI-assisted engineering that gets underestimated. A model that writes the wrong code is a visible failure. A system that makes the right context impossible to find produces wrong code that looks reasonable, which is harder to catch and more expensive to unwind.

Answer the known questions deterministically

If the answer is known and stable, encode it. A path, an identifier, a policy, a documented convention. Deterministic mechanisms are cheap, inspectable, and identical every time they run.

There is a resource argument here as well as a design one. Probabilistic reasoning is expensive and variable. Spending it to rediscover something the system already knows adds cost without adding capability.

A useful test for whether something belongs in this layer: would two competent people, given the same inputs, give the same answer? If yes, it can be a rule. If no, it is a judgment call that needs a different mechanism.

Keep judgment where the input is genuinely open

A good system does not push everything into rules. Ambiguous intent, synthesis across sources, and cases the rules do not cover still need judgment, from a model or a person. Refusing to use it there produces brittle software.

The design work is deciding where the boundary sits and what happens at the edges. A system that never defers breaks on novel input. A system that always defers never becomes predictable.

On ocalendar, an event with a missing venue or an ambiguous date needed a person. A clean event did not. Mapping that boundary did more for data quality than any single extraction rule. The automation handled the repeatable path and the person handled the exception, and both were explicit in the workflow.

The boundary makes failures legible

Once the split is explicit, failures get easier to read. When a rule is deterministic, a violation is a bug with a cause. When a decision is probabilistic, a bad result is a distribution, and it needs thresholds, evaluation, and fallbacks.

Mixing the two hides the difference. A wrong output looks the same whether a policy was violated or a model made a reasonable call on ambiguous input.

This is also where evaluation stops being optional. If a step is deterministic, you test it. If a step is probabilistic, you set a threshold, measure against a set of known cases, and define what happens when the result is not good enough. A validation gate is not bureaucracy; it is the thing that separates a finished run from a correct result.

What it changes day to day

The order matters. In practice it means asking, for each step of a workflow: is this a known question or an open one, who decides, and how would I notice a bad answer?

Kyros applies that order to engineering work itself: canonical context, explicit workflows, validation gates, and recovery paths. The approach page covers the decision model behind it.