VeriLoop-Coder-E1

<div align="center"> <img src="https://huggingface.co/tsinghua-sigs-robot-lab/veriloop-coder-e1/resolve/main/veriloop_logo.png" width="154" alt="VeriLoop logo"> <h1>VeriLoop Coder-E1</h1> <h3>Open Model Component of the VeriLoop Coding Intelligence System · Apache-2.0</h3> <h3><strong>Open Model Backend · Private Self-Harness Control Plane · Voder Under Development</strong></h3> <h3><strong>Developed by Tsinghua SIGS Robot Lab</strong></h3> <h4><strong>Technical Lead &amp; AI Researcher: Libo Wang</strong></h4> <h4>Contact: <a href="mailto:[email protected]">[email protected]</a></h4> <p> <a href="https://www.apache.org/licenses/LICENSE-2.0"> <img src="https://img.shields.io/badge/License-Apache--2.0-2F80ED?style=flat-square" alt="License: Apache 2.0"> </a> <img src="https://img.shields.io/badge/Backbone-Qwen3.6--27B-6F42C1?style=flat-square" alt="Backbone: Qwen3.6-27B"> <img src="https://img.shields.io/badge/Surface_Host-PEFT-0A7F6F?style=flat-square" alt="Surface Host PEFT"> <img src="https://img.shields.io/badge/Self--Harness-Non--Public-B45309?style=flat-square" alt="Self-Harness: Non-public"> <img src="https://img.shields.io/badge/Voder-In_Development-374151?style=flat-square" alt="Voder: In development"> </p> <p> <a href="#system-boundary-at-a-glance">System Boundary</a> · <a href="#runtime-protocol-and-recovery-guidance">Runtime Protocol</a> · <a href="#benchmark-results">Benchmarks</a> · <a href="#public-self-harness-functional-contract">Self-Harness Contract</a> · <a href="#surface-host-adapter">Surface Host</a> · <a href="#public-loading--surface-host-toolkit">Loading Toolkit</a> · <a href="#open-source-release-and-licensing">Licensing</a> </p> </div>

---

System Boundary at a Glance

VeriLoop is a coding-intelligence system architecture. VeriLoop Coder-E1 is its open model backend, not the complete agent runtime.

The architectural relationship is:

VeriLoop Coder-E1 model backend
            +
Surface Host PEFT post-training behavioral control surfaces
            +
production Self-Harness execution control plane
            ↓
Voder — general-purpose coding agent under development

Why the production Self-Harness is not included

The production Self-Harness remains non-public for ongoing research, product-development, system-integrity, and competitive reasons. It contains the runtime methods that govern task-contract compilation, repository-state management, evidence admission, tool scheduling, validation, targeted repair, candidate arbitration, rollback, stopping conditions, and recursive evidence-state updates.

This boundary is functional rather than cosmetic. Loading the model weights or the published PEFT artifacts does not reconstruct the production execution control plane.

The public release remains fully usable within its stated scope: the distributed Coder-E1 weights, tokenizer and configuration assets, published Surface Host PEFT artifacts, public-safe utilities, documentation, and selected evaluation materials remain available under the licenses attached to those files.

Evaluation attribution

The benchmark results in this model card are system-level evaluation results, not standalone checkpoint scores.

They were produced by an early internal coding-agent runtime in the prototype lineage that now informs Voder. The evaluated configuration comprised:

internal prototype agent runtime
        +
pre-release Self-Harness control loop
        +
VeriLoop Coder-E1 model backend
        +
applicable Surface Host PEFT surfaces
        +
benchmark-native tools, sandbox, and evaluator

Accordingly, the reported scores characterize the complete evaluated model–Harness–agent configuration under each benchmark's native execution and scoring workflow. Loading the Coder-E1 checkpoint or the public PEFT artifacts alone should not be expected to reproduce those results.

The evaluated prototype is not represented as the final Voder product, and the results do not constitute a commitment regarding Voder's eventual release scope, availability, capabilities, or schedule.

Public implementation guidance

Developers may use the open weights, published Surface Host PEFT artifacts, public-safe utilities, the public 14-rule engineering contract, and the following essay as inputs to an independently designed Harness:

Technical essay: VeriLoop: When Evidence-Governed Correction Enters the Future, Recursive Self-Evolution Begins

The essay provides conceptual and architectural guidance; it does not disclose the production Self-Harness implementation. Independent systems may differ materially in evidence routing, tool governance, validation coverage, repair policy, memory design, execution isolation, and stopping behavior. No representation or guarantee is made that an independent implementation will reproduce the private runtime or its benchmark performance.

Access to non-public Voder or production Self-Harness components, if offered, will require a separate written agreement with the applicable rights holder or authorized project entity. This requirement does not restrict the Apache 2.0 rights granted for the public files actually distributed in this repository.

