00 / ABSTRACT
A choice needs a commit boundary.
JEV provides a typed decision interface. TypeSafe’s documentation describes Choice, Noul and Score questions over supplied state [1]. The question investigated here is what an application must own after it receives such an answer. A permitted choice does not, by itself, establish current authority, a resource budget, the validity of a produced artifact, or the durability of an accepted result.
We propose GrokCell Execution as a small, explicit contract around that transition. The host observes state, offers permitted actions, obtains a choice, produces a candidate, checks it, and accepts it only against current permission and recorded evidence. Our implementation is a single-host Python prototype with optional SQLite persistence and two offline fixtures. The completed sprint records 87 passing tests and process-interruption experiments [4]. These results support specific recovery behavior; they do not establish live-provider quality or security isolation.
A bounded attempt that ends in an evidence-bound accepted revision, or a recorded reason to stop.
01 / FIRST-PRINCIPLES DERIVATION
Separate judgment from authority.
Start with four requirements imposed by the task itself. An action consumes resources. Permission can change while work is running. A result can be invalid even when its action was allowed. A process can stop between an external effect and recording the response. Each requirement needs an owner outside the model’s answer.
- Authority belongs to the host. The application defines effects, expiry and revocation. The chooser selects among the supplied offers.
- Work carries a liability. Reserve budget before dispatch. If a response is lost, keep the reservation until its outcome is resolved.
- Evidence binds to exact inputs. A result applies to a candidate, dependency snapshot and checker contract. Changed state can invalidate acceptance.
- Acceptance is a state transition. Commit the accepted revision with its supporting records. A successful callback alone is insufficient.
This reasoning led to a smaller scope than a general agent platform: one run, one coordinator, explicit records, six operations and one authoritative local store. We deferred a service, distributed scheduling, a workflow language and live providers until an accepted task requires them.
02 / EXECUTION CONTRACT
Six operations. One owner of acceptance.
| Operation | Output | Required boundary |
|---|---|---|
read | Observation | Bind inputs to dependencies and state revision. |
decide | Decision | Select one offered, permitted action. |
call | Candidate | Reserve resources before invoking the worker. |
check | Evidence | Bind mandatory checks to the exact candidate. |
admit | Accepted revision | Validate current authority, freshness and passing evidence. |
yield_ | Paused run | Persist the pause; resume does not renew limits. |
The following is a design predicate, not a formal proof of the implementation. With candidate c, evidence e, current state s and permission p, acceptance requires:
admit(c, e, s, p) only if
permitted(p, now) ∧ fresh(c, s)
∧ bound(e, c, dependencies, checker)
∧ all_required_checks_pass(e)
∧ within_limits(run)
commit(accepted_revision, candidate, evidence, journal)The implemented verifier is trusted host code. Its separate interface supports a separation of responsibilities; it does not yet provide process isolation or independence from a compromised host.
03 / DURABILITY & FAILURE SEMANTICS
Record intent before work can escape.
The optional state directory holds a single SQLite snapshot. It encodes known records as bounded, versioned JSON; it does not deserialize pickle or import classes selected by saved data. A lifetime operating-system lock admits one coordinator. SQLite supplies transaction atomicity [2]; our store uses rollback journaling and full synchronization. Filesystem and hardware assumptions still matter [3].
Persist intent, step binding and reservation.
Persist result and accounting before consumption.
Commit revision, evidence and journal completion together.
A restart replays a completed step from the journal without another callback. An interrupted started step has an unknown outcome and cannot be resent automatically under the same step identity. This is conservative replay control, not an exactly-once guarantee for remote effects. The prototype has no live effects and no external reconciliation procedure.
Restoration checks configuration identity, including permission, budgets, dependencies, adapter identities and checker contract. The original deadline and counters remain in force. Cancellation, revocation and pauses survive restart. A save failure disables further work and audit reporting from potentially uncommitted memory. Missing or damaged initialized state fails closed.
Checksums detect accidental corruption, not an adversary who can rewrite the database. State is unencrypted. New POSIX directories use mode 0700; Windows permissions inherit from the parent directory. This design assumes a trusted account, host and local filesystem.
04 / IMPLEMENTATION & EVALUATION
Test the boundary where certainty is lost.
The session extracted the Apache-2.0 execution scaffold from OSAHR_Cell, established the standalone grokcell-execution package, and added durable offline recovery. The baseline comprised 51 tests; Sprint 1 expanded the suite to 87. GPT-6 Luna agents at medium reasoning effort implemented storage, runtime integration and independent failure tests, followed by integration and maintainability review. Automated assistance is part of the method, not a substitute for external replication.
| Experiment | Observed behavior | Scope |
|---|---|---|
| Fresh-process replay | Both fixtures retain two charged calls and one accepted revision; the second process invokes no recorded callbacks again. | Offline chooser, worker and verifier. |
| Death during callback | Dispatch intent and reservation survive; reopening the same step stops. | Process termination, not power loss. |
| Death around admission | Recovery retains a complete old or new snapshot with exact candidate/evidence binding. | Before/after store-save boundaries. |
| Configuration or storage faults | Changed identities and corrupt state are rejected; persistence failure blocks subsequent work. | Tested fault cases, not exhaustive proof. |
| Delivery checks | Linux Python 3.11/3.13, Windows 3.13, installed-wheel recovery and ephemeral container checks pass. | Recorded CI revision. |
The repair fixture verifies exact bytes without executing Python. The dependency fixture checks the shape of an assessment without establishing dependency compatibility. Neither fixture measures general repair accuracy. Ruff and Bandit checks passed; the dependency audit reported no known vulnerabilities in the checked environment. These checks are not a security certification.
Implementation record and reproduction
Implementation: grokcell-execution 0.2.0, merged revision 450c0536c161eddb70f1b89aaeb0cac0c213c6cd. The repository is currently private; the linked code and CI records require access. This report is a public account of internal engineering evidence, not an independently reproduced result.
# From an authorized checkout, with Python 3.11+
python -m pip install -e .
grokcell repair --state-dir .grokcell/repair
grokcell repair --state-dir .grokcell/repair
grokcell inspect --state-dir .grokcell/repairUse a separate directory for the dependency fixture. Reopening retains the original one-hour fixture deadline.
05 / LIMITATIONS & RELATED FOUNDATIONS
Keep the claim smaller than the evidence.
The contribution is an implemented composition of familiar systems boundaries: typed decisions, host-owned permissions, journaled intent, candidate-bound evidence and atomic acceptance. We do not claim invention of transactions, replay, resource accounting or verification. SQLite’s transaction and locking documentation supplies the storage foundation [2, 3]. TypeSafe’s interface supplies the proposed typed-decision boundary [1].
- No live JEV or Hugging Face integration in this runtime. The chooser and worker are offline fixtures. Other SyberLabs applications have separate integration histories.
- No hostile-code sandbox. Imported Python adapters execute with host privileges; logical limits do not preempt a stuck callback.
- No remote exactly-once claim. Retaining an unknown outcome avoids a blind resend, but does not determine what a remote provider did.
- No certified backup, migration or power-loss recovery. Process-kill tests cover a narrower failure model.
- No task-quality or economic benchmark. We have not measured live success rate, latency or cost per accepted result.
The preliminary hypothesis is that making these boundaries explicit will improve inspectability and constrain failure propagation. A comparative evaluation is needed to establish whether it improves operational outcomes enough to justify its complexity.
06 / RESEARCH AGENDA
Progress by evidence, not by feature count.
Durable offline runs
Recover records and acceptance across process exit; refuse unresolved replay.
Isolation & recovery
Separate candidate execution from evidence authority; exercise backup, migration and operator reconciliation.
Live provider evaluation
Integrate pinned JEV and worker identities; retain receipts and compare accepted-result quality, cost and time.
Independent maintainer pilot
Validate installation, rollback and recovery on a supported target with another maintainer’s task.
A useful experiment should hold the task set and acceptance tests fixed, compare against a declared simpler implementation, and report invalid acceptances, completion rate, unresolved outcomes, recovery effort and cost per accepted result. Null or unfavorable results must remain visible.
Where does this contract fail?
We welcome counterexamples to the acceptance predicate, stronger failure-injection methods, and criticism of the proposed isolation boundary. A concrete failing trace is especially useful.
Contact SyberLabs ↗07 / REFERENCES & PROVENANCE
Sources and implementation record.
- TypeSafe AI. Quick start: typed questions and answers. Accessed 26 September 2026. Independent integration; no partnership implied.
- SQLite. Atomic Commit in SQLite. Accessed 26 September 2026.
- SQLite. File Locking and Concurrency in SQLite Version 3. Accessed 26 September 2026.
- SyberLabs. GrokCell Execution, Sprint 1 implementation and checks; verification record at merged revision. Private repository; authorized access required.
- SyberLabs. OSAHR_Cell. Apache-2.0 source provenance: extracted scaffold revision
481151c00347ce461fb5439f4e0a9f73ec64e8fd. See the implementation’s LICENSE and NOTICE for attribution.
This report summarizes the design and first implementation sprint from this research session. It is an engineering report, not a peer-reviewed paper or a claim of production readiness. Source availability limits independent verification.