Enforce boundaries mechanically: turn guidance into executable rules: Practical Field Guide

On this page

01Working definition
02Field situation
03Worked example
04Build it, with checkpoints
05Operating context
06Hands-on lab
07Failure clinic
08Production boundary
09Sources and claim limits

Learning objectives

Classify repository expectations as prose guidance, generated evidence, or mechanically enforceable invariants
Implement fast local checks for import direction, generated files, protected paths, secret exposure, and change budgets
Make local, CI, and release gates share rule identifiers and equivalent outcomes
Design exceptions with owner, reason, scope, expiry, and follow-up instead of silent bypass

Before you start

• The repository map, task contract, isolated environment, feature ledger, and typed tool feedback from Modules 01 through 05
• A passing Release Desk baseline and permission to add lint, dependency, fixture, and diff-policy checks

Working definition

Mechanical enforcement

Mechanical enforcement is executable repository policy for an invariant that can be checked reliably. It runs outside the model, produces the same decision for the same inputs, names the violated boundary, and explains a safe repair or formal exception route. Prose still carries intent and judgment; generated maps expose current facts; rules guard the small set of conditions whose violation repeatedly creates risk or costly review.

A repository instruction such as keep domain logic out of route handlers may orient a careful agent, yet it cannot stop an invalid dependency. As autonomous change volume rises, reviewers spend time rediscovering the same boundary violations. A fast dependency check shifts that feedback to the moment the file changes and gives the agent a concrete repair target.

Too many rules create their own failure mode. Brittle checks reject valid work, exception files become permanent policy holes, and a slow preflight encourages bypass. Enforcement earns its place when the invariant is important, the signal is reliable, the repair is understandable, and ownership exists for rule evolution.

Field situation

A fast feature crossed three invisible boundaries

The dependency graph, secret canary, protected files, and exception records are synthetic Release Desk fixtures.

Owner: A technical lead establishing repository controls before allowing longer unattended coding runs.
Decision: Which boundaries belong in fast mechanical checks, and how can the migration proceed without opening a permanent bypass?
Starting state: A candidate implementation imports database code into a UI route, modifies a generated client, and writes a fixture token to a screenshot log. The feature appears functional and the reviewer finds all three issues manually.
Expected outcome: The rule pack catches all seeded violations, returns stable repair codes, accepts one scoped exception, and produces matching local and CI receipts.

Constraints

• Rules must run without production credentials, network access, or a model judge
• The local preflight target is under twelve seconds on the course fixture
• A legitimate schema migration needs one narrow seven-day exception for a protected generated manifest
• Destructive commands, broad process termination, and unvalidated recursive paths remain prohibited

Worked example

Three rules turned review comments into preflight failures

Evidence status: Named synthetic scenario

Historical fixture diffs showed repeated route-to-database imports, manual changes to generated API files, and sensitive canaries entering test artifacts. The team had prose for all three but no executable guard. Review time increased because each change required another architecture and log scan.

The harness added DEP-001 for allowed package direction, GEN-002 for generated-file provenance, and SEC-004 for secret canaries across diff, logs, receipts, and screenshots. Each rule linked a repair note. A migration exception for GEN-002 matched one manifest path, one issue, one owner, and an expiry seven days later.

The seeded bad patch failed locally in under the fixture target and returned three codes. The corrected patch passed. CI replayed the same fixture and rule versions with identical outcomes. When the exception expired, the rule failed until the generated workflow was restored and the record removed.

Limits

Static and fixture checks cannot prove an architecture is secure or appropriate. They protect declared invariants and must be paired with runtime authorization, end-to-end verification, threat review, and accountable release decisions.

Method

Build it, with checkpoints

Field situation

Which boundaries belong in fast mechanical checks, and how can the migration proceed without opening a permanent bypass?

01Select enforceable invariants
02Implement fast checks with stable codes
03Add a narrow exception path

Acceptance checks

