The 3-stage pipeline
How codingassist.bot transforms a pull request into a deterministic, replayable verdict.
codingassist.bot is built around a 3-stage pipeline. Each stage is independently observable, independently replayable, and bounded by a strict input/output contract. Nothing in the pipeline is non-deterministic — given identical inputs, you get identical verdicts.
Stages at a glance
Stage 1 — Context
The Context stage builds a single, typed bundle from three independent sources:
- Diff — hunks, renames, symbol moves
- Ticket — acceptance criteria parsed from Jira/Linear/GitHub Issues
- CodeGraph — semantic neighbours retrieved from a vector index over the repo
The output is an immutable ReviewContext record, content-addressed by SHA-256.
Stage 2 — Analysis
The Analysis stage fans out the ReviewContext to six reasoning planes (Intent, Contract, Semantic, Tests, Security, Performance). Each plane:
- Receives the same immutable bundle
- Runs in isolation — no cross-plane reads
- Emits a typed signal:
{ plane, severity, finding[], confidence }
There is no master prompt. Each plane is a standalone evaluator; the LLM call (when used) is bounded to the plane's input schema.
type PlaneSignal = {
plane: "intent" | "contract" | "semantic" | "tests" | "security" | "perf";
severity: "info" | "warn" | "error";
findings: Finding[];
confidence: number; // 0..1
};Stage 2-bis — Sandbox (optional)
For findings that need code execution (e.g. test-coverage delta), Stage 2-bis runs the proposed change in an ephemeral sandbox. Sandboxes are language-scoped and disposable.
Stage 3 — Orchestration
The Orchestration stage receives the six signals and produces:
- A verdict (auto-merge / auto-approve / human review / escalate / declined)
- A confidence tier (T1–T5)
- A signed audit record that can be replayed
Orchestration applies tenant-defined policies — for example, "always escalate when the Security plane reports error severity" or "auto-merge T1 only on main".
Determinism guarantees
| Property | How it's enforced |
|---|---|
| Input determinism | ReviewContext is content-addressed; equivalent inputs map to the same hash |
| Plane determinism | Temperature pinned to 0; seeded sampling; output schema validated |
| Verdict determinism | Orchestration is pure given signals; policies are versioned |
| Replayability | The full chain — context → signals → verdict — is stored, signed, and exportable |
What's next?
- AC verification — how Stage 1 binds ACs to code
- Findings & severity — what each plane emits
- POST /v1/reviews — drive the pipeline from your code