APEX
Menu

Apex / a system in development

Bounded perpetual software.

Apex is being built to understand a codebase, discover worthwhile improvements and evolve software within customer-defined rules, authority and evidence requirements.

For teams that want software to keep improving while retaining control over what may change, why and under whose authority.

Where it stands: implemented components and a signed calibration record on a private test copy of pypa/packaging. The complete system remains a design direction. No customer deployment yet.

Why it matters: the intended model keeps software understanding and accepted requirements available for later changes. If independently demonstrated, improvement could compound instead of starting from lost context.

Read the investor brief → · Inspect the historical evidence →

Understand the complete system →

Optional exploration: the illustrative Lab →

CapabilitiesWhat is working, what is partial, and what is still roadmap. Internal audit, not public proof.

The thesis is stronger than today's proof.

Cycle 2, performance.nesting_ceiling FAIL to PASS, 11 protected dimensions, 26,854 passed / 0 failed, frozen 2026-09-11.

Follow the indexed entries to public pages and stated limits. The current signed record is from a calibration run, not a customer deployment; its signature check does not rerun the verdict.

Check the signed summary yourself

Inspect the claims and their limits →

Evaluating Apex? Early access status →

Design direction / the connected system

Understand. Improve. Carry the learning forward.

Bounded perpetual software is the goal: an ongoing process of learning and improvement, constrained by a customer's constitution, workflows and permission to act. Governance and verification belong within that system. They are not its entire purpose.

  1. Intelligence

    Build a grounded picture of the software and its constraints.

  2. Discovery

    Identify real defects, gaps and opportunities worth improving.

  3. Constitution

    Use the customer's constitution to bound change and authority.

  4. Governed change

    Produce narrowly scoped changes within allowed operations.

  5. Independent acceptance

    Keep proposed changes separate from checks and acceptance evidence.

  6. Compounding memory

    Keep accepted requirements and their evidence for later changes.

In the design, independent evaluation tests a bounded change against the customer's requirements. Passing checks does not grant authority to act. Apex is designed so a person makes the acceptance decision. Accepted improvements and their evidence become obligations for future evolution, rather than knowledge lost after a change.

This is the proposed architecture, not a demonstrated end-to-end intelligence or perpetual operation outcome. See the implemented components and their limits, then inspect the bounded public calibration record.

Why it compounds

A recorded gain. An intended ratchet.

The ratchet (carrying minimum requirements forward) asks more than "does this pass today's tests?" It asks whether a candidate preserves everything this system has already earned the right to depend upon. The signed calibration summary records performance.nesting_ceiling moving from FAIL to PASS. The recorded result is a bounded demonstration, not a guarantee for future runs. The dashed extension is a design goal, not another recorded cycle.

startCycle 2.+ FAIL→PASS11 protected dimensionsintended future checkprotected floors

Drawn from the signed calibration summary: performance.nesting_ceiling went from FAIL to PASS; it names 11 protected dimensions. Calibration lane, development-only receipts. Check the signed summary yourself · Inspect the evidence →

Capabilities, with limits

Proof, not positioning.

These cards distinguish implemented parts from demonstrated outcomes. Flip for the scope and limits; read more on the proof page.

Separate acceptanceThe author does not supply its own pass/fail decision.An implemented path separates the change from the acceptance checks.scope & limits ↻
Evidence scopeFACT-BOUNDED / implemented parts. Not a public run receipt; a stronger guarantee remains withdrawn.The signed calibration summary is public; primary run receipts remain private.Inspect the evidence →
Test the changed sourceA passing test must concern the code being evaluated.Packaging calibration found tests running against an installed package. A source-match check was added.scope & limits ↻
Evidence scopeFACT-BOUNDED / calibration finding and implemented check, not a customer result.The signed calibration summary is public; primary run receipts remain private.Inspect the evidence →
Observe running softwareSource code alone does not prove a running system.Historical Astronomy Shop work explored verifying running software within a limited observation window.scope & limits ↻
Evidence scopeFACT-BOUNDED / historical feasibility. No current production acceptance or customer installation.The signed calibration summary is public; primary run receipts remain private.Inspect the evidence →
Carry requirements forwardThe signed calibration summary names 11 protected dimensions.The public calibration record is the signed summary.scope & limits ↻
Evidence scopeFACT-BOUNDED / development-only calibration. The public signed summary is not the full run receipts.The signed calibration summary is public; primary run receipts remain private.Inspect the evidence →

Downloads

Take the public signed summary and explanation with you. The underlying governed receipts and mirror remain private, not publicly accessible; access requires separate authorization.

How this differs from review and CI

A decision that carries forward.

Code review reads a change. CI runs your tests. Apex is designed to add a separate acceptance decision: checks the author does not control, and rules agreed before the change. Acceptance means permission for a change to enter the main branch.

DIRECTION / design: an accepted improvement becomes a measurable minimum future changes must preserve. Apex calls this a floor; carrying it forward is the ratchet. This is the intended difference, not evidence that Apex replaces your review or CI.

FACT-BOUNDED / calibration: the signed projection names 11 protected dimensions and records performance.nesting_ceiling moving from FAIL to PASS. The signed public summary is not the full run receipts or a replay of the verdict.

No customer pilot or installable GitHub App is live yet. Early access is not yet open.

The governed loop

Governed stages between a proposal and a decision.

The diagram shows the longest path, not a count of stages a change passes. A change that fails a check stops at that stage and does not advance. Regions group the stages.

  1. BindFix exactly what is being changed.
    1. StartA governed run opens for its goal.
    2. Pin the subjectWhat is being changed is fixed.
    3. Bind the repositoryThe exact code revision is locked.
    4. Discover what must holdProperties that must stay true are found.
    5. Seal the rulesThe owner's rules are fixed before work starts.
  2. GovernApply the owner's rules before any code moves.
    1. Judge the goalThe goal is checked against the rules. No change is a valid answer.
    2. Bind what may changeThe scope of any change is set in advance.
  3. ExecuteA coding agent proposes a bounded change, then stands down.
    1. Candidate producedA coding agent proposes a change.
    2. Author stands downThe author keeps no authority after handing over.
  4. ProveMachinery the author does not control tests the exact candidate.
    1. Independent verificationChecks the author does not control test the candidate.
    2. Outcome recordedThe result is written down, not summarised by the author.
    3. Results sealedRecorded results are locked.
    4. Evidence packagedThe run's evidence is bundled for review.
    5. Checked offlineThe bundle is verified without trusting the run.
    6. Run completesThe run ends with a recorded result.
    7. Final verificationA further independent check before delivery.
  5. PromotePassing is not permission. Eligibility is decided separately.
    1. Bind to the exact changeThe verdict is tied to this exact change.
    2. Promotion decisionPassing is not permission. Eligibility is decided separately.
    3. Awaiting operator mergeEligibility to land is decided separately from the checks.
    4. Merge observedWhat actually landed is checked.
  6. RatchetWhat was accepted becomes the next baseline.
    1. Learning recordedThe outcome is recorded for the next run.
    2. Delivery closedThe delivery record is sealed.

CandidateIndependent checkHuman authorityIllustrates the design of the governed loop, not a run receipt. Evidence of what has run is on the evidence page.

Want to talk to Apex?

apex · public proof runtime
Ask about the public record. Answers are bounded by indexed sources.
$

Latest

Interested in the design for software that keeps improving within your rules? The complete system and a customer pilot remain future work.

Early access - not yet open →