A coding session receives immediate, specific feedback for five important repository boundaries, cannot broaden a migration exception, and sees the same decision before and after push.

Why this visualA rule ladder distinguishes prose guidance, generated repository facts, fast local checks, CI gates, and owned release decisions.

01
Select enforceable invariants
Review baseline and code-review evidence. For each candidate, describe the bad state, deterministic input, expected output, false-positive risk, owner, and repair. Keep subjective style or product judgments in documented guidance rather than forcing a weak rule.
CHECKPOINT · Five selected rules have a reliable signal and owner; every rejected candidate records why prose or human review is more suitable.
02
Implement fast checks with stable codes
Build dependency, generated-file, protected-path, secret-canary, and diff-budget checks. Resolve paths from the verified repository root, cap output, link evidence, and return rule IDs with a precise repair hint instead of a generic nonzero exit.
CHECKPOINT · Each seeded violation fails only its expected rule, clean fixtures pass, and no checker reads outside the task repository or approved evidence directory.
03
Add a narrow exception path
Create a signed fixture exception for the migration. Validate rule ID, exact paths, owner, issue, reason, creation time, expiry, and scope. Test missing fields, path widening, wrong rule, and expired date, then prove each attempt fails closed.
CHECKPOINT · The legitimate migration passes only inside its seven-day scope, while unrelated generated files and every malformed exception remain blocked.
04
Prove local and CI parity
Run the same rule manifest and fixture corpus through local preflight and the CI simulator. Compare rule versions, input commit, outcomes, runtime, and evidence hashes. Repair any environment-dependent result rather than documenting a known difference.
CHECKPOINT · Local and CI receipts match for all pass, fail, and exception fixtures, and the full local pack remains under the declared runtime target.

Operating context

Beyond the demo

Build a rule ladder

Start with observed failures from the baseline and later modules. Keep judgment-heavy design choices in instructions with examples. Generate architecture facts such as package ownership, route inventory, schema status, or public exports. Promote an expectation into a rule only when a checker can identify the violation with low ambiguity and a reviewer would reject it consistently.

Assign each rule an identifier, purpose, owner, scope, severity, local command, CI stage, repair hint, and exception policy. The agent should see the same identifier locally and in CI. If two implementations disagree, the harness creates false confidence locally and surprise remotely.

Treat exceptions as expiring work

Some migrations need a temporary dependency or a protected-path edit. An exception must name the exact rule and files, accountable owner, reason, issue, creation date, and expiry. The checker validates every field and rejects an expired or broader match. A blanket disable flag is outside the task contract.

Review rule health from evidence. Track violations, successful repairs, false positives, exception age, local runtime, CI drift, and bypass attempts. Remove a rule that no longer protects a real boundary. A smaller credible set produces better behavior than a long list the team routinely ignores.

Hands-on lab

Create the Release Desk mechanical rule pack

Implement five rules for dependency direction, generated files, protected paths, secret canaries, and task diff budget. Seed violations, add one expiring exception, then compare local and CI receipts.

Prepare

• List repeated review findings and select only boundaries with an objective signal and named owner
• Capture the current dependency graph, generated-file manifest, protected paths, fixture canaries, and baseline preflight runtime

Deliverable

A versioned rule manifest, five executable checks, seeded pass and fail fixtures, one validated expiring exception, repair notes, and parity receipts from local preflight and CI simulation.

Starter kit: Mechanical rule manifest

YAML

rules:
  - id: DEP-001
    owner: platform
    severity: blocking
    scope: ["src/app/**", "src/domain/**", "src/data/**"]
    check: "node scripts/check-dependencies.mjs"
    exceptionRequired: ["owner", "reason", "issue", "expiresAt", "paths"]

Downloadable artifacts

Mechanical rule manifest

mechanical-rules.yml · YAML

An editable course fixture for the main lab. Save it inside the Release Desk repository before running the acceptance command.

