How Apex decides what your software becomes next

Apex is being built to turn a request to improve software into a governed change of state. The intended model separates the author from evaluation and makes accepted requirements constraints on later work. The public calibration record does not establish that complete continuing system.

What you give Apex

A codebase, a goal, and a constitution: the owner's written rules for what may change, what must be preserved, what evidence counts, and who has the authority to accept the result. The constitution is the law. The agent works inside it and cannot edit it.

The governed loop

The following regions explain the intended loop, not an authenticated account of a complete runtime execution.

Bind. Apex pins exactly what it is working on: this repository, this revision. The target cannot shift under the evaluation.

Govern. The owner's rules are attached before any code changes, and Apex decides whether the goal is allowed under them at all. Sometimes the right answer is no change. That counts as a successful outcome.

Execute. A coding agent gets a bounded problem and a fixed finish line. It can reason, try things and iterate. When it hands back a candidate, its part is over. It does not get to move the finish line, edit the evidence or declare itself finished.

Prove. Machinery the worker does not control tests the exact candidate against the properties that must hold and the improvement that was asked for. Results are recorded, not summarised by the agent that wrote the code. The verdict applies to that exact candidate. Change the code and the verdict no longer applies.

Promote. Passing is not permission. Whether a verified candidate may cross into the customer's system is a separate decision, made against the constitution, with a person holding the authority the constitution names.

Ratchet. What was accepted becomes the new baseline. Then the loop starts again from there.

Agents agreeing with each other is not proof. The judgment has to come from evidence the worker does not control.

The ratchet

Say a system sits at a baseline. Apex finds a valid improvement and produces a candidate. To be accepted, that candidate must show the requested improvement is real, and the protected properties of the baseline are still there. If both hold, the candidate becomes the baseline and its protections carry into the next cycle. If not, the baseline does not move.

So the next agent is not just trying to make another change. It has to improve on the new baseline without giving back anything already earned. Each verified baseline becomes the start of the next. Floors are explicit and machine-checkable. In the design they only move up; a person with authority can retire or amend a floor, deliberately and on the record.

Floors guard only what they measure. A harmful change can still pass every configured floor. That is why floors grow from what each cycle teaches, and why acceptance is never left to the system alone.

More capable agents, bounded authority

DIRECTION: what we are working toward.

We are working toward software improvement in which more capable agents do not gain more authority. The aim is to constrain the worker, the rules it works under, and Apex itself. For an owner, the value is control over what changes and what must survive, without having to trust an agent's account of its own success.

The concern about agents going rogue is a question of authority: what can the agent change, who decides whether it succeeded, and can it rewrite the rules when they get in its way?

The workflow bounds the work

Our aim is for the agent to receive a bounded problem and a fixed finish line. It can try different ways to solve the problem, but it cannot enlarge its assignment or make itself the judge. A convincing explanation should never be enough to turn its proposal into an accepted change.

The constitution bounds the authority

The owner's rules should define what may change, what must be preserved, and what evidence counts. Apex is designed so a person makes the acceptance decision. We are working toward letting better models operate under those same limits. More intelligence should mean better proposals, not permission to put more of the owner's business at risk.

Apex should be bound too

The same principle must apply to the system deciding what is acceptable. We are working toward holding Apex's own improvements to the constraints it applies to other software. It should not be able to make a change acceptable simply by loosening the standard that change failed.

Documented today, not proof of enforcement: in apex-prime, Apex's own changes are proposed as pull requests. Its written rules require explicit human sign-off for changes to the checks themselves.

This is a direction for governed software change, not a promise that agents cannot misbehave. The goal is for a mistake to remain a proposal rather than become the next baseline, and for accepted improvements to carry their protections forward.

What it looks like in practice

Reported historical calibration. The public signed projection from a private pypa/packaging mirror names eleven protected dimensions and records performance.nesting_ceiling moving from FAIL to PASS. Its target-native result reports 26,854 passed and zero failures.^{evidence summary} The calibration account also reports an earlier operations.retry_bound floor, reversal checks and a private same-engine re-evaluation. Those private records are not publicly reproduced. This is a bounded development account, not independent proof of an ongoing ratchet or a repair of a customer problem. The evidence page separates the public summary from private primary receipts.

Illustration, not a receipt. Suppose you tell Apex: reduce checkout latency without changing observable checkout behaviour or weakening security controls. A normal coding agent changes something, runs the tests and opens a PR. Under Apex the starting revision is pinned, the protected behaviour is fixed before the run, and the worker gets a bounded problem and exits with a candidate. Separate machinery then measures the improvement and checks for regressions. Only a candidate that meets the constitution can reach the customer's acceptance step. Once accepted, the faster checkout is part of the baseline, and the next cycle has to keep it. Any figures in such an example would be invented to explain the idea.

It is not: AI writes code, AI says the code looks good, merge. It is: the owner defines the law, an agent proposes a bounded change, separate machinery shows what happened, the constitution decides whether the evidence is enough, an authorised person promotes it, and the accepted state becomes the new floor.

Trust in autonomous change should not reset to zero at the start of every run. The ratchet makes it accumulate.