About
Apex is being built to understand a codebase, discover worthwhile improvements and evolve software within customer-defined rules, authority and evidence requirements. The category thesis is bounded perpetual software: a unified intelligence and constitutional software-evolution system, still in development.
The ambition
The ambition is software that can keep learning about its own reality, identify worthwhile opportunities and improve within customer-defined constitutions and workflows. That requires understanding before action, explicit authority for bounded changes, evaluation separate from the author, and memory of what future changes must preserve.
What exists today
The internal capability audit describes implemented and partial components. Those source-reported statuses are not independent public evaluation of the private runtime. The website's Lab, Studio, Atlas and Observatory explain the architecture; their availability does not establish live Apex operation.
What the public record reports
Governance and verification make that ambition accountable; they are essential parts of the product rather than its entire definition. Component implementation, a historical outcome and the proposed complete system are different claims. On a private mirror of pypa/packaging, development-only calibration evaluated bounded changes against machine-checkable floors fixed in advance. The target's own tests and the Apex evaluator supplied distinct results. The signed projection records acceptance PASS and does not name a person. It names 11 protected dimensions and reports a target dimension moving from FAIL to PASS; this is not a public per-dimension evaluation or native Apex Review ACCEPT. That is a bounded record, not proof of an unattended customer deployment or a sealed fix of a real deficiency.
Early access is not yet open. We publish the evidence and its limits as we go. Read the investor brief for the category thesis and next evidence milestone, explore the writing, or go straight to the evidence.
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.
Intelligence
Build a grounded picture of the software and its constraints.
Discovery
Identify real defects, gaps and opportunities worth improving.
Constitution
Use the customer's constitution to bound change and authority.
Governed change
Produce narrowly scoped changes within allowed operations.
Independent acceptance
Keep proposed changes separate from checks and acceptance evidence.
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.