Run receipt template

he-06-receipt.json · JSON

A compact evidence record for the check, environment, result, and limits that another reviewer must be able to inspect.

Acceptance command

npm run harness:rules -- --manifest .harness/mechanical-rules.yml --parity

Expected receipt

PASS he-06 mechanical-enforcement
rules=5 seededViolationsCaught=5
localCiMismatches=0 invalidExceptionsAccepted=0

Expected result

A coding session receives immediate, specific feedback for five important repository boundaries, cannot broaden a migration exception, and sees the same decision before and after push.

Carry forward

Run the rule pack as the first layer of the verification ladder. Include rule outcomes and exception age in observability, scaling evidence, and the capstone Harness Card.

Acceptance checks

01All five seeded violations fail with the expected rule ID, evidence, owner, and repair guidance
02Clean fixtures pass and the complete local preflight stays under the course runtime target
03Exception validation rejects missing owner, missing issue, expired date, widened path, and unmatched rule
04Local and CI simulation produce matching outcomes, rule versions, commit identity, and evidence hashes

What breaks

Failure clinic

F1Agents routinely add ignore comments because a rule rejects valid changes.

Inspect: Review false-positive fixtures, bypass frequency, rule scope, parser assumptions, repair time, and owner response.
Likely cause: The check encoded a broad proxy instead of the actual invariant or has no maintained exception path.
Repair: Disable only the faulty rule through an owned change, narrow its signal, add retained valid fixtures, and remove unauthorized bypasses.
Prevent next time: Track false positives and repair time per rule; require an owner and tests for every policy change.

F2Local preflight passes while CI reports a different dependency violation.

Inspect: Compare rule package, manifest hash, working directory, generated state, runtime version, inputs, and ignored files.
Likely cause: Local and CI paths use different implementations or resolve repository state differently.
Repair: Run one versioned checker entry point with explicit root and inputs, then add the mismatch as a parity fixture.
Prevent next time: Publish rule version and input hashes in both receipts and gate releases on parity fixtures.

F3A temporary exception remains active months after the migration.

Inspect: List exception owners, creation and expiry dates, matched files, usage events, linked issues, and current violations.
Likely cause: Exceptions were comments or blanket flags without validated expiry and follow-up ownership.
Repair: Expire the record, restore the invariant or create a reviewed rule change, and reconcile changes made under the exception.
Prevent next time: Fail expired records mechanically and surface exception age in every harness health report.

Beyond the demo

Production boundary

01Each rule protects a named invariant with reliable signal, explicit scope, severity, owner, and repair path
02Rules resolve paths and environment identity safely and never rely on empty variables, broad roots, or unowned processes
03Local, CI, and release gates use the same versioned rule implementation and publish comparable receipts
04Exceptions require exact rule and path scope, accountable owner, reason, issue, creation date, and enforced expiry
05Rule fixtures cover valid changes, seeded violations, malformed exceptions, environment drift, and secret redaction
06Rule health tracks runtime, violations, false positives, repair time, bypass attempts, and exception age

Evidence status

Sources and claim limits

Sources support the named claims; they do not guarantee the same result in another system.

[1]
Harness engineering: leveraging Codex in an agent-first world
OpenAI · Public case · 2026-08-26
repository knowledge · agent legibility · mechanical enforcement · entropy management
[2]
Harness Engineering learning guide
deusyu · Public case · 2026-08-26
repository as record · mechanical rules · agent readability · continuous cleanup
[3]
Learn Harness Engineering
Walking Labs · Public case · 2026-08-26
project-based sequence · five harness subsystems · loop engineering · graph engineering
[4]
Harness Engineering Guide
Nexu · Public case · 2026-08-26
runtime boundary · tool systems · sandboxing · recovery patterns
[5]
Effective harnesses for long-running agents
Anthropic · Published research · 2026-08-26
initializer pattern · feature ledger · session handoff · end-to-end verification