Separate model judgment from deterministic calculation

A score can be calculated perfectly from uncertain inputs. The arithmetic repeats exactly, the output contains several decimal places and the conclusion still depends on a judgment that nobody has established. This is a common problem when an agent is asked to evaluate the value of a feature before people have used it.

In March, I asked for a creation-time evaluation method that separated measurable properties from inference. I specifically rejected speculative proxies presented as objective facts. The subsequent design request put variable assessment in prompts and the arithmetic in the Rust programming language, with ranges and examples explaining how to supply each input.

That is evidence of a requested architecture. It does not establish that the resulting score objectively measures value or that the claimed code artifact was compiled and validated. The distinction matters because deterministic calculation can improve consistency without resolving uncertainty about what should be calculated.

Two inputs with different evidence

Consider an illustrative feature review with two inputs. One is whether a saved export can be reopened successfully. That can be checked against an artifact. The other is how important the export feature will be to a particular group of readers. That requires evidence about their work and may remain an estimate before use.

Do not store both values as unexplained numbers. Preserve the observed test result with its artifact and record the importance estimate with its rationale, source and uncertainty. A later reviewer should be able to change the estimate without pretending that the export test has changed.

The model can help interpret descriptions and map them to a defined scale. The application should reject an out-of-range value or a missing required explanation. It should also distinguish “unknown” from zero, because missing evidence is not evidence that the feature has no value.

What the program can establish

A deterministic function performs the same operation on the same inputs. It can check types, enforce valid ranges and return a result with the formula version. These are useful properties because the model does not need to improvise arithmetic during every review.

The function cannot establish that the supplied importance rating is correct. If the model gives an unsupported high rating, the program can calculate faithfully and still produce a misleading recommendation. Input review therefore remains part of the evaluation rather than disappearing after the formula is implemented.

For the illustrative review, test boundary values, absent values and malformed inputs. Keep examples where a reviewer expects the calculation to refuse a result. A program that always returns a score can conceal uncertainty more effectively than one that explicitly reports which required input remains unsupported.

Keep the prompts used to elicit the values with the calculation record, because changing the explanation of a scale can change the model’s answers even when the accepted numeric range and arithmetic remain exactly the same. If two reviewers assign different importance estimates, preserve their reasons and rerun the conditional calculation for both values before deciding whether the disagreement requires more evidence about the intended readers or simply clearer assessment instructions.

When the estimate changes the recommendation

Suppose two plausible importance estimates produce different recommendations. Report that sensitivity. The decision depends on the estimate, and further evidence about the intended users may be more valuable than another decimal place in the calculation.

If the recommendation stays the same across a reasonable range, that is useful too, but its scope remains conditional on the formula and the range examined. It does not convert the estimate into a measured fact.

A review record should preserve the feature version, observed inputs, inferred inputs, calculation version and any unresolved evidence. That makes it possible to revise the assessment when a real user test or implementation change supplies better information.

The final export review might establish that the file reopens correctly while leaving expected importance uncertain. Keep those conclusions separate in the saved record. A later evaluation can update the importance estimate from observed use and rerun the same calculation without rewriting the earlier artifact test as though it had answered a question about demand.

Source notes

Drew Wiberg, feature-evaluation requirements and prompted-variable/Rust calculation design, 21 March 2026. The requested architecture does not establish an objective measure of user value.

Worked examples and review procedures in this article are instructional applications, not additional historical project results.