A function may exist. A resolver may find it. Tests may pass. None of that grants production authority.
The last part ended on a deliberate design choice: the new capability lane was built so that merely working would not make it authoritative.
This is that design.
One of the most important principles in the capability-resolution work is simple:
Capability does not equal authority.
A function may exist.
A resolver may find it.
A side lane may execute successfully.
Tests may pass.
None of those facts automatically grant production authority.
The experimental capability resolver was deliberately created beside the existing invocation lane rather than replacing it.
The established implementation remained runnable.
The new implementation received temporary identities.
The two could be compared.
And even if the new path worked, shadow success did not equal promotion.
That rule matters because autonomous systems become dangerous when technical success silently turns into institutional authority.
The side lane was intentionally inert
The WP5A evidence — the recorded proof from the side-lane work package — established several things.
The new resolver/invoker:
- had a separate entry point;
- did not modify the existing baseline;
- used exact resolution;
- used a static catalog rather than mutable dynamic paths;
- did not fall back into the existing lane;
- had no delivery authority;
- had no activation route;
- could not promote or retire itself.
That is a meaningful result.
But there is an equally important thing it did not prove.
WP5A did not establish Blog Capture behavioral equivalence.
That comparison was explicitly deferred.
The correct statement at that stage was:
separation proved; behavioral comparison deferred.
That may sound less exciting than declaring success.
It is actually much more important.
The system was being forced to distinguish:
what has been demonstrated
from
what we would like to believe.
Should an autonomous system ever be allowed to promote its own implementation simply because its tests pass?
Promotion and retirement are different decisions
Another principle in the implementation plan is that promoting a new capability does not automatically authorize deleting the old one.
Those are separate governance events.
The new lane must earn promotion.
Then it must prove the required behavior is covered.
Then rollback must be demonstrated.
Then the system must survive an agreed soak period.
Only then can retirement of the prior implementation become a separate decision.
This creates friction.
That is intentional.
The important question is not:
Can an AI modify software quickly?
We already know it can.
The harder question is:
Can it modify a large operational system while preserving identity, evidence, authority, reversibility, and a trustworthy record of what changed?
That question leads directly to the benchmark.
The system pieces in this story
New terms in this part — Parts 1 and 2 cover the capability-resolution lane, correlation envelope, task_id, SPOCs, the canonical session chain, session reports, emission, and witness evidence. Each links to its entry in the live Governance Glossary (sign-in required).
Side lane (shadow lane) — an experimental implementation deliberately built beside the production path: separately named, runnable, comparable, and fail-closed — no delivery authority, no activation route, no ability to promote or retire itself.
Temporary identity — the provisional identity an experimental capability runs under, recorded as non-canonical in its own evidence. Nothing carrying a temporary identity can be mistaken for — or quietly become — the production implementation.
WP5A evidence — the recorded evidence from work package 5A of the capability-resolution pilot: a separately named, fail-closed shadow invoker proven for invocation ordering, exact catalog loading, and typed outcomes — with what it did not prove recorded just as deliberately.
Blog Capture — the production capability the side lane was built beside: the governed, operator-driven workflow that captures approved canvas content into the blog store. Behavioral equivalence with it is the comparison WP5A explicitly deferred.
Promotion — the gated governance event that converts working code into authorized capability, requiring explicit approval. Passing tests and shadow success are inputs to promotion, never substitutes for it.
Retirement — the separate governance ruling that removes a prior implementation, granted only after the promoted lane proves coverage of every required behavior of the old one. Promotion never implicitly authorizes deletion — and a survived soak period alone is not enough.
Soak period — the agreed interval a promoted lane must survive in real operation before retirement of its predecessor can even be considered.
Next in this series: Now We Have to Prove It
0 comments