Synthesizer

Four parallel domain specialists produce a lot of overlap. Without a synthesizer, that overlap shows up as 40 redundant comments on the PR. The synthesizer turns four streams into one signal — and it’s where the believability pipeline does most of its work. It runs after the four specialists and is not one of them.

Where the synthesizer sits in the believability pipeline

Believability in Sigilix is architectural, not a prompt. A finding cannot post unless it earns its way through the 5-stage believability pipeline: evidence → provenance contracts → refute/execute → proof-tier receipts → memory. The synthesizer is the stage where evidence is checked against provenance contracts, refuted-or-confirmed, and stamped with a proof-tier receipt (VERIFIED / REPRODUCED / GROUNDED / MODEL) before anything reaches the PR. The four stages below are how the synthesizer does that.

The four stages

1. Collect

Specialists submit findings in a structured shape:

{
  "specialist": "security",
  "path": "src/api/checkout.ts",
  "line": 142,
  "category": "security",
  "severity": "critical",
  "headline": "missing CSRF verification on POST /checkout",
  "body": "...",
  "citedCode": "app.post('/checkout', handler)"
}

The specialist field is the role name (logic, security, performance, tests) — the same name shown on the finding in the final review comment.

Each finding must carry the evidence it stands on (the cited code it quotes). Findings missing required fields are dropped at this stage.

2. Cross-reference

The synthesizer performs structural-provenance checks against the source code to suppress hallucinations. This is the grounding gate: a finding that cannot be anchored to cited code does not earn a GROUNDED receipt and is suppressed or demoted.

• Line-validity check. Does the finding’s path:line actually exist in the diff? Hallucinated line numbers are dropped.
• Symbol-resolution check. Does the function/variable referenced in the finding actually exist in the file? Hallucinated identifiers are dropped.
• Pattern-match check. For security findings, does the claimed unsafe pattern (e.g., “passes user input to SQL template”) actually match the code? Pattern-mismatches are dropped or down-graded.

Findings that pass all three checks proceed. Findings that fail are silently suppressed — they never reach the PR.

3. Calibrate

The synthesizer then performs deduplication and severity calibration:

Deduplication. Overlapping findings (same path:line from multiple specialists) are merged into one. The merged finding’s body draws from each specialist’s contribution; the severity is the maximum of the inputs.

Severity calibration. Each finding’s severity is recalculated:

Advisory cap. If a flood of low-severity (Info) findings exists, the synthesizer surfaces the top few inline and aggregates the rest into a single “advisory nits” line in the summary. This prevents review-comment dilution.

Proof-tier receipts. Each surviving finding is stamped with a tier pill — VERIFIED, REPRODUCED, GROUNDED, or MODEL — recording how strongly it was witnessed. See Confidence Scoring and Verification & the Trust Ledger.

4. Render

The synthesizer writes the final comment. The shape:

1. Synthesizer summary — what was reviewed, how many findings survived, what verdict
2. Inline findings — anchored to specific path:line, tagged by specialist + severity + proof-tier receipt
3. Suggested patches — included where the synthesizer’s structural check confirms a clean fix is in scope

Sigilix is inline-first: anchorable findings post on the line they quote, not buried in a review body.

Failure modes

Specialist provider failures

If one specialist’s model is overloaded (503) or exceeds its size-scaled budget, Sigilix retries once on the primary, then fires the cross-provider fallback. Primary + fallback run on independent infrastructure so a same-family provider outage can’t silence the same role twice.

If all attempts for a specialist fail, the specialist’s findings are skipped — but the synthesizer still synthesizes from the remaining specialists. The verdict is still posted with a footnote: _3 of 4 specialists succeeded._

Stale-head guards

If the user pushes a new commit while Sigilix is mid-review, the old review would be stale. Sigilix has two stale-head guards:

• Before fan-out. If the PR’s head SHA changed since the webhook fired, abort.
• Before posting. If the head SHA changed during specialist execution, abort and let the new webhook fire its own review.

Both guards prevent stale reviews from racing to post.

Submit failures

If GitHub rejects the inline-anchor positions in the review payload (typical 422 for a bad line number), Sigilix falls back to an anchorless review with all findings rolled into the body. The user sees one coherent review, just without inline anchors.

This recovers verdicts that would otherwise be silently lost.

What the synthesizer adds

Synthesis is the stage that turns four independent specialist streams into one review you can trust. It deduplicates overlapping findings, cross-references each claim against the source, calibrates severity from cross-specialist agreement, weighs every candidate against your review memory, and stamps each survivor with a proof-tier receipt. Skip that stage and raw model output would post as-is — a false positive, a redundant comment, or a hallucinated line number would all reach the PR unchecked.

The synthesizer is the difference. The four-stage pipeline — deepened by the org context it carries in from memory — is what makes Sigilix’s reviews believable and readable.

Read next