Public functional disclosure

This model card discloses the Self-Harness functional contract: its system roles, evidence semantics, stage boundaries, and model-visible engineering discipline. It does not disclose production prompts, orchestration code, routing policies, scoring functions, thresholds, memory schemas, anti-contamination controls, private data pipelines, or deployment infrastructure.

Design principle: evidence-governed correction

Evidence in VeriLoop is corrective rather than decorative. It must be capable of changing the system's current interpretation, selected action, validation plan, or next inquiry.

A system does not improve merely because it can change itself. Recursive self-improvement begins only when evidence changes how the system will change itself in the future.

Runtime Protocol and Recovery Guidance

Why this matters: The public release includes the VeriLoop Coder-E1 model backend and its PEFT-based Surface Host artifacts, but the production Self-Harness is non-public and is not distributed in this repository. Public users therefore run these components inside their own serving stack, agent client, or independently developed Harness. In that setting, the tokenizer, chat template, parsers, stop semantics, client commit logic, and recovery loop become part of the observed system behavior rather than invisible implementation details.

Establish a repository-native baseline before building a custom Harness

Developers should first use the exact designated Qwen3.6-27B revision, the repository-shipped tokenizer, and the model's built-in chat_template.jinja, while keeping the reasoning parser, tool-call parser, assistant/tool turn delimiters, EOS/stop rules, and generation configuration consistent with that template. This is not an arbitrary deployment restriction: it preserves the token, role, tool-call, and termination boundaries expected by the model and its parsers, creating a stable baseline from which model behavior can be distinguished from third-party runtime behavior.

After that baseline has been verified, developers may integrate a third-party agent client or build their own Harness intelligence system around the public model-and-adapter boundary. Protocol changes should be introduced one at a time and validated against raw responses and same-prompt A/B tests. A community-modified template should therefore be treated as a new protocol implementation, not as a drop-in formatting change.

A template or parser mismatch can alter special-token placement, tool-call delimiters, role transitions, or termination semantics. The resulting symptoms may include premature finish_reason=stop, an empty assistant turn, a malformed tool call, or a valid tool intention that the client fails to recognize. Because the private Self-Harness is absent, those recoverable faults may be exposed directly unless the developer's own runtime detects and repairs them. A recurring finish_reason=stop is therefore a runtime signal, not by itself evidence that the model or PEFT artifacts are ineffective.

Before attributing such behavior to the weights, verify all of the following under the same prompt and decoding settings:

Observed behavior in a third-party agent should be attributed to the complete deployed stack—model, adapters, template, parsers, serving runtime, client, and agent loop—until these variables have been isolated.

Build an independent recovery Harness when the private Self-Harness is unavailable

Because the production Self-Harness is non-public, developers who require agent-grade reliability should place their own validation and recovery Harness around the verified repository-native baseline. At minimum, that Harness should prevent recoverable protocol faults from reaching the user through the following transaction boundary:

Generate candidate assistant turn
        ↓
Reject empty, truncated, or schema-invalid tool calls before commit
        ↓
Roll back to the last valid conversation and tool state
        ↓
Reconstruct the call from the observed parser or execution error
        ↓
Retry within an explicit attempt, token, and time budget
        ↓
Execute only a valid call and capture the real tool receipt
        ↓
Verify postconditions; commit only verified state, otherwise fail explicitly

In operational terms: validate every tool call before commitment; on an empty, truncated, or malformed call, restore the last valid state, rebuild and retry it within a bounded budget, then continue only after the tool result has been executed and verified. This is a public implementation pattern, not a disclosure or reproduction of the private VeriLoop Self-Harness.

Diagnosing duplicated final messages

If tool execution occurs once but the final natural-language confirmation is repeated verbatim, inspect the raw OpenAI-compatible response before changing model settings. If the raw response contains only one assistant message, the duplication is downstream: the client may be committing both the reconstructed streaming output and the final response, appending an internal summary beside the raw assistant message, or firing the completion callback twice. The client should consume either the reconstructed stream or the final response, invoke the final commit once, and deduplicate by request or message ID.

Benchmark Results

Evaluation unit: internal prototype coding-agent runtime + pre-release Self-Harness control loop + VeriLoop Coder-E1 + applicable Surface Host PEFT surfaces + benchmark-native execution and evaluation stack.

