Knowledge check

Check your knowledge

Choose an answer to see why it is right or wrong.

JavaScript is off, so every explanation is shown at once.

1. 01Why does Cogitave build its own kernel instead of running agents on an existing operating system?

   • Because an isolation or audit guarantee is only as strong as the layer enforcing it, and a rented layer cannot be verified or attested to.Correct. If you do not control the enforcing layer, every guarantee above it is an assumption about somebody else's system.
   • Because writing a kernel is faster than configuring an existing one.Incorrect, and nobody claims it. Building a kernel is the expensive path; it is chosen for what it makes verifiable, not for speed.
   • Because existing operating systems cannot run TypeScript.Incorrect. They run TypeScript perfectly well - that is exactly how Namzu runs today, on Node.

2. 02Yuva has zero unsafe blocks above one audited HAL crate. Why is confinement the goal rather than elimination?

   • A kernel must talk to hardware, so some unsafe code is unavoidable - but confined to one crate it can be reviewed as a unit and re-reviewed when it changes.Correct. Auditing has a budget. Unsafe code spread through a codebase cannot be reviewed as a whole; unsafe code in one place can.
   • Unsafe code is faster, so the kernel keeps as much of it as possible.Incorrect. The design minimises and isolates unsafe code; it is a review-surface decision, not a performance one.
   • It is eliminated entirely - there is no unsafe code anywhere in Yuva.Incorrect, and the project does not claim it. One audited HAL crate contains it.

3. 03Yuva pins its Kani harness counts in CI. What does that pin buy?

   • The proof set cannot silently shrink - if a verification disappears, the build fails.Correct. A verification claim that can quietly get smaller is not a claim; the pin is what makes it hold over time.
   • It makes the proofs run faster.Incorrect. The pin is about coverage not regressing, not about speed.
   • It proves the entire kernel is correct.Incorrect. Selected leaves are proved, because that is where model checking is tractable. Nobody proves a whole kernel.

4. 04Yuva's boot does not report success unless the full self-test marker chain prints. Why does that matter?

   • It fails closed: a check that does not run is treated as a broken guarantee rather than an assumed one, so gaps surface in CI instead of accumulating silently.Correct. Fail-open systems collect small missing checks until nobody knows what is actually enforced.
   • It makes the boot faster by skipping checks that are not needed.Incorrect. The opposite: no check may be skipped, and a missing marker is a failure.
   • It lets the kernel boot in a degraded mode when a check fails.Incorrect. There is no degraded success. A missing marker is a failed boot.

5. 05Yuva's status tokens currently report that live inference is MOCK and learning is DORMANT. How should you read that?

   • Literally. Yuva cannot host an agent workload today, and the tokens are the signal that changes when it can.Correct. A system that reports only its successes cannot be reasoned about. Take the tokens at face value and use Namzu on Node to run agents now.
   • As a conservative disclaimer - inference works in practice.Incorrect. The tokens are a factual status report, not legal caution. MOCK means mock.
   • As a sign the project is abandoned.Incorrect. The kernel boots on two architectures on every push. The tokens report which capabilities are gated, not that work has stopped.