Regulated teams review, version and baseline their requirements, risks and the links between them and the code. Neural Inverse keeps all of that in your repository under .neuralinverse/, links work items from the tracker you already use, and checks it at commit, merge and release. The views in the Editor tell you what will block; CI decides.
Set your intent
Say what you are working on before you start. Your intent is the work item or change request, and the requirements, a piece of work addresses.
- Click the intent item in the status bar (it reads No Intent, or Intent required by policy; none set), or run Set Intent....
- Pick the work item from your tracker (the picker searches as you type) or type its key.
- Name the requirements it addresses, or choose Name requirements only.
The status bar then shows Intent: and the work item. Your intent:
- is recorded in the activity record, and each agent session started under it records it too;
- lets agents work where the policy requires an intent: until you set one, the agent host refuses sessions in that repository, including sessions the Agents app runs in a worktree;
- is added to your commits as a
Work-Item:trailer (or the trailer key your policy names) by theprepare-commit-msghook, for commits made in the app and in its terminals; - keeps agents to the code linked to its requirements, where the policy confines them.
Run Clear Intent when the work is done. An intent may name at most 100 requirements.
Install the git hooks once per clone:
scripts/ni-gov.sh hooks installThis installs pre-commit, commit-msg, pre-push and prepare-commit-msg. Existing hooks are kept as <name>.local and still run. ni-gov is in the Neural Inverse source (scripts/ni-gov.sh, or scripts/ni-gov.bat on Windows).
Repository layout
.neuralinverse/project.json the project
.neuralinverse/requirements/<ID>.md one requirement per file
.neuralinverse/risks/<ID>.md one risk per file
.neuralinverse/trace/links.json every trace link
.neuralinverse/change-requests/<KEY>.json one change request per file
.neuralinverse/baselines/<release>.json one baseline per release
.neuralinverse/records/ approvals and signaturesRequirement and risk files are Markdown with front matter in a small, strict subset of YAML (key: scalar, key: [a, b] and block lists of scalars). Comments, nesting, anchors and multi-line values are refused with the line number. Ids look like tracker keys (REQ-12, HAZ-7) and must match the file name. Every file is checked with size limits, because anyone with push access can edit it.
Project Overview and Traceability
Open the Governance panel.
- Project Overview shows the project's requirements, risks, work items and releases.
- Traceability shows each requirement against its code, tests, risks and approvals, with coverage.
Suspect links
When a requirement or risk changes, every link from it becomes suspect: what the link claimed was checked against different text. Layout-only edits do not change an item's digest; any changed word does.
- Open the suspect link in Traceability ("Confirm the link from ... to ... still holds").
- Check that the linked code or test still holds.
- Choose Mark Reviewed. Your name and the time are recorded.
Suspect links block a release when the policy says so, and only reviews by people the policy enrols count.
Trackers
| Tracker | What it does |
|---|---|
| Jira (Cloud and Data Center), Azure DevOps Boards, GitHub Issues, GitLab Issues | Work items, links, optional status updates |
| Polarion, Jama | Requirement import and links |
| IBM DOORS Next (OSLC RM) | Requirement import and links |
| Linear | Work items and links |
- Set Tracker Credential... stores your token for a tracker in the OS credential store, under a key that includes the tracker kind, address and project. Clear Tracker Credential... removes it.
- Import Requirements from Tracker... brings requirements (and work items) into the repository without overwriting local items.
- Link Work Item to Commit... links a work item to your current commit.
Only identifiers and links are ever sent to a tracker, never source code. HTTPS only, and a redirect to another host is refused. Status updates in a tracker happen only where your organisation's signed policy opts that tracker in, and when the policy lists trackers, a connection not on the list is refused.
Each adapter is tested against recorded responses from the vendor's documented API, not against live tracker instances.
Baseline a release
- Run Create Release Baseline....
- Give the release (Create Baseline: Release), the full commit hashes of the release (Create Baseline: Commits), and, when asked, the sign-off rule.
- The baseline is written to
.neuralinverse/baselines/<release>.json. It freezes the digest of every requirement and risk, the trace links, the approval requests in force, the commits and the project file. - When the policy names a release approval rule, the sign-off is requested in the Approvals view ("Baseline ... created (digest ...). Its sign-off was requested in the Approvals view."). Signing it is a governance approval like any other.
After a baseline, the policy can require an approved change request for a change to a baselined requirement or to code of a governed safety class.
Release Readiness
The Release Readiness view and Check Release... show what blocks a release and who must act: open risks, suspect links, requirement coverage, a missing or changed baseline, and the sign-off. The view is a preview; the binding verdict is ni-gov release check in CI.
The gates
| Gate | Where | What it checks |
|---|---|---|
| Commit | pre-commit and commit-msg hooks | The work item trailer and the Checks controls |
| Push | pre-push hook | The trailer of every pushed commit |
| Merge | CI, ni-gov gate merge on the exact commit | Trailers, controls, every approval record verified, change set approvals bound to the exact content |
| Release | CI, ni-gov release check | Baseline integrity and freshness, release sign-off, open risks, suspect links, requirement coverage |
A failing check prints what failed and why, the waiver that applied, and the control and framework requirement it maps to. --no-verify only postpones the answer to CI.
In CI, on the exact commit, with keys from configuration the pull request cannot change:
ni-gov gate merge --base origin/main --head HEAD --trusted-keys "$NI_POLICY_KEYS_FILE"
ni-gov release check 2.4.0 --trusted-keys "$NI_POLICY_KEYS_FILE" --test-results results.jsonWithout --trusted-keys, a CI runner has no product keys or managed policy and the gate binds nothing. Exit codes: 0 pass, 1 refused, 2 error or tampering. Every gate result is recorded as a governance.gate event.
What is not claimed
The views are not the verdict; CI is. Tracker data is what the tracker returned. Requirement coverage measures links and test results supplied to the run, not whether the tests are adequate.