<p align="center"> <a href="https://huggingface.co/tsinghua-sigs-robot-lab/veriloop-coder-e1/tree/main/.eval_results"><strong>Evaluation metadata</strong></a> &nbsp;·&nbsp; <a href="https://huggingface.co/datasets/tsinghua-sigs-robot-lab/veriloop-coder-e1-evaluation-evidence"><strong>Evaluation evidence repository</strong></a> &nbsp;·&nbsp; <a href="https://huggingface.co/tsinghua-sigs-robot-lab/veriloop-coder-e1/blob/main/Benchmark%20Results.png"><strong>Full-resolution figure</strong></a> </p> <p align="center"> <a href="https://huggingface.co/tsinghua-sigs-robot-lab/veriloop-coder-e1/blob/main/Benchmark%20Results.png"> <img src="https://huggingface.co/tsinghua-sigs-robot-lab/veriloop-coder-e1/resolve/main/Benchmark%20Results.png" width="100%" alt="VeriLoop Coder-E1 comparative benchmark results for models below 32B parameters and all listed models"> </a> </p> <p align="center"> _{<strong>Figure 1.</strong> Comparative benchmark snapshot as of 27 July 2026. Panel (a) restricts the comparison to models below 32B parameters; panel (b) shows the all-model view represented in the published snapshot. The figure is a static comparative record and may not reflect subsequent leaderboard updates.} </p>

These are agent-system results, not checkpoint-only measurements. The prototype runtime generated the task artifacts, while each benchmark's native evaluator determined the reported outcome. Where published, the evidence packages bind task identity, generated artifact, execution or evaluation record, and integrity metadata to support task-level inspection.

Publication of a score, figure, or evidence package does not by itself imply endorsement, certification, or independent verification by a benchmark maintainer.

Voder: Development Direction

Voder is the working name of the general-purpose coding agent under development by the VeriLoop team. It is intended to integrate the private Self-Harness control plane with VeriLoop Coder-E1 so that repository state, tool execution, evidence admission, validation, targeted repair, rollback, candidate selection, and long-running task state are governed as one auditable software-engineering process.

The public repository provides the model-side foundation for that direction. The four benchmark evaluations are early internal systems experiments in Voder's technical lineage; they are not claims that the open checkpoint reproduces the complete agent, nor that the evaluated prototype is the final Voder product.

The long-term research objective is bounded recursive improvement: validated failure and repair evidence should improve how later tasks are framed, investigated, checked, and corrected. This is not unrestricted self-modification. The recursion remains constrained by current-task supremacy, evidence admission, explicit budgets, deterministic validation, rollback, safe stopping, benchmark-locked evaluation, and one selected deliverable with a verifiable evidence chain.

Voder remains under active development. Its eventual release scope, availability, capabilities, commercial terms, and schedule have not yet been determined.

Public Self-Harness Functional Contract

The following describes the public functional contract of the VeriLoop Self-Harness. It specifies the required engineering stages and evidence semantics, but not the private Voder implementation, prompts, thresholds, routing code, or arbitration policy.

Current task
    ↓
Contract compilation
    ↓
Evidence admission → Candidate realization
    ↓
Falsification → Gap-driven exploration
    ↓
Surgical repair → Re-verification
    ↓
Selection or rollback
    ↓
One final deliverable + next-loop evidence

Phase A — Contract compilation

Resolve the task family, repository scope, required artifact, interfaces, constraints, acceptance conditions, uncertainty, tool budget, and explicit halt conditions into one active engineering contract.

Phase B — Evidence admission and candidate realization

Admit only repository context, tests, traces, tool receipts, selected references, and prior prevention rules that can change the artifact. Generate a complete candidate under that bounded evidence state.

Phase C — Falsification and counterevidence

Challenge the candidate against task intent, repository interfaces, tests, contradictions, unsupported assumptions, and observable failure signals. Syntactic validity or plausibility alone is not sufficient.

Phase D — Gap-driven exploration

Trigger retrieval, search, reverse analysis, sandbox execution, or additional model work only for a decisive unresolved gap. Every action must have trigger evidence, an expected output, and a defined downstream consumer.

Phase E — Surgical repair and re-verification

Convert the observed failure into a focused repair constraint, correct the smallest broken invariant, preserve unaffected surfaces, and re-run the same contract-aware checks.

Phase F — Selection, rollback, and evidence inheritance

Select exactly one eligible deliverable, or stop and roll back when the evidence does not support delivery. Persist validation receipts, failure class, repair outcome, halt reason, and reusable prevention evidence for later loops.

The operating semantics are compact:

Evidence → Falsification → Exploration → Repair ↺

Re-verification completes Repair; a verified outcome becomes next-loop Evidence. This is how VeriLoop converts generation into bounded, auditable engineering rather than uncontrolled retry.

---

Expert Convergence Mode

Expert Mode uses a richer bounded convergence loop for difficult software-engineering tasks.

It is designed for:

• repository-scale changes with hidden invariants;
• ambiguous failures requiring evidence synthesis;
• cross-file API or behavior changes;
• tasks with multiple plausible repairs;
• cases where a first candidate should be challenged before delivery.

At a functional level, Expert Mode adds:

