Postcondition verification

After acting, JARVIS checks that the result actually happened.

TESTED , rung 3 of 8 Recorded 6 August 2026

Technical

What it is

Postcondition verification: observed state is compared with the requested state before an action is reported as done.

Truth ladder

Rung 3 of 8: TESTED

Automated tests exercise it in isolation, often against fixtures.

Project record: IMPLEMENTED

CONCEPT Designed or specified. No working code yet.
IMPLEMENTED Code exists. Nothing has demonstrated that it behaves correctly.
TESTED Automated tests exercise it in isolation, often against fixtures.
INTEGRATED Wired into the rest of JARVIS and tested across component boundaries.
PRODUCTION-REACHABLE The owner can reach it through the real runtime path, not only through a test harness.
LIVE-PROVEN A bounded probe ran the real code path on a booted JARVIS on the real machine and recorded evidence. The project treats live evidence as expiring after 24 hours, so every live reading here shows the date it was taken.
FORMALLY VERIFIED Its critical property is checked by a proof or exhaustive verification.
RELEASE-QUALIFIED Passed every qualification gate for a named release.

Limits

A probe of the real code path passed and wrote evidence (2026-08-06), but it did not demonstrate a booted process on a real port, so the project itself refuses to call it LIVE.

Record

Only states recorded in the public export are listed. Earlier states may exist in the project’s private ledgers.

Connected work

Neighbours