Rule packs
See the v1 Integrity rule packs for identifiers, traceability, stale references, import readiness, and baseline gates.
Integrity v1 uses code-defined rule packs. Workspace admins cannot create arbitrary custom linter rules in this release.
Each rule pack adapts existing product checks into the shared Integrity finding contract: stable code, severity, enforcement, scope, display-safe evidence, visibility, remediation mode, and action target.
Identifier health
Identifier findings protect the workspace-wide artefact identifier invariant.
Examples:
- duplicate normalized identifiers
- next generated identifier collision
- missing source prefix
- identifier counter drift
- import identifier collision risk
- legacy or custom identifier prefixes
- shared prefix advisory
Shared prefixes are informational unless they create a concrete identifier or generated-identifier collision. Prefix changes use a controlled cascade only when every generated artefact identifier can preserve its number.
Traceability
Traceability findings come from Trace Schema and saved links.
Examples:
- missing required outgoing link
- link outside Trace Schema
- source or target kind mismatch
- stale Trace Schema
- disabled link type
- source-to-self warning
- risky overlapping rules
- duplicate schema rule
Required-link findings keep Open artefact as the primary remediation target. When Integrity can identify exactly one required Trace Schema config and the user can view the source, the finding also includes a Coverage secondary action.
Stale references
Stale-reference findings show active configuration that still points at lifecycle-disabled or unavailable objects.
Examples:
- disabled or archived source kind reference
- disabled or archived artefact kind reference
- disabled link type reference
- stale source reference
These findings help admins clean up configuration without losing the history of why it became stale.
Import readiness
Import readiness findings come from import reports and preflight checks.
Examples:
- blocking import readiness errors
- warning-level readiness findings
- identifier collision risks discovered before import
Import readiness remains the authoritative import surface. Integrity makes the findings visible at workspace level and links back to the import report or workbench.
Baseline and release gates
Baseline findings show when release evidence cannot safely lock.
The main v1 baseline rule is a required-link blocker: if baseline eligibility depends on required trace links and those links are missing, the baseline cannot lock until the evidence is complete.
Baseline locking remains server-authoritative. The Integrity finding explains the blocker and routes users to the evidence surface; it does not bypass baseline eligibility checks.
Future candidates
Future rule packs may cover access/governance health, Spec-Driven Development evidence quality, roadmap metadata health, setup/template completeness, field mapping, package exchange, release-context completeness, baseline-impact review, change-proposal review, and audited risk-acceptance workflows.
Future rule packs should use the same display-safe redaction, realtime/cache, remediation, and human-approval boundaries as the v1 rule packs.