• richer contract and evidence compilation;
• multiple candidate opportunities where justified;
• independent validation and failure classification;
• focused repair cycles;
• candidate comparison and quality arbitration;
• strict selected-artifact delivery;
• explicit safe stopping when no candidate satisfies the required threshold.

The exact prompts, thresholds, orchestration order, candidate scoring, repair policies, and routing logic are proprietary.

Runtime Modes

---

Surface Host Adapter

The Surface Host Adapter is VeriLoop's detachable model-side post-training adaptation plane. It hosts the published PEFT artifacts, produced through narrow-domain PEFT fine-tuning, as explicit behavioral control surfaces without redefining or mathematically rewriting the frozen backbone.

The four published PEFT surfaces are model-side behavioral control artifacts designed to interoperate with the private Self-Harness interfaces used in the Voder development lineage. They specialize signal formation for tool contracts, uncertainty, rollback, and evidence binding; they do not contain or reproduce the orchestration, routing, validation, repair, arbitration, or stopping policy of the private runtime.

This layer must be understood in the correct architectural order:

Self-Harness = core governing technology
Surface Host Adapter = external adaptation host
Narrow-domain PEFT artifacts = hosted behavioral surfaces

The PEFT surfaces are therefore not the core of VeriLoop, not a substitute for the backbone, and not a substitute for the Self-Harness. They are purpose-built auxiliary components whose value is realized when the Harness uses their signals to improve contract sensitivity, evidence handling, escalation, repair, rollback, and delivery control.

External injection model

The public PEFT artifacts remain logically separate from the distributed model weights. The current published adapters target explicit surface_host.* modules rather than the raw backbone's attention or MLP projections. They must therefore be hosted through the public Surface Host scaffold and wrapper; they are not ordinary backbone LoRA adapters and must not be presented as if they were mathematically merged into the Qwen checkpoint. The original backbone remains unchanged.

The optional packaging utility performs a mergeability preflight. For the current surface_host.* adapters, its correct result is a co-packaged deployment bundle containing the backbone assets and four detachable adapter directories—not a mathematical weight merge.

This architecture provides three important properties:

• separation of concerns — the backbone retains general coding and reasoning capability, while each PEFT surface contributes a narrowly defined behavioral bias;
• detachable composition — published surfaces can be loaded, removed, evaluated, or replaced independently of the original checkpoint;
• Harness-centered control — the Self-Harness remains the governing layer that determines how task contracts, evidence, validation, and repair consume the resulting surface signals.

The Surface Host Adapter is not a single fifth adapter. It is the host boundary for multiple specialized adaptation surfaces.

This design separates three kinds of capability:

• backbone capability — code understanding, generation, reasoning, and language competence;
• surface capability — narrow-domain sensitivity learned during post-training through PEFT fine-tuning;
• Harness capability — evidence admission, falsification, exploration, repair, re-verification, arbitration, and recursive evidence evolution.

The current public adaptation surfaces are:

What the post-training adaptation plane improves

The narrow-domain post-training, implemented through PEFT fine-tuning, is intended to materially strengthen:

• tool-call and schema discipline;
• contract adherence before generation;
• repository-aware code planning;
• evidence-sensitive reasoning;
• uncertainty-triggered escalation;
• validator-aware repair behavior;
• rollback and correction boundaries;
• artifact-only delivery discipline;
• claim, source, and validation alignment;
• consistency across long, multi-stage coding workflows.

These adapters are optimized as behavioral control surfaces, not as isolated leaderboard specialists. Their main value appears when they are hosted by the Surface Host Adapter and coordinated by the Self-Harness, where adapter signals can influence routing, evidence injection, repair control, and delivery policy.

Adapter-only loading does not reproduce the complete production system.

---

Public Rule Lineage: Karpathy → Forrest Chang → Mnilax → Libo Wang

The public VeriLoop rule system has a documented intellectual lineage.

1. Andrej Karpathy's original observations. In January 2026, Karpathy publicly described recurring coding-agent failure modes: silent assumptions, unmanaged confusion, overcomplication, unnecessary adjacent edits, and weak success criteria.
2. Forrest Chang's four-rule operationalization. Forrest Chang converted those observations into a compact CLAUDE.md behavior contract containing four principles: Think Before Coding, Simplicity First, Surgical Changes, and Goal-Driven Execution. These are referred to here as the Karpathy-origin Golden Four, while credit for packaging them into the formal four-rule repository belongs to Forrest Chang.
3. Mnilax's eight agent-era additions. In May 2026, Mnilax published eight additional controls for newer agentic failure modes:
   • use the model for judgment calls, and keep deterministic decisions in code;
   • enforce hard token and execution budgets;
   • surface conflicting patterns instead of averaging them;
   • read relevant code before writing;
   • make tests verify intent rather than appearance;
   • checkpoint significant multi-step work;
   • follow repository conventions unless explicitly changing them;
   • fail visibly rather than silently reporting success.
