AI & ML interests

LLMs Reasoning, Sparse Attention Mechanism, Mixture of Experts (MoE), Vision Language Action (VLA)

Recent Activity

ConorWang  updated a model about 2 hours ago
veriloop-lab/veriLoop-coder-e1
ConorWang  updated a Space 18 days ago
veriloop-lab/README
ConorWang  published a model 18 days ago
veriloop-lab/veriloop-scientist
View all activity

Organization Card

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.

datasets 0

None public yet