Skip to main content

WootzApp Factory / System architecture

Execution · Capture · Post-training

Openrind Shell.
Engineered for continual learning.

Openrind Shell couples native agent execution with a persistent filesystem and model-context capture scoped by signed session identity. In the Desktop deployment, Linux sandboxes run inside a VM. The gateway constructs reviewed, recorded-session RFT + OPSD supervision from eligible conversations.

Figure 01 / Execution & capture

Desktop deployment / WSL2 virtual machine
Linux agent sandboxNative agent processes

bash · git · compilers · tests

Supervised FUSE mount/sandbox/work

Filesystem · process · network policies

Project I/O ↓
PostgreSQLCommitted workspace state
Model calls ↓
Capture gatewaySession-scoped histories

Workspace storage and model-context capture are separate paths.

01 / Execution architecture

More than a token gateway.
Deeper integration for trace capture.

Model traffic records the agent’s view of a run. Openrind also integrates the execution environment: native tools, committed project state, browser observations, and independent task-outcome records. Researchers can inspect evidence beyond the model API boundary.

LayerImplementationResearch use
ExecutionNative processes run inside a supervised Linux sandbox. The Desktop deployment hosts it in a VM, with filesystem, process, and network controls.Run the shell, compiler, and tests that produce the agent’s actual tool feedback.
Project stateA supervisor-owned FUSE mount serves /sandbox/work through a Rust daemon. PostgreSQL stores inode metadata and sparse 256 KiB chunks; commit barriers and a fenced lease govern writes.Inspect committed code and artifacts across sandbox replacement, using the same native filesystem interface as the agent.
Model contextSigned conversation context binds managed calls to a workspace, sandbox, and agent. The gateway records supported messages and model-visible tool calls and results.Recover recorded prefixes for session judging, turn selection, and grounded hint validation.
Human demonstrationsA separate Desktop recorder pairs input events with before/after frames and display-relative coordinates.Inspect the visual evidence around a human action when designing supervision.

Cybersecurity / CTF instrumentation

CTF traces with independent flag verification.

The CTF capture path links model interactions and browser steps with challenge-side HTTP metadata and flag-judge results. This supplies evidence outside the model’s request/response stream, so researchers can inspect an attempted solve alongside its independently judged flag outcome.

Examples: Flag Command · GlacierXchange

CTF runtime & evidence formats
trajectory.json
Actions, observations, timings, and judge verdict.
events.jsonl
Model requests/responses, step events, and errors.
challenge-events.jsonl
HTTP method, path, status, and timing, plus judge events, scoped to the run.

DOM snapshots appear in observations; screenshot files are linked when captured.

CTF capture and persistence path

The standalone CTF runner writes local JSON/JSONL evidence through a separate model route. This path is independent of managed gateway capture and does not automatically create an OPSD dataset. Its FUSE persistence test flushes trajectory and event files, recreates the owner sandbox with the same workspace ID, and checks file hashes.

Agent profiles: Claude Code · Codex · OpenClaw · OpenHands. Each profile configures its launcher, model route, and capture adapter.

Persistence and capture contracts

Committed filesystem state survives sandbox replacement. Live processes and uncommitted bytes do not. The FUSE tables retain current state rather than an append-only action history. A PostgreSQL advisory lock and expiring writer lease prevent stale writers from continuing after fencing.

Windows Desktop runs Linux sandboxes in WSL2; Linux deployments use the host’s Docker runtime. Managed model capture and host desktop recording are separate paths. Capture is best effort; incomplete sessions are excluded from the training path. The current OPSD trainer consumes supported text and tool histories, not screen video.

02 / Learning objective

Supervision at recorded token positions.

The gateway implements rejection-sampling fine-tuning (RFT) and a recorded-session form of on-policy self-distillation (OPSD). Complete sessions are judged, annotated, validated, and sealed before an offline update through Tinker.

CE / RFT
Imitate exact recorded tokens from safe turns in sessions judged successful.
Hinted forward KL / OPSD
Bad turns with grounded, validated hints receive distribution targets from the teacher.
Context only
All other retained turns supply history for later decisions, with zero direct loss.

Privileged context. Shared recorded tokens.

Same source weights · offline teacher forcing

Recorded continuation · schematicrecency_filter="24h"

Teacher Frozen / stop-gradient

Recorded context + validated hint

Use day, week, or month.

Student Trainable

Recorded context · no hint

Teacher → student · renormalized top-K forward KL approximation

Both score the original continuation, including the bad call; no replacement answer becomes a target.

Schematic loss · top-K approximation

L ≈ (Σ CE+ λ Σ KLtop-K) / NCE

λ weights distillation; NCE is the selected CE-token count. CE and KL masks are disjoint.

Versioned human review → seal dataset + explicit digest-bound training approval → offline update.

Checkpoint evaluation and promotion are separate from the implemented update. The protocol below defines the proposed comparison.

Method boundaries

Training runs offline on eligible, complete recorded sessions with supported text/tool renderers. Unsupported content and over-context sequences are rejected. Safe turns from successful sessions receive CE; bad turns with validated hints receive KL. Other retained turns remain context, including bad turns whose hints fail validation.

Teacher and student start from the same source weights. The frozen teacher receives validated privileged hints; the student receives none. Both teacher-force the saved continuation. Renormalized teacher top-K targets approximate forward KL, not exact full-vocabulary distillation. CE and KL masks are disjoint and share the selected-CE-token denominator.

Edits advance the human-reviewed revision and invalidate prior validation. Training requires explicit approval bound to the sealed dataset’s SHA-256 digest. An isolated worker uses Tinker for one combined optimizer step and saves training-state and sampler checkpoints. Hint validation checks next responses without executing tools; separate held-out checkpoint evaluation informs promotion.

03 / Research evidence

Complementary studies.

Openrind Shell is the implemented runtime. These complementary DOM-diff and GRPO studies do not measure end-to-end Factory quality.

DOM-diff / Paired audit

W8 DOM-diff Bench

Missing-evidence rate: rubric criteria lacking required evidence in one record but present in its paired record, averaged across runs.

Screenshots
9.85%
W8 DOM-diff
2.10%

97 matched tasks · 3 runs · 619 criteria/run

GRPO / Execution grading

Let Execution Do the Teaching

Compiler and test outcomes supply rewards for GRPO updates to a LoRA adapter. Fixed26 is a C++ development suite; selected trials and training overlap limit interpretation.

C++ tasks in Fixed26
26
Task-trial runs per setup
104

Proposed evaluation protocol

Evaluate on held-out executions.

Pin implementation, harness, and task-set revisions, training-dataset digests, and both checkpoint IDs. Compare baseline and candidate on held-out tasks with matched permissions and budgets. Predeclare executable acceptance checks and promotion thresholds; count failed attempts in cost per accepted task. Re-run prior tasks for retention and report uncertainty over repeated trials.

  • Task completion
  • Cost per accepted task
  • Skill retention