4. VeriLoop's adaptation. VeriLoop materially rewrites and extends this 4+8 lineage into a 14-rule public Self-Harness contract organized around task supremacy, evidence admission, falsification, targeted exploration, surgical repair, deterministic enforcement, checkpointing, traceability, and domain-overlay isolation.

The VeriLoop rules are not presented as Karpathy's, Forrest Chang's, or Mnilax's exact text, nor as an official collaboration with those authors. They are an attributed adaptation for VeriLoop's evidence-bound Self-Harness architecture.

Primary references

• Andrej Karpathy's original X post: https://x.com/karpathy/status/2015883857489522876
• Forrest Chang's four-rule repository (currently hosted under multica-ai): https://github.com/multica-ai/andrej-karpathy-skills
• Mnilax's original eight-rule extension on X, published 9 May 2026: https://x.com/Mnilax/status/2053116311132155938

The Libo Wang 14-Rule Public Self-Harness Contract

The following rules are intentionally public. They form the model-visible engineering discipline shared across VeriLoop coding modes.

1. Current-Task Supremacy
   The current request and its exact output contract override old memory, cached templates, prior habits, and unrelated retrieved context.

2. Escalate on Evidence, Not Instinct
   Trigger search, reverse analysis, sandbox execution, or repair only when concrete uncertainty, missing evidence, or a failed contract justifies the cost.

3. Inspect Before Editing
   Read the relevant entry points, callers, interfaces, tests, repository conventions, selected evidence, and failure signals before changing code.

4. Produce the Minimal Complete Artifact
   Deliver the smallest implementation that fully satisfies the task, preserves required interfaces, and can be validated.

5. Repair the Broken Invariant, Not the Whole System
   Prefer a precise correction of the failing region. Rewrite broadly only when evidence proves that local repair cannot restore correctness.

6. Validate Intent, Not Appearance
   Syntax, formatting, and imports are necessary checks; the decisive test is whether the artifact satisfies the user's actual functional intent.

7. Surface Failure; Never Simulate Success
   Keep failures, skipped checks, degraded states, and unknowns explicit in Harness evidence. Never claim execution, validation, or success that did not occur.

8. Put Determinism in Code
   Parsing, static checks, validation, scoring, self-tests, and reproducible transformations belong in typed deterministic code whenever possible.

9. Treat Budget as an Execution Contract
   Use token, tool, time, and compute budgets deliberately. The requested deliverable receives priority over commentary, duplicated context, and optional explanation.

10. Make Every Tool Call Accountable
    Every tool, search, retrieval, or execution action must have trigger evidence, an expected output, and a defined downstream consumer.

11. Checkpoint Long-Running Work
    Persist candidate artifacts, validation receipts, repair records, selection results, and progress state so useful work survives interruption and remains auditable.

12. Preserve Local and Task-Family Conventions
    Respect filenames, APIs, paths, repository style, artifact format, language conventions, benchmark constraints, and user-defined operating rules.

13. Deliver One Artifact with a Verifiable Evidence Chain
    Select exactly one final deliverable while retaining the evidence bundle that explains why it was chosen.

14. Separate Core Discipline from Domain Overlays
    Apply specialized domain or benchmark rules only when the current task requires them, and never allow an overlay to override the current request.

---

Core Technical Advantages

Evidence binding over prompt accumulation

VeriLoop does not equate more context with better context. Raw findings are compiled into constraints, selected evidence, and validation targets before they reach generation.

Native artifact routing

Repository patches, polyglot source files, shell tasks, functions, configuration files, and structured outputs are handled as distinct artifact families rather than being forced into a single Python-centric path.

Deterministic–generative separation

The model handles ambiguity, synthesis, and repair hypotheses. Deterministic components handle parsing, structural checks, contract enforcement, receipts, and reproducible transformations.

Failure-aware convergence

Validation failures are preserved as evidence. The system distinguishes an invalid candidate, a missing dependency, a degraded tool, an unverified assumption, and a genuine task failure instead of collapsing them into a generic retry.

Safe stopping

When evidence does not support delivery, the system can stop with an explicit failure record rather than manufacturing a confident result.

Task-level traceability

Evaluation packages can bind a task identity to the generated artifact and the corresponding official evaluation record, allowing third parties to inspect the complete task-level chain.

---

Current Public Repository Contents

The repository contains the open model component of the VeriLoop system, published adaptation artifacts, and selected evaluation and traceability materials. Unless a file states otherwise, the repository's original VeriLoop artifacts are distributed under the Apache License 2.0, subject to applicable third-party licenses and notices.

Backbone and runtime-compatible files

