VeriLoop is a coding-intelligence system architecture. VeriLoop Coder-E1 is its open model backend, not the complete agent runtime.
Component
System role
Public status
Distribution and access boundary
VeriLoop Coder-E1
27B model backend for code reasoning, repository understanding, and artifact generation
Public
Distributed in this repository under Apache 2.0, subject to applicable third-party notices
Surface Host PEFT
Detachable model-side behavioral control surfaces produced through narrow-domain PEFT fine-tuning during post-training, covering ToolSpec, Uncertainty, Rollback, and Evidence Binding
Public
Distributed as published repository artifacts under their stated terms
Production Self-Harness
Private execution control plane for contract compilation, evidence routing, tool governance, falsification, repair, re-verification, arbitration, rollback, and evidence-state inheritance
Non-public
Not included in this repository and not licensed merely because the model backend is open
Voder
General-purpose coding agent under development around the VeriLoop model-and-Harness architecture
Non-public / pre-release
Any future access, deployment, or licensing, if offered, will be governed separately by the applicable rights holder or authorized project entity
The architectural relationship is:
text
1VeriLoop Coder-E1 model backend
2 +
3Surface Host PEFT post-training behavioral control surfaces
4 +
5production Self-Harness execution control plane
6 ↓
7Voder — 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:
text
1internal prototype agent runtime
2 +
3pre-release Self-Harness control loop
4 +
5VeriLoop Coder-E1 model backend
6 +
7applicable Surface Host PEFT surfaces
8 +
9benchmark-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:
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:
Check
Required evidence
Model identity
Exact backbone revision, tokenizer revision, and model configuration
Adapter activation
Surface Host loading manifest or logs showing that the intended PEFT artifacts were loaded and executed
Protocol alignment
Active chat_template.jinja, reasoning parser, tool-call parser, EOS/stop rules, and generation configuration
Raw response
Complete OpenAI-compatible JSON, including request ID, finish_reason, message.content, and tool_calls before client-side rendering
Controlled attribution
Same-prompt A/B comparison between the untouched backbone and the adapter-enabled runtime
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:
text
1Generate candidate assistant turn
2 ↓
3Reject empty, truncated, or schema-invalid tool calls before commit
4 ↓
5Roll back to the last valid conversation and tool state
6 ↓
7Reconstruct the call from the observed parser or execution error
8 ↓
9Retry within an explicit attempt, token, and time budget
10 ↓
11Execute only a valid call and capture the real tool receipt
12 ↓
13Verify 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.
Figure 1. 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.
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.
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
Mode
Optimization target
Functional behavior
Flash
Lowest latency
Direct artifact realization with lightweight control and minimal orchestration
Thinking
Balanced quality and cost
Evidence-guided artifact generation with bounded self-check and targeted correction
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:
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;
Stronger coupling between generated artifacts, supporting context, and observable verification evidence
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.
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.
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.
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;
fail visibly rather than silently reporting success.
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.
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.
Current-Task Supremacy
The current request and its exact output contract override old memory, cached templates, prior habits, and unrelated retrieved context.
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.
Inspect Before Editing
Read the relevant entry points, callers, interfaces, tests, repository conventions, selected evidence, and failure signals before changing code.
Produce the Minimal Complete Artifact
Deliver the smallest implementation that fully satisfies the task, preserves required interfaces, and can be validated.
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.
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.
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.
Put Determinism in Code
Parsing, static checks, validation, scoring, self-tests, and reproducible transformations belong in typed deterministic code whenever possible.
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.
Make Every Tool Call Accountable
Every tool, search, retrieval, or execution action must have trigger evidence, an expected output, and a defined downstream consumer.
Checkpoint Long-Running Work
Persist candidate artifacts, validation receipts, repair records, selection results, and progress state so useful work survives interruption and remains auditable.
Preserve Local and Task-Family Conventions
Respect filenames, APIs, paths, repository style, artifact format, language conventions, benchmark constraints, and user-defined operating rules.
Deliver One Artifact with a Verifiable Evidence Chain
Select exactly one final deliverable while retaining the evidence bundle that explains why it was chosen.
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:
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
Property
Value
Model family
VeriLoop Coder-E1
System product direction
Voder — general-purpose coding agent under development
Task-level evidence, official evaluation records, traceability packages
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.
Purpose: verify the adapter configuration, Safetensors files, tensor metadata, base-model binding, and public security boundary without loading the complete 27B backbone.
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.
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.
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.
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.
text
1Included under Apache-2.0:
2 public Coder-E1 weights + published Surface Host PEFT + public repository artifacts
34Not included in this release:
5 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
bibtex
1@misc{veriloop_coder_e1_2026,
2 title = {VeriLoop Coder-E1: Evidence-Bound Self-Harness Loops for Recursive Software Engineering},
3 author = {Wang, Libo},
4 year = {2026},
5 note = {Developed by Tsinghua SIGS Robot Lab; Technical Lead and AI Researcher: Libo Wang},
6 howpublished = {Hugging Face model repository},
7 url = {https://huggingface.co/tsinghua-sigs-robot-lab/veriloop-coder-e1}
8}
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.
