Separating Mechanical Gates from Semantic Gates

Split verification into what can be judged deterministically (mechanical gates) and what needs a judgment of meaning (semantic gates). Don't hand what a machine can judge over to the model's self-report or a reviewer's eyeballing. And "write it in the instructions" is neither gate.

Problem

The model says "fixed" when it isn't fixed. The cause usually isn't a lie — it's that it never checked. So the human adds a line to the instruction file: "don't say done until tests pass." But instructions are context, not enforced configuration (Official, source in the Practice section), and compliance is non-deterministic (Official, with its limits and source in the Practice section). What needs to stop for certain is riding on a mechanism that isn't certain. The reverse happens too — a formatting break that lint could catch in an instant gets left to the model's or a reviewer's eyeballing, and slips through.

Context

Applies when:

• A constraint that's supposed to be "kept" exists — instructions, conventions, verbal agreements — running on words alone
• CI, tests, lint, or a scanner exists (or can be written) to check it mechanically
• The situation has become "trust the model's self-report or nothing" — there's no way to confirm the "I checked" claim

Does not apply when:

• A machine can't judge it, and forcing mechanization anyway. "Is this readable," "is this design sound" — neither lands on a mechanical gate. Force it, and quality ends up measured by a proxy metric the machine can judge (line count, coverage percentage), and only the metric turns green

Boundary with neighboring patterns:

• Failure as Institutional Memory — a failure a machine can stop becomes a gate. What goes into instructions is only the failure a machine can't judge. That pattern writes this same boundary from the side of what to keep in memory; this pattern writes it from the side of what to put on a gate
• Rules Ranked by Binding Force — that pattern's limit is this pattern's entry point. Binding force is words, and words only ever work non-deterministically
• Making the Verification Target Explicit — this pattern is about which kind of gate something lands on; that pattern is about what gets verified
• Strong Gates for Unattended Paths — that pattern is about which path gets a heavier gate; this pattern is about which kind of gate something lands on

Solution

Verification comes in two kinds, and their natures differ:

	Mechanical gate	Semantic gate
Judgment	Deterministic — same input, same answer	Non-deterministic
What it can judge	Form, existence, matching, known patterns	Validity, intent, design, readability
Examples	Tests, lint, type checks, scanners	Review, critique
How it fails	Only judges what it can judge	Misses judgments

Why does the separation work? The value of a gate lies in determinism. A mechanical gate either passes or it doesn't. Run it as many times as you like, by anyone, and it stops at the same place. A semantic gate can see validity a machine can't judge, but in exchange, it can miss things. This difference isn't one of degree — it's one of kind. A mechanical gate's "passed" is a factual claim; a semantic gate's "looks fine" is one opinion.

The way each fails is a matched pair too. A mechanical gate only judges what it can judge — tests can be green while the design is broken. A semantic gate misses judgments — eyeballing doesn't catch every formatting break. The two can complement each other, but neither can substitute for the other. Mix them and only both weaknesses survive: hand formatting judgment to a semantic gate and it gets missed; hand validity judgment to a mechanical gate and a meaningless metric turns green.

And the most common accident is putting it in a third place. Writing "be careful" or "always check" into the instruction file is neither gate. Instructions are context, not enforcement (Official, source in the Practice section), and compliance is non-deterministic (Official, with its limits and source in the Practice section). Whoever wrote it thinks a gate was put in place, but nothing was placed at all. What's worth writing in instructions is only the memory of a failure specific to this environment that a machine can't judge (Failure as Institutional Memory) — and even that isn't a guarantee.

Trade-offs

Advantages

• What needs to stop for certain, actually stops. Unlike an instruction, a mechanical gate's "doesn't pass" is never skimmed past or accidentally forgotten.
• The semantic gate gets to focus on judging meaning. Since form and known patterns are already caught by the machine, review attention goes toward design and intent.

Costs

• Mechanical gates have an upfront cost. Tests, lint, and scanners become assets once written, but they aren't free until then. Turn a one-off constraint into a gate and all you pay is the cost, with nothing to recoup.
• Green gets read as proof of quality too easily. A mechanical gate only judges what it can judge, yet "all green" looks as if everything was confirmed. Reading green as proof of passing and skipping the semantic gate breaks this pattern's separation from the other side.

