Work / Invariant
A model says the change is done. What actually happened?
That question is what pulled me into Invariant. I’m building separate pieces for reusable engineering methods, a human-facing capability layer, and a harder execution boundary because a confident answer, a passing command, and an acceptable result are not automatically the same thing.
The problem
One word can hide several different claims.
- Did the system use an appropriate verification method?
- What repository state was the work based on?
- What was authorized?
- Which commands actually ran?
- Which result supports which requirement?
- Is that evidence still current now?
Three responsibilities
I split the work because those questions belong to different layers.
Which methods are worth reusing?
Arsenal captures recurring engineering judgment as inspectable methods, capability contracts, evaluation records, and portable packages.
Recent work evaluated competing Repository Recon methods and a verify-change proof-obligation method before adoption.
Inspect Arsenal ↗What supported capability is the person asking for?
Loadout starts from a goal, resolves supported capability, freezes a plan and work envelope, and presents the result back in a human-facing form.
It now distinguishes simulation from canonical real Kiln results and has a verify-change path bound to a frozen verification projection.
Inspect Loadout ↗What was authorized, executed, and actually evidenced?
Kiln owns the harder effect boundary. For registered verification it executes known commands through a hardened no-shell host, binds results to proof obligations, and returns structured readiness.
The merged verification slice recorded 689/689 Kiln tests passing plus unrestricted and sandbox dogfood runs with 9/9 obligations satisfied and READY.
Inspect Kiln ↗A concrete path
“Verify this change.”
That request is small enough to show why the split matters without making somebody learn the whole product universe.
CURRENT PROOF The verify-change path was selected against known-defect and sealed-holdout evidence, adopted into Loadout, then bound to Kiln registered commands. Both unrestricted and sandbox dogfood runs reached READY.
A failure that mattered
The real boundary broke before the architecture story was allowed to win.
That was useful. Fixture behavior had to give way to what the actual CLI and restart path did.
- 01CLI composition failed
The real supervision path omitted the Artifact root and crashed when durable evidence tried to write.
- 02Restart lied by placeholder
The reconstructed result used sentinel values instead of rebuilding authority and state from durable facts.
- 03Repair the boundary
Kiln began persisting the missing input bindings and reconstructing from integrity-verified Artifacts and Evidence.
- 04Use the real path
Loadout then rendered canonical real Kiln results instead of treating the simulation as the product boundary.
That sequence is more important to me than a clean architecture diagram. It forced the integration to answer with real durable state instead of a convincing approximation.
What I will claim today
The maturity is intentionally uneven.
Reusable methods, capability contracts, deterministic packaging, evaluation infrastructure, and recent cross-product method selection.
A deterministic defect-detection campaign is not the same as proving a coding model performs better with Arsenal.
Repository Recon, canonical real Kiln result rendering, and a merged verify-change capability bound to an immutable plan/work envelope.
Real execution exists for supported paths; capability maturity still varies.
Durable work state, real supervision repair, registered-command verification, proof-obligation binding, bounded execution, and structured readiness.
The larger delegation/orchestration direction is not required to make the current verification proof useful.
Why this project fits me
AI made an old support habit more important.
Support taught me not to confuse what somebody says happened with what the system can actually show. AI-assisted engineering creates the same problem at much higher speed: the model can be persuasive before the evidence is complete.
Invariant is where I’m trying to make that gap smaller. The interesting work is not making the agent sound smarter. It is making the result easier to inspect, challenge, recover, and accept.