Evidence

Governed calibration on pypa/packaging

Governed calibration on a mirror of pypa/packaging, and the historical Astronomy Shop campaign that came before.

evidence · calibration · ratchet

Originally published

Article history

No released revision history is available for this article. The original publication date is preserved; no revision events are implied. Any editorial clarification in the article is separate from admitted revision history.

HISTORICAL ACCOUNT - CALIBRATION LANE AND HISTORICAL FEASIBILITY.
Nothing on this page claims production custody of any external system.

Apex has completed governed calibration on a private, governed mirror of software it does not own - no outside custody is claimed - according to its retained calibration account. The public signed projection reports a bounded result; primary receipts are not public. Its integrity can be checked locally, but this page does not reproduce the underlying evaluation.

This is a historical account, not a live feed. New claims require source evidence and a separate disclosure decision.

Packaging - calibration lane

The target is pypa/packaging, the library behind Python's version and dependency semantics, run as a private governed mirror. Apex has completed governed calibration against the dimension evaluator:

  • The earlier run floored operations.retry_bound.evidence summary
  • The signed summary records performance.nesting_ceiling from FAIL to PASS while naming 11 protected dimensions.evidence summaryWhat this does not proveThe public projection is a signed summary. Its signature check does not rerun the acceptance verdict.Public trailSigned summary ↗
  • Target-native test result in the signed summary: the packaging test suite itself - 26,854 passed, zero failures, errors or skips.evidence summaryThe suite is the target's own pytest suite, run unmodified. Apex did not write the test it is judged by.
  • The fresh-clone check is a same-engine re-evaluation, recorded privately: it re-derived the evaluation digest and the recorded verdicts from committed inputs. It is not independent verification.evidence summaryWhat this does not proveThe fresh-clone replay is reported in a private record; a visitor cannot reproduce it from this page alone.Public trailReplay / evidence record ↗
  • The signed projection records authorityState AUTHORITATIVE and verdict COMPLETED; floor ADMITTED; acceptance PASS. It does not name a person. The public projection is signed; no signature over the private primary receipts is supplied here. Its acceptance field does not establish native Apex Review ACCEPT.Public artifact integrity and the authority of a private acceptance decision are separate questions.
$ apex cycles --target pypa/packaginglane: development_only (calibration)
earlier run
[sealed]floor raised: operations.retry_bound
later run [sealed]nesting_ceiling FAIL→PASS · 11 protected dimensions listed
replay [private]same-engine re-evaluation · recorded verdicts (private record)
Try it here / calibration laneWalk through the signed summaryREPLAY, not a live Apex run. Governed calibration on a private pypa/packaging mirror; development-only calibration receipts.
apex · public proof runtime
Ask about the public record. Answers are bounded by indexed sources.
$
Development artifact / diagramA governed cycleSource: Existing Apex calibration-lane loop diagram, backed by the evidence page

Propose. Set rules. Test. Decide. Carry forward.

Apex is designed to keep the author separate from the checks. Apex is designed so a person makes the acceptance decision. Stateful design aims to retain accepted requirements for later checks. A calibration cycle is a development-only test run, not a customer system. The signed calibration summary illustrates carrying requirements forward, not unattended or perpetual operation.

Propose
A limited code change is proposed on a development-only test target.
signed summary / development-only test
→
Bound
Minimum requirements (floors) are set before the change is tested.
11 protected dimensions
→
Verify
The target's own tests run; the Apex evaluator measures its own floors.
The target's own tests: all passed, none failed
→
Decision
Apex is designed so a person makes the acceptance decision. The signed projection records acceptance PASS and does not name a person.
signed verdict; no person named
→
Carry forward
In the intended workflow, prior requirements are checked before a later change is accepted.
11 protected dimensions listed

↺ design goal: recheck prior requirements

Historical results above are drawn from the public signed calibration summary: governed calibration completed on a private mirror of pypa/packaging, calibration lane, development-only receipts. Carry-forward describes the intended workflow, not a guarantee for future runs. Inspect the evidence →

Development artifact / schemaPublished signed-projection fieldsSource: /evidence/signed-projection-2026-09-11.json (field names only; not a database schema)
sourceRevision : string
baseline       : string
targetDimension: string
beforeAfter    : { before: string; after: string }
protectedDimensions: string[]
nativeTestResult: string
evidenceDigest : string
verdict        : string
authorityState : string
lane           : string
freshness      : string
timestamp      : string
signature      : string

What this is: a calibration lane. The receipts are marked development-only. The public summary reports a bounded result, not independent reproduction of the floor and ratchet machinery. These records are not a sealed fix of a real production deficiency, and they are not custody of anything.

Astronomy Shop - historical feasibility

The OpenTelemetry Astronomy Shop, a deliberately messy microservices demo, was Apex's initial external target. Early campaigns exercised the full campaign loop - observation, proposal, evaluation, gated acceptance - against a live distributed system. We classify those runs as historical feasibility evidence: genuinely informative about the machinery, not yet a reproducible public proof campaign. Whether Astronomy Shop becomes an accepted public proof, or stays demoted to history, is an open decision. We will document the outcome here.

Receipts and repositories

The underlying receipts, governed mirrors, replay tooling and full evaluation records remain private. No authorized access procedure is established here; a future disclosure would require separate authorization.

Apex · Pilot reviewDIRECTION

What a pilot review is meant to look like

The shape we are working toward. Pilot intake is not open yet.

Your repository
Separate review workspace
source, tests, history
Apex evaluates
bounded candidate changesagainst your own tests
independent verification
Evidence package
You decide: accept / reject / inspect
DIRECTION: the intended shape of a pilot review, not a current offering. No customer pilot has run.