Rules and findings
Every finding has a rule ID, a level and a severity.
- Level: a violation breaks a rule; drift is where the code and the model disagree without breaking one.
- Severity:
critical,high,mediumorlow. The tables give each rule’s default.
Whether an organisation can change a rule’s severity: to be confirmed.
From the check
These come from arch-check on each pull request and on your default branch. P is the repository’s
package; N, A and B are component names.
| ID | Level | Default severity | Message | What it means |
|---|---|---|---|---|
ARCH-CON-1 |
violation | high | contracts: pyproject.toml's import-linter contracts differ from the model's |
The generated Import Linter block was edited by hand, or is out of date with the model |
ARCH-DEP-1 |
violation | high | drift: P.N is in the code but not in the model |
A component exists in the code that the model doesn’t declare |
ARCH-DEP-2 |
drift | medium | drift: P.N is in the model but not in the code |
The model declares a component the code doesn’t have |
ARCH-DEP-3 |
violation | critical | drift: P.A imports P.B, which the model doesn't declare |
An undeclared dependency between components: the boundary break agents most often cause |
ARCH-DEP-4 |
drift | low | drift: the model says P.A imports P.B, and the code doesn't |
A declared dependency that’s no longer used |
ARCH-IFC-1 |
violation | high | interfaces: E declares PATH, … |
A declared interface file, such as openapi.json, is missing or wrong |
ARCH-ADR-1 |
violation | medium | adrs: FILE:LINE: REF isn't in the pinned index |
A file cites an ADR the pinned slice doesn’t hold |
ARCH-PIN-1 |
drift | medium | the slice is out of date | The slice the repository pins differs in substance from a fresh one |
ARCH-RUN-1 |
drift | high | the check didn’t finish, or wrote no results | Nothing verified the repository this time, so its components show as Unverified |
ARCH-UNK-1 |
violation | medium | any message no other pattern matches | The check’s wording changed; it is reported rather than dropped |
Contracts
From a pull request’s contract checks. They warn on the pull request and don’t fail it.
| ID | Level | Default severity | What it means |
|---|---|---|---|
CON-BRK-1 |
violation | high | The pull request breaks its OpenAPI contract, such as a removed path or a parameter that became required (oasdiff’s error level) |
CON-WRN-1 |
drift | low | A change oasdiff warns may break a client |
CON-BRK-2 |
violation | high | The pull request breaks a data contract: a JSON Schema change that breaks its readers, such as a removed required property, or a Protobuf change that breaks the wire, such as a deleted field |
CON-WRN-2 |
drift | low | A change to a data contract that may break a reader, such as a renamed Protobuf field |
CON-BRK-3 |
violation | high | The pull request breaks an MCP server’s tool list: a tool removed, an input removed or renamed, an input that became required, or an input’s type changed |
CON-WRN-3 |
drift | low | A change that may change what an agent does: a new optional input, or a changed description |
CON-BRK-4 |
violation | high | The pull request breaks an AsyncAPI event contract: a channel, operation or message removed, or a payload change that breaks a reader, such as a removed required property |
CON-WRN-4 |
drift | low | A change to an event contract that may break a reader |
The dashboard’s own rules
These aren’t in any repository’s check. The dashboard evaluates them after each refresh, so a repository’s check never closes them.
| ID | Level | Default severity | Fires when |
|---|---|---|---|
MDL-1 |
drift | high | a repository’s check hasn’t run for 2 days, or never has |
MDL-2 |
drift | medium | its ARCH-PIN-1 has been open for 14 days |
MDL-3 |
drift | low | an implemented component has no test file the model can point to |
MDL-4 |
drift | low | a component has no owner, in the model or CODEOWNERS |
MDL-5 |
drift | low | a component has been planned for 60 days |
MDL-6 |
drift | low | a component with open findings had no merged pull request under its paths for 180 days |
How a finding lives
- Identity. A finding is identified by its rule, repository, component, file and subject, so the same problem keeps the same ID from run to run. Moving a line doesn’t make a new finding.
- Open and fixed. A finding is open while checks keep reporting it, and fixed when a check on the default branch no longer does. Each finding records when it was first and last seen, and its age.
- Reopened. A finding that comes back keeps its ID and its history.
- The fix. The dashboard names the pull request that probably fixed it: the one whose merge commit the fixing run checked, else the newest one merged under the finding’s component in between.
- Notes. Agents can leave notes on a finding; they show newest first, labelled self-reported.
Coming soon
- Enforcement modes per rule and layer: block, require approval, warn or monitor.
- Exceptions: time-limited waivers with an owner, a reason, an expiry and an approver.