The public capability list on this site shows a small number of LIVE-PROVEN entries and a much larger number of TESTED and IMPLEMENTED ones. People who follow the project sometimes notice that the LIVE count used to be much higher. On 28 July 2026 the build ledger recorded 256 of 341 capabilities as LIVE. On 17 September the registry recorded 9. This entry explains that drop. In short, the project decided that most of its earlier LIVE claims did not prove what the word said, and it gave the word a stricter meaning.
The rule that defines LIVE
The capability registry (docs/ledger/CAPABILITY_TRUTH.json) carries its own definition, and it is worth reading in full:
“Within the last 24 hours a bounded probe executed the real registered code path against a real booted JARVIS process on a real port, using real (or verified-clone) stores, returned the correct result, touched no test double, and wrote an evidence artifact that exists on disk.”
Each clause excludes something specific. “Real booted JARVIS process on a real port” excludes in-process calls and unit tests. “Touched no test double” excludes mocks, and the registry enforces this with an is_test_double flag on every adapter: a probe whose call graph touched a double can produce IMPLEMENTED at most. “Within the last 24 hours” means LIVE expires. A state older than a day decays to NOT_PROBED_THIS_PASS.
The constitution also lists what does not count as LIVE proof. Code that exists, imports that succeed, a passing unit test, a mock that returned success, a registered route, a present API key, “it worked last week”, a subagent’s report and someone’s confidence are all excluded.
How 256 became 9
The build ledger (docs/ledger/BUILD_STATE.json, field capabilities_live) records the count each time a commit rewrote it. The values below are the recorded ones. Each was written by a named commit.
| Date | LIVE | Registered | Commit that wrote it |
|---|---|---|---|
| 2026-07-28 | 75 | 304 | 01ed5c7b8 |
| 2026-07-28 | 256 | 341 | 4e70347c7 |
| 2026-07-29 | 153 | 341 | 918420e6f |
| 2026-08-06 | 145 | 341 | dcd7b6ef3 |
| 2026-08-06 | 18 | 341 | c2e0b128a |
| 2026-08-07 | 24 | 341 | ad616aed1 |
| 2026-09-06 | 21 | 341 | fcc7df48f |
| 2026-09-09 | 9 | 341 | ed77b2af5 |
| 2026-09-20 | 9 | 342 | 2ea210950 |
Two events explain most of the fall.
First, AUDIT 03 at the end of July asked a question the earlier readings had skipped: does any production entry point actually construct this code? It demoted 70 capabilities, then 20 more in a cascade, because nothing a real owner could do would reach them. “Reachable from a real entry point” became a precondition for LIVE.
Second, on 6 August the evidence rule itself was tightened. The ledger’s own note says LIVE must be reached “by asking the process, not by proximity”. An earlier probe could pass by exercising code near the registered path, or in the same process as the test. After the change, the probe had to ask the booted process and get the answer back. The registry records its demotions from LIVE on 108 entries, all stamped 2026-08-06T04:59:07Z: 99 moved to IMPLEMENTED and 9 to BLOCKED. That is the step from 145 to 18 on the same day.
After that, the count drifted between 9 and 24 as capabilities were probed, decayed and re-probed. The 24-hour window means the number can only stay up if probes keep running.
The nine
On 17 September, between 22:33 and 22:35 UTC, bounded health-route probes against booted processes on loopback diagnostic ports recorded these nine as LIVE:
- the async event bus, correlation IDs across every surface, redacted logging, health and readiness probes, and the loopback-only binding assertion (
CAP-RT-02/03/06/07/17); - the fail-closed policy engine, the E-stop and the prompt-injection detector (
CAP-GOV-01/05/11); - units and dimensional analysis with unit-error rejection (
CAP-ENG-01).
Most of them are infrastructure and safety. That follows from the rule. They are the capabilities a probe can exercise on a booted process without opening a window on the owner’s screen, starting a camera or sending anything outside the machine. Opening and closing applications, for example, is deliberately not live-probed by the registry, because the probe would change the owner’s screen.
The critical-path scoreboard for that pass (docs/ledger/CRITICAL_PATH.md) records “9 / 341” with the oldest LIVE evidence 0.06 hours old and a decay margin of about 23.9 hours. By 22 September that margin was gone. On this site those nine are shown as LIVE-PROVEN with the date of the reading, which is how the site treats every live claim.
Where the other 333 stand
Registry state counts at the current production head are: IMPLEMENTED 248, BLOCKED 47, NOT_IMPLEMENTED 21, NOT_PROBED_THIS_PASS 16, LIVE 9 and READY 1. The IMPLEMENTED group is not one thing. It includes 153 entries whose probe passed and wrote evidence but did not show a booted process on a real port, 52 that AUDIT 03 found unreachable, and 15 demoted in the cascade.
Across the registry, 256 probes are recorded as passing, 3 as failing and 83 have no probe. No passing probe touched a test double. The passing-probe count happens to equal the 28 July LIVE count. Nothing shows that they are the same 256 rows. The project’s own method file warns that “adjacency in time is not relation”, and this entry does not claim a link.
The site maps these states onto its own ladder conservatively. An IMPLEMENTED row with a passing probe becomes TESTED. An IMPLEMENTED row demoted for reachability stays IMPLEMENTED. A failing probe becomes PARTIAL.
What the registry does not capture
The registry is one instrument among several, and the site keeps them apart. The interaction capability model of 16 September drove desktop, browser, files, research, missions and the HUD live on the owner’s machine and classified those categories PROVEN_LIVE. Fourteen of sixteen post-LM acceptance journeys are recorded LIVE_VERIFIED. Neither of those results is in the registry’s LIVE count, because they were not produced by the registry’s own probes.
The registry has also not caught up with September. Its states were last set on 19 September. Many engineering rows still carry BLOCKED reasons written in late July that the project later corrected. Large pieces of September body work, such as document intelligence and application identity, are not reflected in any registry row. Whether a regenerated registry would promote them is uncertain.
Why keep a number this small
A LIVE count of 256 looked better. It also claimed that 256 capabilities had been shown working on a booted system, and most of them had not. The project chose to publish a number it can defend line by line. A count of nine is less flattering, but each of the nine points to a probe, a port, a timestamp and an artifact on disk. Once a reading is older than a day, the project treats it as history, and so does this site.