The constitution

Stop reviewing changes as they arrive. Start governing what change is allowed. That sentence is the destination. This essay argues for it - it does not claim it as shipped capability. What exists today is the machinery such a destination has to stand on. Its public evidence and limits are available now. So: the down payment, then the thesis.

The down payment

Components for governed change exist in early form. The public signed calibration projection records a target test result and an acceptance field. The separately reported fresh-clone check was a private same-engine re-evaluation, not independent verification. Primary receipts remain private. The intended ratchet makes accepted requirements constraints on later work; this record does not establish a continuing evolution cycle. The evidence pages publish the summary and its limitations.

Read the public evidence and its limitations.

That machinery answers the “how”: how Apex can safely keep changing software. What it does not yet answer is the more interesting question.

Who decides what better means

The ratchet and independent verification explain how Apex can safely keep changing software. The customer-authored constitution explains who decides what “better” means.

Today software development roughly looks like:

human intent → requirements → developers/agents → code → review → deployment

The human intent gets translated repeatedly, and humans remain in the loop because someone ultimately has to judge whether the result is acceptable. Apex is aiming at something structurally different:

customer intent → machine-enforceable constitution → Apex observes current software → identifies gaps between reality and intent → agents propose changes → independent machinery verifies them → accepted state becomes new floor → repeat continuously.

The constitution persists while the workers can change.

A constitution, not a backlog

Imagine a bank doesn't tell Apex: “Fix this ticket.” Instead it defines durable constraints and objectives: reduce latency and operational cost; never weaken authentication; preserve these regulatory controls; these behaviours must always remain true; new functionality must satisfy these acceptance criteria; production changes require this evidence; these components may never be modified autonomously.

Those aren't instructions for a coding session. They describe the space within which the software is allowed to evolve. That's much closer to a constitution than a backlog.

Then the customer's relationship with software development changes. Instead of continually specifying “make change X”, they increasingly specify: “this is what good looks like, these are the boundaries, and this is the evidence required before reality may change.” Apex works inside that space.

The inversion

With ordinary coding agents, humans supervise the work. With the Apex end state, humans govern the system that supervises the work.

That's a very different scaling model. You don't need a human watching every token or reviewing every agent decision if the agent has limited authority and cannot control the acceptance mechanism. Humans move upward in abstraction: write code → review generated code → specify acceptance criteria → govern the constitution.

The constitution as an asset

The durable asset isn't necessarily the coding model. Claude gets better. Codex gets better. Another model beats both. Fine. Swap the worker.

But the customer may have spent years accumulating business requirements, security constraints, regulatory obligations, architectural invariants, performance floors, acceptance criteria, operational evidence requirements, and historical verified improvements. That becomes the institutional knowledge of what this software is allowed to become - and every accepted Apex cycle potentially adds to it.

Today's institutional knowledge is scattered across Jira tickets, people's heads, tests, compliance documents, runbooks, architecture docs, CI configuration and tribal knowledge. A mature Apex constitution could increasingly turn that knowledge into executable governance.

The ratchet makes it compound

Suppose the customer's constitution initially protects security ≥ S₀, reliability ≥ R₀, and latency under a stated ceiling. Apex finds an improvement and independently proves a lower latency. That becomes the new floor. A later agent can't introduce a shiny feature while quietly taking latency back above that floor unless the governing policy explicitly permits that tradeoff.

So the constitution isn't static policy. It accumulates what the organization has earned and proven. Progress compounds rather than silently regresses. And when the customer adds a new intention - “support another payment method” - Apex doesn't receive permission to rewrite whatever it wants. It gets a new objective inside the accumulated constitution, and must produce the feature while preserving every previously protected property. That is much closer to genuine governed software evolution.

The stronger definition

Apex lets organizations define what their software should become, what it must never lose, and what evidence is required before a change can become real. Coding agents work inside those boundaries. Apex independently verifies their changes, rejects anything that cannot prove itself, and turns accepted improvements into the protected starting point for the next cycle.

And the shift is bigger than it looks at the start. It isn't just from humans writing code to agents writing code. It's from humans supervising individual software changes to humans governing the rules under which software can continuously change itself.

Agents make change abundant. The constitution encodes human intent. Apex governs the transition from a verified software state to the next.

If that works at scale, we're not building a better development tool. We're changing the abstraction at which humans develop software.