Checks

Checks makes compliance a live property of your work. As you and agents change code, it records how each change came to exist, works out which requirements the change affects, keeps track of which evidence is still valid, and evaluates your organisation's controls against all of that. It is deterministic: the Editor, the CLI and CI produce the same findings.

Checks supplies facts. Decisions (what is allowed, what blocks, what needs approval) belong to your organisation's governance policy. See Organisation policy.

What Checks looks at

Nothing a model produces is a finding, and nothing a model produces can block. A model can propose; a person attests.

The Checks view

Open it from Panel > Checks, or click the shield in the status bar. It shows the controls of the packs in force for the current git change set, each satisfied, unsatisfied (with the exact location), not applicable, or unknown. Unknown facts never count as satisfied.

The status bar shield also shows when the provenance ledger does not verify; evaluation then stops until the problem is resolved.

Findings of the analyzers also appear in the editor and in the Problems panel as you type, while neuralInverse.checks.enabled is on (the default). That setting is always governed: a value in a settings file is ignored, so Checks cannot be switched off from settings.json.

Only signed rules block

• The baseline pack shipped with the Editor is unsigned, so its findings are advisory.
• Packs in your organisation's signed policy bundle are signed, and their controls can block or require approval.
• Packs found in a workspace are advisory and never block, even if they claim to be signed.
• Waivers come only from the signed policy (or from waiver requests approved under it). There are no local dismissals.

Try it: link a requirement and record a review

This walk-through uses a git repository and a small requirement registry.

1. Run Edit Requirement Registry. It opens the project's registry, creating an empty one in the project's Checks data folder (neural-inverse-checks/<quality>/<repository digest> in the data folder both apps share, outside the repository). Add requirements with anchors:

   {
       "requirements": [
           {
               "id": "REQ-42",
               "title": "Dose never exceeds the configured limit",
               "status": "approved",
               "tests": ["T-dose-limit"],
               "anchors": { "symbols": [{ "name": "check_dose_limit" }], "paths": ["src/dosing/**"] },
               "risks": ["R-7"]
           }
       ]
   }

2. Edit a file under src/dosing/. The control Changes trace to an approved requirement becomes unsatisfied ("No requirement is linked to this change").

3. Run Set Requirement for This Change (or use the action on the gap) and pick REQ-42. It is listed first, as in the blast radius.

4. Ask an agent to change the same file. Its region is recorded as agent-written, and Agent-written code is reviewed by a human becomes unsatisfied at that location.

5. Review the change, then run Record Review of This Change.

6. Run your tests from the Testing view. The run is recorded against the content digests of the changed files; editing a file afterwards invalidates that evidence for it.

7. Commit. Checks evaluates the commit's own diff and writes an evaluation record (records/<commit>.<pack>.json in the project's Checks data folder) with a reproducible digest. In the Editor the record is marked unsigned.

Adding a dependency (to package.json or any of 63 manifest formats) is reported by the Added dependencies are approved control. Approved-component lists are not yet delivered to the device, so today no added dependency counts as approved.

Paste an AWS key id or a -----BEGIN PRIVATE KEY----- block into any file, including .env or Markdown, and it is reported at once, with only the first four characters shown.

Requirement properties

A property is a testable statement derived from a requirement and implemented by a test. Propose Properties for Requirement asks a model for candidate statements and test skeletons; nothing it produces is evidence. A property counts as verified only when a person approved the exact statement (Approve Requirement Property), the test is linked to the requirement, and the test passed on the current content.

Checks and agents

• Every chat request in a governed repository carries the live compliance state as instructions: the signed packs, the declared requirements and their blast radius, the files in scope, and the open obligations.
• Agents read their obligations with the complianceStatus tool and can declare a requirement with declareRequirement.
• When the policy confines agents to their intent, an edit outside the files linked to the declared requirements needs a person. Scope widens only by a person's decision.

Commands

The same engine in CI

scripts/ni-checks.sh in the Neural Inverse source runs the same engine on a repository from Node, with the same grammars and packs:

scripts/ni-checks.sh --repo /path/to/repo --base origin/main --gate merge \
  --requirements requirements.json \
  --bundle policy.bundle.json --trusted-keys keystone-keys.json \
  --out checks-records/

To re-derive the Editor's record for the exact commit instead of trusting it:

scripts/ni-checks.sh verify --record checks-records/org.medical.json --commit "$GIT_COMMIT" \
  --bundle policy.bundle.json --trusted-keys keystone-keys.json --gate merge

The output folder receives, per pack, an evaluation record, OSCAL assessment results and an in-toto statement. Pass --ledger <dir> with a ledger exported from the Editor to carry authorship, reviews and test evidence into CI; without it those facts are unknown and the controls that need them fail closed.

The CLI runs the same analyzers on every change an agent proposes and at commit. See CLI.

What is not claimed

Coverage of a framework is only what a signed, specialist-reviewed pack maps. Results are evidence toward requirements, not certification.