The loop

Bigwave's central thesis: the loop is the product. Every other open-source piece — serving engine, fine-tuning library, eval harness, feedback store — is best-of-breed in isolation. Bigwave's value is making them turn together.

The shape of the loop

       ┌──────────────────────────────────────────┐
       │                                          │
       │           ┌──────────┐                   │
       │           │   Chat   │                   │
       │           └─────┬────┘                   │
       │                 │ user response          │
       │                 ▼                        │
       │           ┌──────────┐                   │
       │           │ Feedback │ thumbs / edits    │
       │           └─────┬────┘                   │
       │                 │                        │
       │                 ▼                        │
       │       ┌──────────────────┐               │
       │       │ Preference data  │ (chosen,      │
       │       └─────────┬────────┘  rejected)    │
       │                 │                        │
       │                 ▼                        │
       │           ┌──────────┐                   │
       │           │   DPO    │                   │
       │           └─────┬────┘                   │
       │                 │ candidate adapter      │
       │                 ▼                        │
       │           ┌──────────┐                   │
       │           │   Eval   │                   │
       │           └─────┬────┘                   │
       │                 │ pass-rate + CI         │
       │                 ▼                        │
       │           ┌──────────┐                   │
       │           │   Gate   │                   │
       │           └─────┬────┘                   │
       │      block ┌────┴────┐ allow             │
       │            ▼         ▼                   │
       │      (rollback)  ┌──────────┐            │
       │                  │ Activate │            │
       │                  └─────┬────┘            │
       │                        │ new handle      │
       └────────────────────────┘                  │
                                                   │
                            (next chat)            │
                                                   │
                                ───────────────────┘

Each step is a real component in the codebase:

Step	Component
Chat	packages/gateway/adapters/firstparty/routes.py
Feedback	packages/feedback/store.py, channel adapters
Preference data	packages/feedback/dataset_builder.py
DPO	packages/training/adapters/unsloth_backend.py (DPO recipe)
Eval	packages/eval/runner.py, packages/eval/scorers/
Gate	packages/eval/gate.py
Activate	packages/serving/replica_manager.py

Why it has to be one product

The pieces above already exist as great open-source projects (vLLM/Ollama for serving, Unsloth for tuning, lm-eval-harness for eval, Phoenix for traces, Langfuse for feedback). The problem is the seams between them.

• Feedback rows from Langfuse don't natively become preference data for Unsloth.
• Phoenix traces don't gate Unsloth's adapter activation.
• Cross-tool workspace boundaries don't compose.
• Audit lineage that crosses three different tools is six workarounds duct-taped together.

A team running this stack hand-rolls four glue layers. Bigwave is those four glue layers, shipped as a single substrate.

What changes when the loop closes

Three things that don't happen with point-tools:

1. Feedback informs the next training cycle automatically.dataset_builder reads the FeedbackStore and produces a DPO dataset with no manual export. The pipeline isn't "Langfuse exports CSV → operator transforms → Unsloth ingests" — it's a single API call.
2. The eval gate is binding. When a candidate adapter regresses, the activation route returns 422 and the old handle stays live. No "we ran the eval and posted a comment in Slack and shipped anyway." The deploy cannot happen without passing the gate.
3. Provenance survives across the loop. Every feedback row carries the (model, adapter, prompt_template_version, workspace_id) of the completion it referenced. Every dataset row carries the lineage of the feedback rows it was built from. Every adapter carries the dataset SHA + hyperparam hash it was trained on. The audit log records every transition. This whole chain is what GRC asks for and what hand-rolled stacks fail to produce.

What "closing the loop" requires architecturally

For the loop to close cleanly, every component needs three properties:

1. Workspace-scoped. Multi-tenant by construction; cross-tenant reads are 404 (see workspace fence).
2. Provenance-carrying. Every artefact knows where it came from.
3. Audit-recording. Mutations land in the audit log.

Bigwave enforces all three at the ABC level. Adapters that don't satisfy them don't pass the conformance harness, which means they don't ship.

What the loop is not

• It's not a way to make any model better. Naive thumbs-DPO on noisy feedback can degrade models. The loop only helps when the feedback is high-signal (senior-agent edits beat thumbs; thumbs-on-completion-acceptance beat thumbs-on-vibes).
• It's not a substitute for human evaluation. The eval gate catches pass-rate regressions; it doesn't catch alignment drift, brand- voice drift, or tone shifts unless you've explicitly built scorers for those.
• It's not a magic compound-improvement engine. Each cycle of the loop yields diminishing returns on the same data. Re-running DPO on the same preference set 10x doesn't make the model 10x better.

Reading order if this concept is new

1. Getting started — walk the loop end-to-end on your laptop.
2. Eval-as-a-gate — the binding-deploy property in detail.
3. Optional-by-design adapters — how every component is swappable.
4. The use cases (compliance, coding, agent eval, support tone) — concrete buyer-grounded recipes.