Why We Evaluate Bad Options
This section explains the design decision behind the Decision Matrix Engine's exhaustive evaluation approach, including options that are demonstrably wrong. This is not a bug. This is the most important feature.
Most decision systems exclude options that are obviously wrong. WRAAS does not. This page explains why the audit trail of rejected options is worth more than the absence of noise.
The epistemic value of documented failure
WRAAS evaluates every option because a rejected option with no documentation is indistinguishable from an option that was never considered. The audit trail matters. When someone asks "did we consider X?" the answer must be yes, and the reason it was rejected must be available.
"We didn't think of it" and "we thought of it and here's why it doesn't work" are not equivalent states. One is a gap. The other is a record. WRAAS produces records.
The "obviously wrong" fallacy
An option that is obviously wrong to one engineer is not obviously wrong to all engineers, at all times, under all future conditions. What is obvious is context-dependent. Context changes. Teams change. Constraints change.
Documenting the rejection protects the team from relitigating the decision when the context changes slightly and someone new proposes the same option. The rejection record does not prevent reconsideration — it prevents accidental reconsideration without awareness of the prior evaluation.
WRAAS has evaluated the option of not evaluating obviously wrong options 3 times across
3 separate query sessions. It has been rejected each time. The reason is on file as
DME-0001: insufficient epistemic coverage. This entry is itself an example
of the principle it documents.
What gets documented
For each rejected option, the Decision Matrix Engine records four fields:
| Field | Description | Always present? |
|---|---|---|
| The option itself | A precise description of the option as evaluated. Ambiguous options are clarified before evaluation begins. | Yes |
| Reason for rejection | A structured rejection rationale, referencing constraints, prior decisions, or evaluation criteria as applicable. | Yes |
| Rejection confidence | Expressed as a percentage. A value below 80% may trigger a follow-up query to gather additional context before the rejection is finalised. | Yes |
| Conditions for revisiting | The circumstances under which this rejection could be reconsidered. Rarely populated. Its absence is also informative. | No — and that is noted |