GitHub Copilot in Practice

Copilot isn't a single product. This section covers the cloud agent and github.com (Copilot code review) surfaces, with Claude Code placed alongside for comparison.

cloud agent — two kinds of gates sit side by side on the same path

Source: Copilot cloud agent risks and mitigations (retrieved 2026-07-16). Code generated by cloud agent gets mechanical checks run on it by default Official:

• CodeQL is used to identify code security issues.
• Newly introduced dependencies are checked against the GitHub Advisory Database for malware advisories, and for any CVSS-rated High or Critical vulnerabilities.
• Secret scanning is used to detect sensitive information such as API keys, tokens, and other secrets.

All three are mechanical gates — matching against known patterns (CodeQL), cross-referencing a database (Advisory Database), and detecting a form (secret scanning). Each is the kind of check that answers "yes" to "can this be judged deterministically?"

The same page goes on to describe a different kind of gate Official:

By default, Copilot cloud agent checks code it generates for security issues and gets a second opinion on its code with Copilot code review.

Copilot code review is called a "second opinion" — not the result of a mechanical gate, which is never called an opinion. It either passes or it doesn't. The same product places two kinds of gates side by side on the same path, writing one as a check and the other as an opinion. This is a real instance of this pattern's separation embedded in a product's defaults.

github.com — code review custom instructions (compliance with instructions is non-deterministic)

What this quote actually covers

The source text below describes custom instructions for Copilot code review specifically. Don't extend it to instruction files in general.

Source: Using custom instructions to unlock the power of Copilot code review (retrieved 2026-07-16) Official:

• Non-deterministic behavior: Copilot may not follow every instruction perfectly every time.

Not every instruction is followed perfectly, every time. This is the gap between writing "don't say done until tests pass" in an instruction and putting the test itself on a CI gate. The former can go unfollowed; the latter either passes or it doesn't.

The equivalent in other tools — Claude Code

Instructions not being enforcement isn't a Copilot quirk. Claude Code writes this about its own instruction file (CLAUDE.md) (source: code.claude.com/docs/en/memory, retrieved 2026-07-16) Official:

Because they're context rather than enforced configuration, how you write instructions affects how reliably Claude follows them. Specific, concise, well-structured instructions work best.

Instructions are context, not enforced configuration. That's exactly why how they're written affects how reliably they get followed — if they were enforcement, the writing wouldn't matter. Two vendors write the same property about their own products. This pattern's premise — what instructions can't stop has to be stopped outside of instructions, at a mechanical gate — stands on these two Official sources.

Also Known As

Name	Source
Separating Mechanical Gates from Semantic Gates	Descriptive — this catalogue's descriptive name; no primary source uses it

Individual gates have established names — CodeQL, secret scanning, Copilot code review (all sourced in the Practice section). What has no name is the practice of separation itself — judging which kind of gate a given check belongs on. The tools provide both kinds of gates, but they don't say which one should carry what. A name is given to the judgment side.

Related

• Failure as Institutional Memory — a failure a machine can stop becomes a gate. What goes into instructions is only the failure a machine can't judge. That pattern writes this same boundary from the side of what to keep in memory; this pattern writes it from the side of what to put on a gate
• Rules Ranked by Binding Force — that pattern's limit is this pattern's entry point. Binding force is words, and words only ever work non-deterministically. A constraint that needs to stop for certain belongs on a gate, not a tier
• Making the Verification Target Explicit — this pattern is about which kind of gate something lands on; that pattern is about what gets verified. Once a criterion that doesn't fit a mechanical gate is left over, next comes making that criterion explicit as a contract in words
• Strong Gates for Unattended Paths — that pattern is about which path gets a heavier gate; this pattern is about which kind of gate something lands on
• Computation as Code — a different application of the same idea. Don't let a non-deterministic means produce an answer that could be produced deterministically
• If reading just one more next: Computation as Code — having handed judgment to a machine, it's next to hand computation to one too