The proof file / capabilities and limits
What has Apex shown?Separate the change from the decision.
Apex is being built to check proposed code changes against rules set in advance. Apex is designed so a person makes the acceptance decision. Accepted requirements are meant to carry into the next change. The strongest outcome shown here is development-only calibration on a private copy of pypa/packaging. Other entries describe implemented parts or historical feasibility, not customer results.
The author does not decide whether its own change passes
Apex has an implemented path separating the author of a change from the acceptance checks. The author's success message is not the acceptance decision.
FACT-BOUNDED / implemented parts, not a public run receipt. A stronger guarantee was withdrawn; see the limitation below.
The tests must check the changed code
Packaging calibration uncovered tests running against an installed package rather than the code being evaluated. A check was added to require the tested source to match the evaluated source.
FACT-BOUNDED / calibration finding and implemented check. This is not a customer result.
Incomplete evidence must stop the decision
A packaging run timed out while gathering evidence. The response was changed to stop that path rather than draw a favourable conclusion from an incomplete record.
FACT-BOUNDED / implemented response to a calibration failure, not a guarantee for every future run.
An improvement can become a requirement for the next change
A floor is a measurable minimum that future changes must keep meeting. The public signed projection names 11 protected dimensions and records floor ADMITTED. Reversal checks are reported in the private calibration account; the projection does not independently reproduce them.
FACT-BOUNDED / the signed calibration summary. The signed public summary is available on the evidence page; primary run receipts remain private.
A failing test can define a repair target
Apex has an implemented path for treating an existing failing regression test as a potential repair target. An implementation is not a completed repair.
FACT-BOUNDED / implemented path only. No sealed fix of a real outside defect is established here.
The intended output is evidence, not a success message
The design calls for comparing a measured failure with a checked candidate result, then recording the acceptance decision. Parts of that path are implemented, but a complete, independently repeatable outside-defect repair is not shown here.
DIRECTION / intended full outcome. Implemented parts do not prove that outcome has been completed.
Running software needs evidence beyond source code
A historical Astronomy Shop test explored connecting a code change to the software actually running and observing its behaviour within a limited window.
FACT-BOUNDED / historical feasibility only. Not current production acceptance or a customer installation.
A separate check can inspect retained runtime evidence
The historical Astronomy Shop work includes a separate verifier for the retained observation record. It checks the record and its stated bindings; that does not establish a customer deployment.
FACT-BOUNDED / historical verification path. No unverified test count is claimed.
Apex is preparing to test changes to itself
An implemented path can identify and separately check potential repair targets in Apex itself. Crediting a repair still needs evidence of the completed work and its delivery.
DIRECTION / self-improvement. No completed self-repair outcome or customer authority is claimed here.
Progress must not mean unlimited complexity
Apex has a recorded complexity limit for a specified development tree and a comparison that rejects a measurement above that limit when the record and procedure match.
FACT-BOUNDED / scoped development check. No completed self-repair or production authority is claimed.
A stronger claim was withdrawn
An earlier proposed guarantee about binding evidence to a file did not survive hostile review. That guarantee remains withdrawn. Implemented acceptance checks should not be read as proof of that stronger claim.
Claims belong here only within the evidence they can support. A code change landing is not the same as a completed run proving the result.
What the evidence does not establish
No indefinite operation or hard-to-copy advantage is proved today. The calibration record does not establish general performance across customer codebases. The public signed record is a summary: checking its signature does not rerun or validate the acceptance decision.
The full underlying run receipts remain private and not publicly accessible; access requires separate authorization. This page shows capabilities and limits, not the private implementation.
Explore the historical record and challenge a local copy →
Explore the Observatory foundation, with no released event history →