• sharded safetensors model weights;
• model and generation configuration;
• tokenizer and preprocessing assets;
• Hugging Face-compatible loading metadata;
• public-safe loading, hosting, verification, and packaging utilities:
  • load_veriloop_coder_e1_surface_host_adapter_publicsafe.py;
  • veriloop_coder_peft_host_publicsafe.py;
  • surface_host_wrapper_publicsafe.py;
  • merge_veriloop_adapters_into_backbone_publicsafe.py.

Narrow-domain post-training artifacts

Each public Surface Host PEFT directory may include:

• adapter weights and adapter configuration;
• tokenizer assets;
• best-checkpoint records;
• epoch history;
• host manifests;
• adapter plans;
• training-result summaries;
• sanitized training and evaluation records;
• training manifests;
• specialized surface heads where published.

Public Surface Host PEFT roots:

surface_host_peft_toolspec_adapter/adapter/
surface_host_peft_uncertainty_adapter/adapter/
surface_host_peft_rollback_adapter/adapter/
surface_host_peft_evidence_binding_adapter/adapter/

These directories contain the published narrow-domain post-training products, produced through PEFT fine-tuning and used as external Surface Host Adapter attachments. They were developed to align with Voder's private task-contract, evidence, uncertainty, rollback, and verification interfaces. They are support layers for Self-Harness operation, not standalone substitutes for either the Self-Harness or Voder.

Evaluation and traceability artifacts

The repository also publishes selected evidence packages for:

• SWE-bench Verified;
• SWE-bench Pro;
• Terminal-Bench 2.0;
• DeepSWE.

These packages are designed to support task-level inspection across:

task identity → prototype-generated artifact → native evaluation record

Publication of an evidence package does not imply independent third-party verification unless explicitly stated.

---

What Remains Private

The Apache 2.0 release applies to the model weights and public repository artifacts. It does not automatically license private VeriLoop components that are not distributed here.

For strategic and competitive reasons, the production Self-Harness and the developing Voder runtime remain private at this stage. The protected boundary includes:

• exact Self-Harness orchestration and stage implementation;
• Voder runtime code, service interfaces, deployment packages, and operator tooling;
• internal prompt compiler and model-visible packet construction;
• evidence routing, ranking, admission, and contamination controls;
• tool scheduling, repository-state management, and execution governance;
• candidate scoring, repair arbitration, rollback policy, and delivery thresholds;
• private memory schemas, evidence inheritance, and evolution policies;
• sandbox, worktree, permission, and observability infrastructure;
• full proprietary training data and data-construction pipelines;
• internal benchmark routing and anti-overfitting controls.

The public model card describes the functional architecture and exposes bounded implementation guidance; it does not release the executable production Harness. The public 14-rule contract is a behavioral interface disclosure, not the Voder runtime.

Use of the public model and published artifacts follows their stated Apache 2.0 terms. Access to non-public Voder or production Self-Harness components, if offered, requires a separate written agreement with the applicable rights holder or authorized project entity.

---

Model Overview

---

Recommended Use Cases

VeriLoop Coder-E1 is intended for:

• repository understanding and codebase navigation;
• bug localization and surgical repair;
• patch drafting and validation;
• cross-file API changes;
• tool-mediated software-engineering agents;
• terminal and automation tasks;
• validator-aware repair workflows;
• evidence-grounded coding assistance;
• benchmark and evaluation research;
• long-running engineering tasks requiring checkpoints and auditability.

---

Public Loading & Surface Host Toolkit

Public scope. These utilities expose the released model, the four published Surface Host PEFT artifacts, and their public loading boundary.

Private boundary. They do not include Voder, the production Self-Harness, orchestration policies, routing thresholds, prompt compiler, repair arbitration, benchmark runtime, or commercial serving stack.

Runtime baseline. Because the private Self-Harness is not included, first preserve the repository-native protocol by using the designated Qwen3.6-27B revision, repository-shipped tokenizer, and built-in chat_template.jinja, with matching parsers and EOS/stop semantics. Once this baseline is verified, developers may integrate a third-party client or build an independent Harness using the guidance in Runtime Protocol and Recovery Guidance.

Toolkit at a glance

Repository layout

Run the commands from the repository root after downloading the model files and all four published adapter directories:

.
├── config.json
├── model.safetensors.index.json
├── veriloop-coder-e1-model-*.safetensors
├── load_veriloop_coder_e1_surface_host_adapter_publicsafe.py
├── veriloop_coder_peft_host_publicsafe.py
├── surface_host_wrapper_publicsafe.py
├── merge_veriloop_adapters_into_backbone_publicsafe.py
├── surface_host_peft_toolspec_adapter/
│   └── adapter/
├── surface_host_peft_uncertainty_adapter/
│   └── adapter/
├── surface_host_peft_rollback_adapter/
│   └── adapter/
└── surface_host_peft_evidence_binding_adapter/
    └── adapter/

Environment preparation

