Spaces:
Configuration error
Configuration error
| # VeriLoop | |
| **VeriLoop (循证)** is an evidence-driven model family and runtime initiative built around **E³-Loop**, a closed-loop reasoning architecture created and designed by **Libo Wang**. | |
| VeriLoop is not positioned as another general chat model optimized only for response fluency or benchmark-facing conversation quality. It is built to turn open-weight models into **evidence-governed, executable, verifiable, revisable, and auditable runtime systems** that can operate inside real workflows. | |
| --- | |
| ## Overview | |
| Most model efforts still treat the model checkpoint as the final product. | |
| VeriLoop takes a different view: the checkpoint is only the **cognitive substrate**. The real system value emerges when reasoning, evidence, execution, validation, revision, rollback, and stopping criteria are organized into one runtime control architecture. | |
| At the center of the VeriLoop family is **E³-Loop**, which shifts the goal of language models: | |
| - from best-effort generation to **budget-bounded convergence toward truth** | |
| - from static prompting to **stateful evidence-governed control** | |
| - from isolated outputs to **closed-loop execution and verification** | |
| - from one-off fine-tuning cycles to **portable runtime capability transfer** | |
| VeriLoop is therefore not only a model family. It is a proposal for redefining what a base model should become in the open-weight era. | |
| --- | |
| ## Why VeriLoop is Different | |
| VeriLoop is not simply building another model that can chat. | |
| It is building an **evidence-driven, executable, rollback-capable, and auditable runtime architecture**. | |
| Many model stacks are still primarily compared by parameter count, conversational smoothness, or single-turn benchmark performance. VeriLoop is built to solve a different problem: **how a model can retrieve evidence, make decisions, execute actions, detect contradiction, revise minimally, and stop under explicit budget constraints**. | |
| That is the difference between generating an answer and running a **truth-seeking closed loop**. | |
| At the same time, VeriLoop is not a single undifferentiated assistant. It is organized as a **professional model family aligned to distinct workflow classes**: | |
| - **VeriLoop Coder** — high-intensity software engineering, repository understanding, test repair, CI debugging, and toolchain-closed execution | |
| - **VeriLoop Interaction** — high-quality multi-turn interaction, long-context continuity, intent understanding, and controllable tool collaboration | |
| - **VeriLoop Skills** — robotic and agent task orchestration, converting natural-language goals into executable skill sequences, action constraints, and step-level planning | |
| - **VeriLoop VLA** — embodied perception-to-action convergence for real-world visuomotor execution | |
| - **VeriLoop Scientist** — hypothesis generation, literature-grounded evidence gathering, contradiction discovery, simulation-based verification, differential revision, and research-plan formation | |
| - **VeriLoop Computer Use** — enterprise knowledge work and digital-interface execution across browsers, desktop software, and document systems, with retrieval, action, validation, and rollback loops | |
| For this reason, VeriLoop should not be understood as a generic assistant. | |
| It is a **family of specialized execution-oriented models** designed to deliver results inside real workflows. | |
| --- | |
| ## If Someone Asks: “Why not just use Doubao?” | |
| If the evaluation criterion is only casual conversation quality or generic question-answering scores, then comparing directly to a mainstream assistant is natural. | |
| But **that is not the point of VeriLoop**. | |
| VeriLoop does not aim to become “another general chat model.” | |
| Its purpose is to provide a **runtime substrate** that can attach to compatible open-weight backbones and elevate them through **evidence gating, sandbox verification, differential revision, rollback discipline, budget governance, and API-oriented runtime control**. | |
| In other words: | |
| - a general assistant is mainly judged by how well it answers; | |
| - **VeriLoop is judged by whether it can complete a high-value workflow with evidence, validation, rollback, and auditability preserved**. | |
| This is why VeriLoop matters even when compared against strong general assistants. | |
| The target is not superficial similarity. The target is **reliable closed-loop execution**. | |
| --- | |
| ## The E³-Loop View | |
| E³-Loop is the architectural core of the VeriLoop family. | |
| It is not a thin wrapper around an LLM, and it is not a cosmetic agent shell. | |
| It is a **runtime control plane** that organizes: | |
| - state | |
| - uncertainty | |
| - budget | |
| - evidence | |
| - claims | |
| - actions | |
| - execution | |
| - rollback | |
| - trace logging | |
| - termination | |
| into one auditable reasoning loop. | |
| In the VeriLoop view, a capable model should not simply produce plausible text. | |
| It should be able to: | |
| 1. form a working hypothesis, | |
| 2. determine whether additional external evidence is required, | |
| 3. retrieve, remember, or execute when necessary, | |
| 4. detect contradiction or incompleteness, | |
| 5. revise minimally instead of regenerating blindly, | |
| 6. terminate when further cost no longer justifies further truth-seeking gain. | |
| This is the operational meaning of **循证** inside VeriLoop. | |
| --- | |
| ## Harness-First Technical Direction | |
| VeriLoop is built around a **Harness Engineering-first** strategy. | |
| We use the term **Harness Engineering** to describe the system-level discipline that makes model behavior converge more reliably inside real environments: structured state control, hard constraints, knowledge entry points, execution harnesses, verification loops, failure signals, and completion criteria. | |
| Under this strategy: | |
| - **Harness Engineering** is the primary driver of system behavior and workflow reliability | |
| - **Context Engineering** remains important, but functions as one controlled layer inside the larger runtime harness | |
| - **PEFT is used selectively and minimally**, only where targeted stabilization is necessary | |
| - repeated large-scale fine-tuning is intentionally avoided whenever the same goal can be achieved through better runtime control | |
| This direction is not anti-model. | |
| It is anti-fragility. | |
| The VeriLoop thesis is that many of the most expensive failure modes in model development do not come from missing raw capability, but from poor control over: | |
| - state continuity, | |
| - evidence discipline, | |
| - tool-use boundaries, | |
| - verification feedback, | |
| - revision fidelity, | |
| - and termination criteria. | |
| Harness Engineering is the system response to that problem. | |
| --- | |
| ## Minimal PEFT, Not Fine-Tuning Dependency | |
| VeriLoop does not reject parameter-efficient tuning. | |
| It rejects **fine-tuning dependency as the default answer to every problem**. | |
| Our current direction is to use **minimal, targeted PEFT** only where it creates stable interfaces for the runtime system, such as: | |
| - identity stabilization | |
| - uncertainty calibration | |
| - evidence-binding discipline | |
| - tool-spec alignment | |
| - revision and rollback fidelity | |
| The goal is not to rebuild the entire model distribution. | |
| The goal is to create a better substrate for a **Harness-first, evidence-driven runtime**. | |
| This is important because model versions change quickly. | |
| If every backbone upgrade forces a full retraining cycle, engineering investment becomes brittle. | |
| VeriLoop is designed to preserve more value across model generations. | |
| --- | |
| ## Open-Weight Compatibility by Design | |
| VeriLoop is designed to work **with** open-weight ecosystems, not against them. | |
| We believe long-term value should not be trapped inside one permanently fixed checkpoint. | |
| Instead, the E³-Loop runtime is designed to make multiple compatible backbones participate in the VeriLoop paradigm through: | |
| - runtime adaptation, | |
| - harness-controlled execution, | |
| - context and evidence integration, | |
| - and minimal targeted alignment where necessary. | |
| That means model evolution should not automatically erase prior engineering work. | |
| The intended outcome is **open-weight continuity under a stable runtime architecture**. | |
| --- | |
| ## API-First Service Vision | |
| VeriLoop is being built with an **API-first service direction**. | |
| Our long-term goal is to make the VeriLoop effect available as a technical service layer that upgrades compatible model backbones into **evidence-driven closed-loop runtime systems**. | |
| The strategic value is not only in owning checkpoints. | |
| It is in building the right runtime architecture on top of open intelligence. | |
| --- | |
| ## Current Public Product Lines | |
| The current public VeriLoop family is organized around six application lines: | |
| - **VeriLoop Coder** | |
| - **VeriLoop Interaction** | |
| - **VeriLoop Skills** | |
| - **VeriLoop VLA** | |
| - **VeriLoop Scientist** | |
| - **VeriLoop Computer Use** | |
| These names identify application-facing product lines. | |
| They do **not** imply permanent binding to one fixed underlying backbone. | |
| --- | |
| ## Development Status | |
| VeriLoop is an active research and engineering initiative. | |
| Current work focuses on the control-plane and runtime foundations required for evidence-driven closed-loop operation, including: | |
| - state and schema contracts | |
| - evidence memory and contradiction management | |
| - sandbox-linked verification | |
| - harness-controlled execution | |
| - trace and audit ledgers | |
| - targeted PEFT for interface stabilization | |
| - backbone adaptation across different open-weight families | |
| --- | |
| ## Open-Weight and License Notice | |
| VeriLoop is built in the open-weight ecosystem and may be developed on top of, adapted from, or interoperable with upstream open-weight backbones. | |
| Where applicable, upstream attribution, license terms, and third-party notices must be preserved in downstream releases. | |
| Current default backbone mapping for the public VeriLoop product lines is as follows: | |
| - **VeriLoop Coder** → Qwen3-Coder-Next | |
| - **VeriLoop Interaction** → Qwen3.5-27B | |
| - **VeriLoop Skills** → Kimi-K2-Thinking | |
| - **VeriLoop VLA** → Psi-Zero | |
| - **VeriLoop Scientist** → S1-Base-1.5-32B-128K | |
| - **VeriLoop Computer Use** → Qwen3.5-35B-A3B | |
| These mappings describe the **current default backbone choices** and may evolve over time as the VeriLoop runtime is validated across additional open-weight models. | |
| --- | |
| ## Founder and Architecture Origin | |
| **Libo Wang** is the creator and architectural designer of the **E³-Loop** framework that defines the VeriLoop family. | |
| VeriLoop exists to explore a new paradigm for model systems: | |
| - more rigorous than prompt-only interaction, | |
| - more reusable than backbone-specific repeated fine-tuning, | |
| - more auditable than opaque agent stacks, | |
| - and more economically realistic for the open-weight era. | |
| --- | |
| **VeriLoop (循证)** | |
| *Evidence-driven closed-loop runtime intelligence for the open-weight era.* | |