Self-Checks

A Self-check reviews a few changed files against the project’s policies while the change is still on the developer’s machine. It tells the developer, or their coding agent, whether those files break a policy, before anything is committed or pushed. A Self-check is not a scan. It creates no findings and doesn’t change the project’s posture, which is its overall status on the Dashboard. It’s advice for the person making the change, not a record of the project. The merge gate on the pull request still decides what merges.

​

When a Self-Check Runs

Earnie runs a Self-check when:

• a coding agent finishes a turn, and the review hook from earnie mcp setup sends its changed files. Review hooks exist for Claude Code, Cursor, and Codex.
• a coding agent calls earnie_review_code itself, over Earnie MCP
• the pre-commit hook runs, before a commit lands
• someone runs earnie scan staged or earnie check by hand

Each time, Earnie reviews only the files it receives, not the whole codebase. If a project has no Self-checks yet, set up one of these: install the hook with earnie hook install, or connect a coding agent.

​

Finding a Self-Check

A project’s sidebar has a Self-checks entry next to Scan history. Self-checks never appear in the scan history. You can narrow the list:

• Search matches a policy name, a detection’s file path, or its summary.
• Gate shows only runs with one outcome.
• Producer shows only runs from one source.
• The status toggle shows only Running, Completed, or Failed runs. Each choice shows how many runs it holds under the other filters.

The page’s address keeps the search, the filters, the sort, and the page, so a link opens the same view. When nothing matches, the page names the filters that are on and offers Clear filters. The list has these columns: A run reads Failed if its upload stopped, for example because a hook timed out or a commit was interrupted. Earnie gives up on such a run after an hour without activity.

​

Reading a Self-Check

Open a run to see its detail.

​

The Verdict

The Verdict card shows the gate and states it in one sentence. It also says:

• how many policies produced no verdict, if any. The gate doesn’t cover them.
• how many files Scan Configuration excluded, if any. The gate doesn’t cover those files either.
• the coverage, which is always Partial. See Why a Pass Does Not Cover Everything.
• for a failed run, the error code and message.

​

What the Gate Means

The gate uses the same terms as a scan’s gate:

​

The Run Card

Next to the Verdict, the Run card shows the run’s details:

• its status and producer, and the actor that started it, such as an API key
• when it was created and finished, and when it expires
• how many files were submitted, included, and excluded
• how many policies and detections Earnie evaluated
• which scanners ran, and why any didn’t. A scanner might not be enabled for your organisation, be outside the API key’s scope, not have been requested, or be unavailable on your Earnie.
• for a coding agent’s run, the files that were already modified before the agent’s turn and changed again during it

​

Violations

Violations has one entry for each policy the files broke, worst first. Each entry shows:

• the policy, at the revision Earnie evaluated
• the detections that triggered it, each with a file and line, the kind of detection, and what Earnie saw
• a remediation, where Earnie can work one out

A remediation has a tier, a short summary, and a Remediation prompt written for a coding agent. Copy prompt copies the prompt exactly as written. The tier says what kind of advice it is: Detections are not findings. Earnie keeps them only as long as the Self-check, and they never enter the Review queue.

​

Found

Found lists everything the scanners found in the submitted files, whether or not a policy fired on it. A run with no violation still shows what the code contains. Rows are grouped by file, and each row shows:

• the kind: open source, dependency, crypto, or AI
• the component and its purl, where the detection names one
• the lines: for an open source match, the submitted lines and the lines they match in the open source file, such as 3-40 → 120-157
• the match type and percentage of an open source match, such as Snippet 87%
• the licence
• the number of known CVEs, with the worst severity
• the policy that fired on it, linked to its violation, or No policy fired

A Self-check keeps at most 500 detections. When it found more, the section says so with the real numbers, such as Showing 500 of 642, and every detection a policy fired on is still listed. A run that found nothing says Nothing found and names the scanners that looked. A scanner that didn’t run looked at nothing, so it’s never counted as having found nothing.

​

Why a Pass Does Not Cover Everything

Some policies get no verdict on a Self-check, most often because it sees only some of the codebase. The Not evaluated list shows each of them, with the reason: So a Pass means nothing Earnie reviewed violated a policy. It doesn’t mean the change meets everything the project enforces. For the same reason, a Self-check’s coverage is always Partial. It reviews the files it was given, never the whole codebase, so it can’t mark anything as gone from the project. See Coverage: Full vs Partial.

​

The Trail

At the bottom of the page, the Trail shows the run’s own history. Each event shows who caused it and when:

• Submitted shows how many files the run received, and when it expires.
• Completed shows the gate, the coverage, how many policies Earnie evaluated, and the violation and detection counts.
• Failed shows why the run failed.

​

How Long Earnie Keeps a Self-Check

Earnie keeps a Self-check for 30 days, then purges it, with its detections. The Trail outlives the run, because Earnie reads it from the audit log, not from the run:

• After the run is purged, its link opens “This Self-check was purged”, with the Trail still shown.
• If the link shows “Self-check not found”, with no Trail, the ID in the link is wrong, or the audit log no longer has the run’s history either.

​

What’s Next

Self-checks and the merge gate keep problems out of your code. To give people outside your team evidence of what your code contains, export an SBOM.