python -m pip install torch transformers peft safetensors accelerate huggingface_hub
mkdir -p public_loading_reports

---

Step 1 — Validate one published adapter

Purpose: verify the adapter configuration, Safetensors files, tensor metadata, base-model binding, and public security boundary without loading the complete 27B backbone.

Example: Evidence Binding

python load_veriloop_coder_e1_surface_host_adapter_publicsafe.py \
  --base-model . \
  --adapter-source . \
  --adapter-subfolder surface_host_peft_evidence_binding_adapter/adapter \
  --verify-only \
  --manifest-out public_loading_reports/evidence_binding_adapter_manifest.json

Output

public_loading_reports/evidence_binding_adapter_manifest.json

Repeat the same command with any of the following adapter subfolders:

surface_host_peft_toolspec_adapter/adapter
surface_host_peft_uncertainty_adapter/adapter
surface_host_peft_rollback_adapter/adapter
surface_host_peft_evidence_binding_adapter/adapter

Technical boundary: the current adapters target explicit surface_host.* modules. They are not ordinary raw-backbone LoRA targets and must not be presented as direct PeftModel.from_pretrained(base_model, ...) attachments to the unmodified Qwen backbone.

---

Step 2 — Load the frozen backbone and create the public PEFT host

Purpose: load the distributed backbone exactly once, preserve the frozen-backbone boundary, instantiate the explicit surface_host module tree, and export a public host manifest.

python veriloop_coder_peft_host_publicsafe.py \
  --backbone . \
  --local-files-only \
  --dtype bf16 \
  --device-map auto \
  --manifest-out public_loading_reports/peft_host_manifest.json

Output

public_loading_reports/peft_host_manifest.json

Security default: remote model code is disabled. Enable it only for a pinned repository revision that genuinely requires custom code and has been independently reviewed.

---

Step 3 — Load and execute all four Surface Host adapter weights

Purpose: load the ToolSpec, Uncertainty, Rollback, and Evidence Binding Safetensors into detachable host-side modules and run a bounded forward smoke test.

python surface_host_wrapper_publicsafe.py \
  --repo-root . \
  --runtime-mode full \
  --timeout-s 120 \
  --emit-report public_loading_reports/surface_host_report.json \
  --emit-injection-text public_loading_reports/surface_host_signal_packet.txt

Outputs

public_loading_reports/surface_host_report.json
public_loading_reports/surface_host_signal_packet.txt

This command:

• loads all four published adapter families independently;
• verifies real adapter-weight hosting and host-side forward execution;
• keeps the raw backbone unchanged;
• does not monkey-patch or rename backbone modules;
• does not disclose the private production routing policy that consumes the resulting signals.

---

Step 4 — Build a deployable model-and-adapter package

Purpose: perform mergeability preflight and create one deployment directory containing the model assets and all four detachable Surface Host adapters.

python merge_veriloop_adapters_into_backbone_publicsafe.py \
  --base-model . \
  --toolspec-adapter surface_host_peft_toolspec_adapter/adapter \
  --evidence-adapter surface_host_peft_evidence_binding_adapter/adapter \
  --rollback-adapter surface_host_peft_rollback_adapter/adapter \
  --uncertainty-adapter surface_host_peft_uncertainty_adapter/adapter \
  --output-dir veriloop_coder_e1_surface_host_package \
  --preflight-mergeability \
  --package-if-not-mergeable \
  --base-file-mode hardlink_or_copy \
  --adapter-file-mode copy \
  --force \
  --backup-existing \
  --json-out public_loading_reports/surface_host_package_report.json

Expected result for the current release

packaged_not_mathematically_merged

The current adapters target surface_host.*, not raw-backbone attention or MLP projections. The technically correct deployment artifact is therefore a package containing the frozen backbone assets and four detachable adapter directories—not a claim that the adapters were mathematically merged into the original checkpoint.

Recommended public workflow

Adapter verification (optional)
        │
        ▼
Frozen-backbone / host compatibility check
        │
        ▼
Four-adapter Surface Host loading and forward smoke test
        │
        ▼
Deployment packaging (optional)

These scripts expose only the released model-and-adapter boundary. They do not reproduce Voder. Developers may use the public architecture, 14-rule contract, and technical essay to design an independent Harness, but equivalence with the private Voder runtime or its benchmark behavior is not guaranteed.

Limitations

