ClawCapsule Proof Viewer
ClawCapsule is a local-first runtime for agent execution that treats structured state as authoritative, compiles deterministic, bounded context for each step, and supports checkpoint and restore as explicit runtime operations. This viewer organises the current evidence package for technical review, beginning with the runtime substrate, then the bounded controller path, and then the supporting operational evidence from the validated path to date.
This is a compact view of the current proof package for ClawCapsule. It focuses on whether the runtime claim is real, bounded, and supported by inspectable evidence.
The proof layers remain separate so the boundary between substrate evidence, controller evidence, and operational evidence stays visible.
ClawCapsule is the runtime substrate: compile, persist, checkpoint, restore,
and state semantics. claw-agent-ref is the proving and benchmark
harness used to exercise that substrate under controlled conditions.
The runtime claim should stand on its own. Evidence from the harness is used to validate behaviour, not to redefine the product boundary.
Four conclusions supported by the current evidence.
Outcome 1
The runtime is designed to return byte-stable bundle_text for the same
authoritative state, regardless of delay, restart, or repeated invocation. That matters because
it turns context assembly into a governed runtime property rather than a hidden prompt artefact.
Outcome 2
Checkpointing is not a logging convenience. Restore re-establishes prior authoritative state and removes later mutations that are outside the restored checkpoint, which is a stronger claim than simple history retention.
Outcome 3
The evidence packet covers core mechanism proofs, clutter-pressure and replay exercises, limited live model-in-loop reference validation, and operational telemetry. The result is a broader validation story than one long run alone.
Outcome 4
There is a constrained model-in-loop reference lane showing that a canonical controller can operate against the substrate with real persistence and replay semantics. It is evidence of viability, not a blanket autonomy claim.
The proof stack is organised by evidence type.
Layer 1
This is the cleanest substrate lane. It focuses on deterministic compile, persistence, checkpoint, restore, and endurance behaviour without relying on an external daemon-backed proving packet.
It shows that the runtime can hold its state contract under sustained operation and that compile remains a governed system function rather than a conversational side effect.
Sources: Endurance Gate Note (50k)
Layer 2
This packet covers replay and clutter-pressure behaviour, with base mechanism proofs, pressure tests, and a capped extension out to 500 steps. It demonstrates replay semantics and retained-state discipline under more adversarial conditions.
It strengthens the case that state durability is operationally meaningful, while still being read as a packet with explicit boundaries rather than a claim of general intelligence.
Sources: packet README, packet summary, proof plan
Layer 3
The reference lane shows a canonical controller operating against the substrate with grounded writes, replay, and bounded evidence admission. This is the bridge from substrate contract to live controller use.
It supports a practical viability reading, but it should not be read as proof of broad autonomous capability across open-ended tasks.
Sources: Reference validation report
Layer 4
Supporting reports add latency, throughput, soak, and implementation behaviour detail. These are important because runtime credibility depends not only on semantic correctness but also on whether the system can operate with acceptable practical characteristics.
This layer helps a reader judge whether the design looks governable and investable in real systems, even though it is not yet a full production benchmark suite.
Sources: Overnight run suite report
This section expands the daemon-backed replay packet into the underlying cases. It keeps the mechanism layer legible by grouping the evidence into base proofs, clutter-pressure proofs, and the single capped endurance extension.
Five compact cases that make the core substrate mechanics easy to inspect.
Shows interruption survival through checkpoint and restore.
The mutated compile differs from the checkpoint-state compile, and the restored compile
matches the checkpoint-state compile exactly. The restored bundle contains
re-enable HMAC verification and excludes
leave temporary bypass enabled.
Three cases that keep the substrate honest under growing but valid same-task clutter.
Shows deterministic compile and useful re-emission under medium clutter pressure.
compile_a and compile_b remain identical in both
bundle_text and included_items. Each compile token estimate is
567, and the final bundle keeps the relevant auth-fix subset while omitting
sampled clutter strings.
Shows restore continuity after heavy valid clutter plus post-checkpoint mutations.
The checkpoint-state compile, compile_restored_a, and
compile_restored_b are identical in both bundle_text and
included_items. The restored bundle returns to the retained auth-fix subset
and excludes the temporary bypass lane.
One bounded extension that demonstrates a longer clutter run without inflating it into a broader benchmark family.
This is the only endurance extension in the packet, and it remains explicitly capped.
compile_100_a and compile_100_b match,
compile_250_a and compile_250_b match, and
compile_500_a and compile_500_b match. The final restored
compile matches the checkpointed retained subset, while the mutated compile shows the
temporary proxy bypass lane and then disappears after restore.
OMEGA-9921,
src/auth/webhook_guard.rs, re-enable HMAC verification,
and reject unsigned webhook replay
src/gateway/proxy.rs,
leave temporary bypass enabled, and
allow unsigned replay until Monday
449 at step 100, 566 at step
250, 580 for the mutated compile, and 566 at the final
restored compileThe stack is organised from core runtime proof outward: substrate validation first, replay validation second, bounded live controller evidence third, and supporting operational evidence after that.
The current evidence supports a serious architectural claim: durable agent continuity can be implemented as explicit runtime machinery with deterministic state compilation, persistence, and recoverable execution semantics.
It also supports a narrower practical claim: a controller can operate on that substrate in a controlled reference lane without collapsing the runtime boundary.
The evidence should not be read as proof of broad autonomous reliability, universal coding superiority, general product readiness, or a solved comparison against every transcript-centric system in the market.
Those are future diligence questions, not current validated conclusions.
The current evidence establishes a bounded but substantive validation envelope for the ClawCapsule runtime and its supporting proof stack.
The runtime substrate has evidence for deterministic compile, authoritative checkpoint and restore semantics, and sustained endurance in the runtime-only lane. The validation package also includes a daemon-backed replay packet, limited but meaningful model-in-loop reference validation, and supporting operational telemetry and latency evidence.
The current package does not yet establish broad comparative dominance over the best transcript-centric systems, full production hardening across varied workloads, or unconstrained long-horizon autonomous task completion in the general case.
Current diligence position The package supports technical review of the core runtime claim, while leaving broader comparative, deployment, and generalisation questions open for further diligence.
These documents form the primary evidence path for the runtime claim: claim boundaries, methodology, exact gate proof, and substrate packet summary.
Defines the bounded claims supported by the current evidence and the limits that govern outward interpretation.
Explains the validation methodology, conservative reading discipline, and how the runtime evidence should be interpreted.
Records the exact reference-lane 50k runtime-only gate clearance, including run id, checkpoints, and bounded scope.
Summarises the substrate replay packet, including base mechanism proofs, clutter-pressure cases, and the capped 500-step extension.
These reports provide supporting operational and bounded integration context. They sit behind the core runtime evidence and do not widen the primary validation claim.
Bounded canonical-controller reference run showing live seam behaviour, preserved boundaries, and the limits observed in that round.
Extended runtime-only operational report covering determinism, phase completion, and bounded latency behaviour on the evaluated configuration.