Documentation

Policy model

How sensitive, infrastructure, and denied paths are classified, and where denial happens.

Three tiers of path rules

Every project carries its own rules, not a shared global list: sensitive paths (escalated to a human regardless of confidence), infrastructure paths (eligible for a fast-track card when confidence is high and tests are green), and denied paths (refused outright).

Classification combines file-path and diff heuristics against those rules with a model classification as a second opinion. Where the two disagree, the stricter class wins.

Hard denial

A change touching a denied path is refused immediately after diagnosis produces its file list — before any change is applied, before typecheck or tests run, and before anything is committed. No branch and no pull request are ever created. The refusal gets its own incident status and its own decision record, distinct from an escalation, so a ledger shows refusals that were reasoned about rather than absences.

This is a small set of path rules per project, not a rule language. Blast-radius-size and dependency-version-bump rules are deliberately deferred.

Example configuration

Each rule is a path prefix or an exact path. A denied-paths list covering a schema file and an auth module looks like this:

[
  {
    "type": "exact",
    "path": "db/schema.sql"
  },
  {
    "type": "exact",
    "path": "auth/tokens.ts"
  }
]

How the draft is created

The initial draft is generated from the repository’s structure and requires explicit human review and confirmation before the project is created. An empty denied-paths list is a legitimate reviewed answer — over-broad denial rules block legitimate fixes outright — so the confirmation step records how many rules were approved, making “reviewed and empty” distinguishable from “never considered”.