• The distributed backbone, the four Surface Host PEFT artifacts, and the public utilities do not reproduce Voder or the production Self-Harness.
• The reported benchmark scores are system-level results from an internal prototype agent configuration and must not be interpreted as checkpoint-only performance or as results from a final Voder product.
• Independent Harness implementations may differ materially in routing, tool use, evidence quality, repair policy, stopping behavior, and final results.
• Community-modified chat templates, mismatched parsers, custom EOS/stop rules, or third-party client behavior can cause premature termination, malformed tool calls, or duplicated final messages even when the model and adapters are loaded correctly.
• Without an independent validation, rollback, and bounded-retry loop, recoverable protocol faults may be exposed directly to the user because the production Self-Harness is not included in the public release.
• Coding outputs may still be incorrect, incomplete, insecure, or incompatible with the target environment.
• Validation quality depends on available repository context, tests, tools, permissions, and execution environments.
• Long-context operation requires appropriate accelerator memory and KV-cache planning.
• External documentation and retrieved evidence may be stale, incomplete, or conflicting.
• Safe stopping reduces unsupported delivery but cannot eliminate all false positives or false negatives.
• Published evaluation evidence should be interpreted according to its stated verification status.

---

Safety and Responsible Use

Generated code should be treated as an engineering proposal until validated.

Recommended safeguards:

• run generated code in isolated environments;
• inspect shell commands and dependency changes before execution;
• use tests, static analysis, security review, and repository-specific checks;
• preserve rollback points for destructive operations;
• require human review for high-impact or security-sensitive changes;
• do not infer successful execution from plausible-looking output;
• keep credentials, private repositories, and sensitive logs outside uncontrolled prompts.

---

Open-Source Release and Licensing

VeriLoop Coder-E1 is released as an open-source model under the Apache License 2.0.

The model weights and original VeriLoop artifacts distributed in this repository may be used, reproduced, modified, redistributed, and deployed—including in commercial applications—provided that users comply with the Apache License 2.0 and preserve any required license and notice information.

This grant covers the public repository artifacts, including:

• distributed model weights;
• model configuration and tokenizer assets;
• published Surface Host PEFT adapter artifacts;
• public-safe loading, hosting, verification, and packaging utilities;
• original manifests, compatibility files, and published evaluation materials, except where a file states a different license.

Third-party components, upstream model materials, datasets, benchmark assets, and externally sourced content remain subject to their respective licenses and terms.

The Apache 2.0 release does not include Voder, the private production Self-Harness implementation, internal prompts, orchestration code, evidence-routing logic, repair and rollback policy, private training data, proprietary data-construction pipelines, or serving infrastructure unless those components are published separately under an explicit license.

Included under Apache-2.0:
  public Coder-E1 weights + published Surface Host PEFT + public repository artifacts

Not included in this release:
  private Self-Harness + Voder runtime + unpublished internal systems

Access to or deployment of non-public Voder and production Self-Harness components, if offered, requires a separate written agreement with the applicable rights holder or authorized project entity. This requirement does not reduce or override the Apache 2.0 rights attached to the public files actually distributed in this repository.

Use of the open model or its published PEFT surfaces does not imply endorsement, certification, warranty, or support by VeriLoop Lab, Tsinghua University, or any affiliated organization. The public artifacts are provided under the terms and warranty limitations of the Apache License 2.0.

---

Citation

@misc{veriloop_coder_e1_2026,
  title        = {VeriLoop Coder-E1: Evidence-Bound Self-Harness Loops for Recursive Software Engineering},
  author       = {Wang, Libo},
  year         = {2026},
  note         = {Developed by Tsinghua SIGS Robot Lab; Technical Lead and AI Researcher: Libo Wang},
  howpublished = {Hugging Face model repository},
  url          = {https://huggingface.co/tsinghua-sigs-robot-lab/veriloop-coder-e1}
}

---

Acknowledgements

VeriLoop Coder-E1 builds on a Qwen3.6-27B-compatible foundation and the broader open machine-learning tooling ecosystem.

The public Harness discipline acknowledges:

• Andrej Karpathy, whose public observations identified recurring coding-agent failure modes;
• Forrest Chang, who operationalized those observations into the compact four-principle andrej-karpathy-skills repository;
• Mnilax, who published eight additional agent-era rules in May 2026;
• the communities behind Transformers, PEFT, Safetensors, vLLM, software-engineering benchmarks, repository-level evaluation, and reproducible model deployment.

VeriLoop's 14-rule contract is a materially adapted public technology layer of the Self-Harness. The production Self-Harness and Voder runtime—including proprietary orchestration, prompts, routing, scoring, repair, memory, training systems, and production controls—remain private.

---

A Note from the Author

VeriLoop was built through an unconventional research path. I entered this work without a conventional software-engineering background, and the project developed through skepticism, rejection, repeated failure, and sustained iteration.

The lesson I take from that experience is not that persistence can replace rigor. It is that original hypotheses, disciplined evidence, transparent limitations, and engineering execution can allow unconventional researchers to produce work that deserves evaluation on its technical merits.

I present VeriLoop neither as a claim to personal infallibility nor as a request for approval. I present it as an argument for intellectual independence: criticism should be answered with reproducible artifacts, explicit boundaries, stronger evidence, and better systems.

— Libo Wang