Four Guard Lanes: How GuardSpine Routes Every Change

Your team is mass-approving PRs because the governance tool treats a README typo the same as a rewrite of your OAuth middleware. Developers learned that every change gets the same 8-minute review cycle, so they batch unrelated changes together to amortize the pain. Your “governed” pipeline is now a rubber stamp with extra latency.

This is what happens when governance has one speed. Every change gets the same scrutiny, which means no change gets appropriate scrutiny. The high-risk changes get under-reviewed because reviewers are fatigued from over-reviewing the low-risk ones.

GuardSpine has four speeds. Four guard lanes, each calibrated to a different risk tier. The lane determines review depth, reviewer composition, approval thresholds, and evidence granularity. Here is how the routing works and why one-size-fits-all governance is a liability.

The Routing Decision

Before a change enters any lane, GuardSpine classifies it. The classification engine evaluates three signals:

File path patterns. Changes to src/auth/** or src/payments/** are inherently higher risk than changes to docs/** or tests/fixtures/**. You define these patterns in your GuardSpine configuration.

Content analysis. The diff itself is analyzed for risk indicators. New database queries, cryptographic operations, environment variable access, external API calls, PII field references — each pattern contributes to the risk score.

Historical context. Files that have caused incidents before carry elevated risk. A module with three prior security findings starts at a higher baseline than a module with a clean history.

These signals combine into a risk tier: L0, L1, L2, or L3. The tier determines the lane. The lane determines everything else.

L0: Express Lane

What goes here: Documentation, comments, test fixtures, localization strings, configuration files that do not affect runtime behavior, dependency lock file updates (without version changes).

Review process: Automated single-model scan. The reviewer checks for accidental secrets, broken links, and formatting issues. No deep logic review. No multi-model council.

Approval threshold: Consensus score below 0.6. Almost everything passes unless the reviewer flags something unexpected — like a supposed documentation change that actually modifies executable code.

Evidence: Minimal bundle. Diff, classification reasoning, single review assessment. Sealed and signed but lightweight.

Why it matters: L0 is the release valve. Without an express lane, governance becomes a bottleneck on trivial changes, and developers start resenting the system. A README fix should merge in minutes, not hours. The express lane makes that possible while still capturing evidence that the change was classified and checked.

Real example: a developer updates the API documentation to fix a broken curl example. L0 classification fires because the change is entirely within docs/. Single-model scan confirms no executable code was modified. The PR merges with a sealed evidence bundle in under 90 seconds.

L1: Standard Lane

What goes here: Business logic, UI components, non-sensitive API endpoints, internal tooling, test code, build configuration changes.

Review process: Single-model AI review against your coding standards and business logic rules. The reviewer evaluates correctness, maintainability, and adherence to your team’s patterns. No security-focused deep review unless content analysis flags a concern.

Approval threshold: Consensus score below 0.4. Findings of medium severity or higher require developer acknowledgment before merge.

Evidence: Standard bundle. Diff, classification, review with all findings, acknowledgment records if applicable. Full hash chain.

Why it matters: L1 handles the bulk of daily development work. Most PRs in a typical codebase are business logic changes that need good review but not security-level scrutiny. The standard lane gives them thorough single-model review without the overhead of multi-model consensus.

Real example: a developer adds a new filtering option to a dashboard component. L1 classification fires — UI code, no auth or data handling patterns detected. Claude reviews against coding standards, flags a missing null check on the filter parameter. Developer fixes it. Bundle sealed with the finding and resolution documented.

L2: Elevated Lane

What goes here: Database schema changes, API authentication modifications, data handling logic, third-party integration code, infrastructure configuration, CI/CD pipeline changes.

Review process: Multi-model council review. Two or three AI models independently evaluate the change against security policies, data handling rules, and integration standards. Consensus scoring with dissent documentation.

Approval threshold: Consensus score below 0.3. Any security-related finding at high severity blocks merge until resolved. Dissent between reviewers triggers mandatory human review.

Evidence: Full bundle. Diff, classification with matched patterns, multiple independent reviews, consensus computation, dissent records, resolution documentation. Complete hash chain with all items.

Why it matters: L2 is where governance earns its keep. These changes carry real risk — a bad database migration can corrupt production data, a flawed auth change can expose user accounts. Multi-model review catches issues that a single reviewer misses. The elevated threshold means marginal changes get extra scrutiny.

Real example: a developer modifies the database schema to add a new user preferences table with a foreign key to the users table. L2 classification fires on the schema migration pattern. Claude checks the migration for data integrity. GPT-4 evaluates the foreign key constraints and index coverage. Gemini flags that the migration lacks a rollback path. The developer adds the down migration. All three findings and resolutions are sealed into the evidence bundle.

L3: Critical Lane

What goes here: Authentication flows, payment processing, cryptographic operations, PII handling, access control logic, security middleware, secrets management, compliance-critical paths.

Review process: Full multi-model council with mandatory human sign-off. All council members review independently. Consensus scoring with strict thresholds. A designated human reviewer must approve after seeing the AI council’s findings. The human approval is captured in the evidence bundle with the same integrity as the AI reviews.

Approval threshold: Consensus score below 0.2. Any finding at medium severity or higher blocks merge. Unanimous AI approval required on security-specific rules. Human approval required regardless of AI consensus.

Evidence: Maximum bundle. Every item described above, plus human reviewer identity and approval timestamp, policy compliance attestation, and cross-reference to any related security findings in the codebase. The most detailed evidence trail in the system.

Why it matters: L3 exists because some code changes can cause catastrophic damage if they go wrong. A flaw in payment processing can lose money. A flaw in authentication can expose every user account. A flaw in cryptographic operations can invalidate your entire security model. These changes need the deepest review and the strongest evidence.

Real example: a developer refactors the JWT token validation middleware to support a new signing algorithm. L3 classification fires immediately — authentication, cryptographic operations, security middleware. Claude, GPT-4, and Gemini each review independently. GPT-4 flags that the new algorithm validation does not reject alg: none. Claude catches that the key rotation logic has a race condition during the transition window. The senior security engineer reviews all findings, confirms both are valid, and approves after fixes. The evidence bundle contains every step, every finding, every resolution, and the human authorization.

Configuring Your Lanes

Lane configuration lives in your .guardspine.yml file:

guard_lanes:
  L0:
    patterns: ["docs/**", "*.md", "tests/fixtures/**"]
    reviewers: 1
    threshold: 0.6
  L1:
    patterns: ["src/**", "lib/**"]
    reviewers: 1
    threshold: 0.4
  L2:
    patterns: ["src/db/**", "src/integrations/**"]
    reviewers: 3
    threshold: 0.3
    require_human: false
  L3:
    patterns: ["src/auth/**", "src/payments/**", "src/crypto/**"]
    reviewers: 3
    threshold: 0.2
    require_human: true

Patterns are evaluated in order from L3 down. A file matching L3 patterns is never downgraded to L1, even if it also matches L1 patterns. The highest applicable tier wins.

The Point

Guard lanes exist because governance without proportionality is just bureaucracy. Treating every change the same — either too little scrutiny or too much — makes the system either useless or unusable.

Four lanes, risk-proportional review, configurable thresholds, sealed evidence at every tier. That is governance that developers can live with and auditors can trust.

Want to see how your codebase maps to guard lanes? Book a walkthrough at cal.com/davidyoussef/guardspine. I will classify your last twenty PRs and show you the lane distribution.