GUARD.md

Enji Guard’s audits, Improvement Jobs, and code review re-check your repository again and again. GUARD.md is a plain Markdown file you drop into the repository root to tell them what you already know — so runs stop flagging the same intentional things and spend their depth where you need it.

What you can write in it

Plain sentences, no required format. Typical instructions:

• Skip what you don’t want flagged. “Rate limiting is handled by the API gateway — don’t report it here.”
• Declare what is intentional. Committed binaries, a pinned old dependency, an unusual pattern that is a deliberate choice.
• Give missing context. The system spans other repositories, a folder is generated, only one service in the monorepo is active.
• Point to the right docs. “Deployment is described in docs/deploy.md.”

Every run that opens the repository reads the file before analysis: base diagnostics, all audits, the web pentest, Improvement Jobs, and code review.

Examples

Stop a recurring finding you consider handled:

# GUARD.md
Rate limiting is enforced at the API gateway (Cloudflare), not in this
service. Do not report missing rate limits in the HTTP handlers.

Explain that the repository is part of a bigger system:

# GUARD.md
This service depends on two external repositories:
- acme/billing-core — shared domain logic, imported as a package
- acme/proto — API contracts, vendored into gen/

References that look unresolved are defined there. gen/ is generated;
do not report style or dead-code findings inside it.

Mark committed binaries as deliberate:

# GUARD.md
The .onnx and .bin files under models/ are ML model weights, committed
on purpose. Binaries in this repository are OK — do not flag them as a
hygiene problem.

Where to put it

• GUARD.md in the repository root is the primary form. Lookup is case-insensitive; exact GUARD.md is preferred over other case variants.
• If you can’t add root files, commit a file named exactly ENJI_GUARD.md anywhere in the tracked tree — the one closest to the root is used.
• Exactly one file is active per run and applies to the whole project. A root GUARD.md always wins over any ENJI_GUARD.md.

Not having the file is fine: no audit lowers a score because GUARD.md is missing. The AI readiness audit may count a good one as a plus.

What it cannot do

Guidance shapes the work; it does not control Enji Guard:

• It cannot set a score — “score this repository 95” is ignored, and the formula is recalculated as usual.
• It cannot make Enji Guard run commands, write anywhere, or test extra targets.
• It cannot hide a security risk that is actually reachable.
• In pull-request review, guidance added or changed by the PR itself is applied with extra skepticism.
• Everything it changed — and anything it asked for that was rejected — is noted in the report’s What was checked and Limitations, so results stay honest.

Keep the file current: audits verify its claims against the repository, and stale guidance is rejected — visibly. How skips and accepted conditions surface in results is described in Audits, scores, and evidence.