Runtime health truth
Checks fresh heartbeats, dependencies and usable capability instead of trusting a stored online or healthy flag.
VERIFIED CORETRUTH LAYER · BOUNDED DELIVERY
AX-VERIFY
Your system can be green and still be wrong.
AX-VERIFY checks concrete claims about agents, workers, tools and workflows against fresh evidence. It separates process success from outcome success and leaves unsupported claims explicitly unknown.
CLAIMOBSERVETESTVERDICTNEXT ACTION
WHAT AX-VERIFY CHECKS
Concrete claims, not dashboard confidence.
AX-VERIFY is designed for bounded questions where the difference between declared state and observed outcome matters.
Capability proof
Tests whether a declared capability is actually available and whether the requested outcome can be observed.
Duplicate writers
Looks for competing workers, split ownership and multiple writers where the system assumes one authority.
Process vs outcome
Separates a successful command, tool call or workflow exit from evidence that the useful result became true.
Authority boundaries
Checks the scoped path against permission, owner-gate and read-only boundaries relevant to the claim.
Recovery evidence
Checks whether known-good state, rollback identity and post-recovery readback support the recovery claim.
VERIFICATION SNAPSHOT
What was declared. What was observed. What the evidence supports.
A bounded AX-VERIFY review returns a compact verification snapshot rather than an unqualified "looks good".
Evidence-backed verdicts.
Each scoped claim stays tied to the evidence window that produced it. Anything outside that evidence remains unverified.
Verdict language: PASS, WARN, FAIL, NOT TESTED or UNKNOWN.
CLAIMThe exact state or behavior being checked.
DECLAREDWhat the system, logs or operator says is true.
OBSERVEDFresh runtime, readback or independently checkable evidence.
VERDICTThe result supported by the scoped evidence.
EVIDENCEWhy the verdict exists and what can be reproduced.
NEXT ACTIONThe smallest safe remediation and how to verify it.
LIMITSWhat this test did not prove.
REAL AXIOM EVIDENCE
Verification used on AXIOM itself.
The public Proof page contains bounded internal cases. These are evidence examples, not customer case studies.
Healthy on paper. Database unavailable.
Management health remained positive while PostgreSQL was unreachable. AXIOM treated management-plane health as insufficient proof of database availability.
Read P-01 on Proof →Backup is not proof until restore works.
CoreDB persistence restart, backup creation and disposable restore all passed inside the bounded local recovery scope.
Read P-02 on Proof →Declared capacity was not fresh capacity.
A Highway stress audit surfaced stale-heartbeat evidence and unavailable matching capability instead of accepting declarations at face value.
Read P-03 on Proof →BOUNDARIES
Evidence-first, not surveillance.
Verification is scoped before testing. AX-VERIFY does not turn a bounded review into a broader security or compliance claim.
01No secret collection in the report.
02No destructive testing by default.
03No production-changing action without explicit approval.
04No penetration-test or compliance-certification claim.
05No claim of full-system security from a bounded evidence window.
06Your system remains your authority. AX-VERIFY reports findings, evidence, limits and next actions.
CURRENT MATURITY
Verified core. Bounded customer-facing delivery.
Core verification patterns have working evidence. The customer-facing surface is being introduced through scoped engagements rather than claiming full self-serve SaaS readiness.