{
  "uid": "cogitave.learn.understand-yuva.how-yuva-is-verified",
  "kind": "moduleUnit",
  "href": "/modules/understand-yuva/how-yuva-is-verified/",
  "title": "What \"verified\" actually means",
  "summary": "",
  "type": null,
  "products": [],
  "roles": [],
  "levels": [],
  "subjects": [],
  "headings": [
    "1. Unsafe code is confined, not avoided",
    "2. Selected leaves are formally proved",
    "3. It boots two architectures on every push",
    "4. The boot fails closed",
    "5. It states what is not working"
  ],
  "source": "\"Verified\" is a word that gets used loosely. This unit is about what it means\nconcretely in Yuva, so you can judge the claim rather than take it.\n\n## 1. Unsafe code is confined, not avoided\n\nYuva is `no_std` Rust with **zero `unsafe` blocks above one audited HAL crate**.\nA kernel cannot avoid unsafe code entirely — it talks to hardware. What it can do\nis put all of it in one place.\n\nThe distinction matters because auditing is a human activity with a budget. Unsafe\ncode spread across a codebase cannot be reviewed as a unit; unsafe code confined\nto a single hardware-abstraction crate can be, and re-reviewed whenever it changes.\n\n## 2. Selected leaves are formally proved\n\nSome components are proved with **Kani**, a model checker for Rust: rather than\ntesting a sample of inputs, it explores the state space to show a property holds\nfor all of them.\n\nTwo details make this more than a badge:\n\n- The proof set covers **leaves** — small, self-contained components — because\n  that is where model checking is tractable. Nobody proves a whole kernel.\n- **The harness counts are pinned in CI.** If a proof disappears, the build fails.\n  A verification claim that can silently shrink is not a claim.\n\n## 3. It boots two architectures on every push\n\n`x86_64` and `aarch64`, on every commit. Portability that is not exercised is\nportability that has already broken; the only honest way to claim it is to run it\ncontinuously.\n\n## 4. The boot fails closed\n\nThis is the property worth internalizing.\n\nYuva does not report a successful boot unless the **full cumulative self-test\nmarker chain** prints over serial. A missing marker is a failed boot — not a\nwarning, not a degraded mode, not a log line somebody notices next week.\n\n| | Fail-open | Fail-closed |\n| --- | --- | --- |\n| A check does not run | Boot succeeds anyway | Boot fails |\n| A guarantee is unproven | Assumed to hold | Treated as broken |\n| Who notices | Whoever is paged later | CI, immediately |\n\nFail-open systems accumulate silent gaps: each individually looks like a small\nmissing check, and together they mean nobody knows what is actually enforced.\n\n## 5. It states what is not working\n\nYuva reports **honesty tokens** over serial — uppercase status markers that say\nwhich capabilities are not live. Today they say live inference is MOCK and\nlearning is DORMANT because a gate has not been met.\n\nThis is an engineering practice, not modesty. A system that reports only its\nsuccesses cannot be reasoned about, and a status page that never says NO is not\ntelling you anything. The tokens are also the signal to watch: they change when\nthe gate is met.\n\n> [!TIP]\n> When you assess any platform's verification claim, ask the four questions this\n> unit answers: where is the unsafe code, what exactly is proved, can the proof\n> set shrink without anyone noticing, and what happens when a check does not run.\n",
  "partOf": "cogitave.learn.understand-yuva",
  "durationInMinutes": 6,
  "quiz": null
}