Overview

The rule ids are the shared vocabulary between the auditor script, the triage step, and the agent acting on the report. A finding is cited by id, a severity override in the spec is keyed by id, and a run-over-run delta is counted by id. This page is the reference. How to run the auditor and triage what it finds is in vault-audit.

Read the structural rules as framework-agnostic

C-rules fire on every vault regardless of framework. They check shape, links, dates, and whichever fields the spec declares required.

RuleFindingSeverity
C000Frontmatter unparseablecritical
C001Orphan atom, no inbound or outbound linkswarning
C002Broken wikilinkwarning
C003Missing frontmatterwarning
C004Filename does not match the type’s patternwarning
C005Decision modified after its decision datecritical
C006Undigested source, zero atoms extracted past the age thresholdinfo
C007Decision past its expected resolution datewarning
C008Required field missing or emptywarning
C009Atom past the atomicity byte thresholdwarning
C010Stale seedlinginfo
C011Publishable claim failing the corroboration or legal gatecritical
C012Stale verification on a decision-relevant claimwarning
C013Unresolved contradiction past its aging thresholdinfo
C014Note filed outside its type’s folderwarning
C015Content note with an absent or unmappable typewarning

The three criticals protect provenance. Unparseable frontmatter (C000) hides a note from every other check. A decision edited after its date (C005) is a hindsight rewrite, per decision-journals. An under-corroborated publishable claim (C011) breaks the gate in source-verification.

C015 matters more than it looks. Without it, a note with no type silently evades every per-type check, so the cleanest way to pass the audit would be to strip the field that makes a note checkable.

Read the schema rules as prefix-triggered

S-rules encode a rigor framework and fire only on notes that opt in by type or filename prefix, per rigor-frameworks. Existing notes in another framework are untouched.

RuleFindingSeverity
S003Theme atom with fewer than three linked data pointswarning
S004Result atom not linked to a hypothesiswarning
S006Objective atom missing concept, example, or assessment linkswarning
S007ADR missing an alternatives sectionwarning
S008Decision missing key_atomswarning
S009Naked link dump in an atominfo

S001, S002, and S005 are reserved for future built-in rules. Custom rules a vault declares take a U prefix (U001, U002) so they never collide with a reserved slot.

Treat M000 as a failed run, not a warning

M000 fires when vault-spec.yaml is missing or unparseable and the auditor fell back to built-in defaults. It is emitted as a warning precisely so the run exits non-zero, and spec_status in the JSON summary reads missing or invalid. A clean count sitting next to M000 says nothing about the vault’s real rules; generate or repair the spec before triaging anything else.

Override severities in the spec, never in the script

severity_overrides in the spec maps a rule id to a severity. The defaults stay in the script; the vault’s opinion lives in its spec, alongside the per-type fields described in vault-frontmatter-schema.

Autofix only the mechanical tier

The auditor’s --fix mode repairs what it can derive with certainty and nothing else.

  • C003, missing frontmatter. Adds a block, with type taken from the folder when that folder maps to exactly one type.
  • C008, missing required field. Fills id from the filename, created and modified from file mtime, status with the seedling default, and the structural tags. Semantic fields (title, sources, confidence, decision_date) stay open for a human.
  • C015, untyped note. Sets type from an unambiguous folder.
  • C002, broken link. Repairs only when exactly one filename matches the target.

Everything else is left alone. An autofix that invents a title, a source, or a confidence value is fabricating research provenance. Dry run is the default, --apply writes, and an un-versioned vault is refused without a further --force, because there is no undo otherwise. The case where a field becomes newly required across many notes is handled as a migration in vault-schema-migration.