# annotations are never checked **Status: verified on `experiment/annotation-checking`, not merged.** ## Ishikawa — why does El silently miscompile? Three bugs found the same day shared one shape. ``` method type tracked by per-function name sets, fed from annotations machine el_val_t erases everything at the C boundary material no propagation through expressions measurement nothing verifies an annotation against what it annotates ───────────────────────────────────────────────────────────────────────── root cause El has type ANNOTATIONS but no type CHECKING. The annotation feeds dispatch and is never itself verified. ``` ## Predictions ``` P1 let x: Int = "hello" compiles clean expect TRUE P2 let s: String = 42 compiles clean expect TRUE P3 the annotation drives dispatch, unverified expect TRUE P4 same root cause as all three bugs found today expect TRUE P5 checking literal-vs-annotation catches both expect TRUE P6 zero false positives across the compiler's source expect TRUE ``` ## Results — 6/6, and worse than a wrong answer ``` let x: Int = "hello"; x + 1 → 4343631981 a string POINTER used as an integer let s: String = 42; println(s) → nothing address 42 dereferenced as a string ``` The first **leaks a raw memory address into program output**. The second is an **arbitrary-read primitive** if that integer is ever attacker-influenced. Verified: 6/6, zero false positives across the compiler's own source, fixpoint ok, 105/105 native. ## Six Sigma The emitter only **records** the mismatch; `tools/check/annotations.sh` decides — consistent with every other check. Literals are checked because they are unambiguous. **Incomplete, stated not hidden:** only literals. `let x: Int = some_string_fn()` still passes, because `signatures.rel` carries Int/Instant/Duration and no String entries. That is a data gap, not a capability limit — every El function declares its return type in source and codegen already holds `ret_type` on every `FnDef`.