ADR-010: Unknown Equals Error — Strict Verification
Context
When the compiler encounters a construct it cannot fully analyze — an opaque expression, an unsupported pattern, a guard beyond the current abstract domain — it must decide what to do.
| Option | User experience | Safety |
|---|---|---|
| Warn and continue | No interruption | False sense of security |
| Silently skip the check | No interruption | No guarantee whatsoever |
| Treat unknown as error | Compilation fails | No false positives |
Source: CLAUDE.md “Conventions” section — “Unknown = error. The compiler never silently
succeeds when it cannot verify.”
Decision
Unknown equals error. If a check cannot be performed because the input is outside the analyzable domain, the compiler reports an error rather than assuming correctness.
This applies uniformly: opaque expressions in guards, constructs not yet covered by validation rules, and any case where the compiler would otherwise make an optimistic assumption.
Escape hatches for advanced use cases (e.g., explicitly marking a block as unchecked)
are deferred and must be explicitly designed — they are not implicit.
Consequences
Positive
- No false sense of security: if the compiler reports “valid,” it means it verified the claim, not that it gave up.
- Forces language evolution: every construct must be made analyzable or explicitly scoped out. There is no drift by neglect.
- Users can trust compiler output unconditionally within the analyzed subset.
Negative
- May reject valid programs that the compiler cannot yet analyze. The analyzable subset grows incrementally with compiler development.
- More conservative than typical compilers; some users will find the strictness surprising before escape hatch mechanisms are available.