Integrity
Integrity

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 Admin Editor Viewer

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 Admin Editor Viewer

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 Admin Editor Viewer

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 Admin Editor

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 Admin Editor Viewer

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.

On this page