Kode Verification Pipeline: Six Gates, Zero Guesses

How Kode’s six-gate pipeline catches syntax errors, hallucinated imports, bad calls, and security issues before any generated code reaches your disk.

Every LLM-generated patch Kode produces passes through a deterministic, six-stage verification pipeline before a single byte reaches your filesystem. No file is written speculatively, no diff is applied optimistically — the pipeline runs entirely in-memory and rejects anything that cannot be structurally proven correct for your project. If even one gate fails, the write is blocked and the verdict is returned immediately.

How verification works

When Kode generates a patch, it invokes the Gate — a Go struct that chains six checkers in order:

Diff Applier → Syntax → Imports → Calls → Blast Radius → Architecture → Security

All content is held in memory throughout. The DiffApplier reconstructs the modified file contents from the patch and the originals. The resulting map[string]string — file path → proposed content — flows through each gate. The first gate to return FAIL stops the chain and returns a Verdict with "overall": "FAIL".

Files are only written to disk when the overall status is PASS.

The 6 gates

1. Gate 1 — Syntax
2. The syntax gate uses a dual-engine approach: a Tree-sitter AST parser for languages where it is available, with a bracket-balance regex fallback for all others.
3. Supported languages and their engines:
4. LanguageEngineGogo/parser AST (standard library)TypeScript / TSXTree-sitter + bracket-balance fallbackJavaScript / JSX / MJSTree-sitter + bracket-balance fallbackPython / PYIBracket-balance + triple-quoted string trackingRustBracket-balance fallback
5. The Go checker calls parser.ParseFile with parser.AllErrors set, so every parse error in the file is collected before failing. The bracket-balance checker tracks strings, template literals, single-line comments, and block comments to avoid false positives inside string literals.
6. What it catches: Unclosed braces {, mismatched parentheses (, malformed Go function signatures, Python indentation errors surfaced through bracket mismatch.
7. A syntax failure immediately stops the pipeline — no further gates run.
8. Gate 2 — Imports
9. The imports gate validates every import statement in each modified file against the project’s actual dependency graph. It walks the ContextGraph built by Kode’s indexer, which maps every known import path in your project.
10. For Go files, it checks that every imported package path exists in go.mod or as a relative internal package. For TypeScript and JavaScript, it validates that npm package names appear in package.json and that relative paths resolve to real files.
11. What it catches: Hallucinated package names (e.g., import "github.com/nonexistent/pkg"), misspelled npm modules, import paths that were valid in the LLM’s training data but don’t exist in your project.
12. A failed import blocks the write — the gate returns FAIL.
13. Gate 3 — Calls
14. The calls gate checks every function and method call in the modified files against the set of symbols known to exist. It uses the same ContextGraph to verify that:
16. The checker distinguishes between hard failures (calling a method on a hallucinated external package) and warnings (calling an internal function that wasn’t found in the graph — the graph may be incomplete).
17. What it catches: somePackage.HallucinatedMethod(), wrong method names on real types, calls to functions that the LLM invented but don’t exist.
18. A hard failure (hallucinated external call) blocks the write.
19. Gate 4 — Blast Radius
20. The blast radius gate walks the reverse-dependency graph to count how many downstream files would be affected if the modified file changed. It follows both direct and transitive edges: if A imports B which imports C, modifying C has a blast radius that includes both B and A.
21. You configure the maximum acceptable blast radius in .kode/kode.json:
22. {
      "engine": {
        "max_blast_radius": 10
      }
    }
    

23. When the number of downstream files affected by any single modified file exceeds max_blast_radius, the gate returns FAIL with a summary:
24. blast radius: 14 downstream file(s) affected (threshold: 10)
    

25. What it catches: Patches that modify a low-level shared utility and would ripple uncontrolled changes across your entire codebase.
26. This gate only activates when max_blast_radius is set and a ContextGraph is available.
27. Gate 5 — Architecture
28. The architecture gate enforces your declared module and microservice boundaries. You define rules as ArchRule entries — each rule specifies a forbidden import prefix and optionally which packages are allowed to import it:
29. {
      "engine": {
        "architecture_rules": [
          {
            "forbidden_import_prefix": "internal/database",
            "allowed_in_packages": ["internal/repository"],
            "error_message": "Database access is only allowed from the repository layer"
          }
        ]
      }
    }
    

30. By default, architecture violations are reported as warnings (WARN) and do not block the write. Set "block_on_architecture": true to make violations hard failures.
31. What it catches: Service A directly importing Service B’s internal packages, handler layers importing data layers directly, circular dependency anti-patterns.
32. Gate 6 — Security (Sicario)
33. The security gate runs an AST-based static application security testing (SAST) scan via Sicario, Kode’s companion security scanner. Install it with:
34. kode install sicario
    

35. Sicario scans the proposed content for:
37. Findings are classified by severity:
38. SeverityOutcomehigh or criticalFAIL — write blockedmedium or lowWARN — write proceeds with warningNone foundPASS
39. If Sicario is not installed, the gate returns WARN with the message:
40. Security check skipped — Sicario not found (install with 'kode install sicario')
    

Two input modes for kode verify

The verify command supports two JSON input shapes, depending on whether you have a diff or proposed file contents.

Hunk Mode

{
  "hunks": [
    {
      "file_path": "internal/auth/handler.go",
      "diff": "@@ -10,6 +10,7 @@ ..."
    }
  ],
  "original_files": {
    "internal/auth/handler.go": "package auth\n..."
  }
}

In hunk mode, Kode applies the hunks in-memory against the originals first, then passes the resulting content through all six gates.

In file mode, the proposed file contents are verified directly without hunk application — useful when you have already assembled the full file outside of Kode.

Run verification:

kode verify --input patch.json --project-dir .

Audit logging

Every verification result is appended as a JSONL entry to logs/kode.log in your project directory:

{
  "timestamp": "2025-11-14T09:31:04.123Z",
  "task_id": "verify",
  "status": "FAIL",
  "files": [],
  "failures": {
    "internal/auth/handler.go": "syntax: Syntax check failed: unmatched closing brace '}'"
  },
  "rounds_used": 1,
  "duration_ms": 23,
  "input_source": "patch.json"
}

Override the log directory with --log-dir:

kode verify --input patch.json --log-dir /var/log/kode

Exit codes

Code	Meaning
0	Pipeline passed — all gates returned PASS
1	Pipeline failed — at least one gate returned FAIL

Architecture violations downgraded to WARN do not cause a non-zero exit. Only hard FAIL results exit 1.

Related pages

• CLI: kode verify — full flag reference for the verify command
• Troubleshooting gate failures — how to read and resolve each gate’s error messages