---
name: Validate Skill - Audit Rubric
description: Per-check rubric the validate skill applies to a deployed instance. Encodes BOOTSTRAP-BRIEF Sections III, IV, X, XI as concrete pass/fail/finding criteria. Reference document; the skill's SKILL.md encodes the procedure.
type: reference
---

# Validate Skill - Audit Rubric

- **Last reviewed:** 2026-04-28
- **Review cadence:** on-event (refresh when SKILL.md or BOOTSTRAP-BRIEF revises the rubric)
- **Status:** active

This rubric tells the `validate` skill exactly what to check and how to score. It implements BOOTSTRAP-BRIEF Sections III (maturity scale), IV (relationship semantics), X (audit standard), XI (failure modes) as discrete checks.

## Maturity scale check (per layer)

For each of L0, L2, L3, L4, L5 (per platform), L7:

| Score | Criteria |
|-------|----------|
| **none** | Layer artifact does not exist OR exists but has no content beyond frontmatter |
| **stubbed** | Artifact exists with right shape (template-derived) but body contains "TBD", template placeholders, or generic content not specific to this instance |
| **partial** | Artifact has instance-specific content but is incomplete; either content gaps named in artifact OR the artifact's "Maturity self-assessment" table reports any aspect as `none` / `stubbed` / `partial` |
| **mature** | All aspects in maturity self-assessment report `mature`; last-reviewed within cadence; the artifact's content survives the question "could a capable replacement operate from this artifact alone" |

L1 has a fifth score: `N/A-explicit` (the layer was consciously excluded with rationale; only valid when Q1's function type is `internal-tool`, `internal-platform`, or `external-api`).

L6 lives inside L5 dossiers; not separately scored.

## Relationship classification check

For each declared relationship in HANDOFF.md cross-pod table + L4 mirror manifest + L7 cross-platform participation:

| Status | Criteria |
|--------|----------|
| **live** | Relationship has been exercised end-to-end at least once with verification within reasonable window (varies by relationship type; see below) AND the artifact naming the relationship has a `last verified` date present |
| **declared-but-inactive** | Relationship is documented but verification is missing, stale, or last verification failed; default state until evidence shows otherwise |

Verification windows per relationship type:

| Type | Reasonable window |
|------|------------------|
| Mirror | within cadence period (e.g., biweekly) |
| Inbox-outbox | within drain cadence (e.g., weekly to biweekly) |
| Handoff (runtime envelope) | within 7 days (continuous traffic expected) |
| Cross-platform runtime call | within 7 days |
| Inheritance (static) | once per quarter (re-confirmed during quarterly review) |
| Runtime auth | within 30 days OR continuous (every call validates) |
| Event subscribe | within 30 days OR continuous |

A relationship with no `last verified` date is `declared-but-inactive`; do not infer from artifact existence.

## L7 six-concern check

Per cross-platform/L7-glue.md:

| State | Criteria |
|-------|----------|
| **exists-mature** | Artifact present + named owner + last-verified-live within 30 days + participating L5 platforms enumerated |
| **exists-partial** | Artifact present + content but incomplete + gap named explicitly |
| **declared-not-built** | Concern named but no implementation; closes-by date present (or `unscheduled` with BACKLOG entry) |
| **none-applicable** | Concern genuinely does not apply; one-sentence justification present |

`unknown` is **prohibited**. Any concern reporting `unknown` is a blocking finding.

## ADR catalog check

For each ADR in decisions/:

- Status one of: `proposed`, `accepted`, `superseded by ADR-XXXX`, `deprecated`
- Date present
- Reversibility named
- Deciders named
- Scope named
- Context, Decision, Options, Rationale, Consequences sections all present

For each session log + drained inbox entry + commit message in the audit window:

- Look for evidence of decisions matching BOOTSTRAP-BRIEF Section VII criteria (2+ real options, non-trivial reversibility, etc.)
- Cross-check against decisions/; if a decision lacks an ADR, surface as a finding

## Behavior trigger encoding check

For each trigger in BOOTSTRAP-BRIEF Section V, scan for:

- Encoded location (a doc, skill, checklist, or runbook)
- OR a record showing the trigger was applied recently (session log evidence)

If neither: trigger is memory-only; surface as a finding.

Specific triggers and where they should be encoded in a deployed instance:

| Trigger | Expected location |
|---------|-------------------|
| Read brief at session start | OPERATING-MODEL "What to do if you are new here" + CLAUDE.md |
| Write ADR for 2+-options decision | decisions/ folder + ADR-template + architect-adr skill |
| Doc Lifecycle frontmatter on every artifact | architect-lifecycle skill + every artifact's frontmatter |
| Per-layer maturity not binary | MATURITY-SCORECARD format itself |
| Mark L1 N/A explicitly for internal functions | policies/brand-posture.md when N/A-explicit |
| Mirror relationship default to declared-but-inactive | cross-platform/L7-glue.md + kit/PLATFORM-KIT.md mirror manifest |
| Concurrent-session lock-on-write | HANDOFF.md concurrent-actor section + L5 dossier lock-on-write boundaries |
| Five-question decision framework | CLAUDE.md decision framework section |
| Drain inbox on cadence | inbox-topology.md drain protocol + recent session-log evidence of drains |
| Session log on state-change session | sessions/ directory + session-log template + architect-handoff skill |

## Concurrent-actor surface check

For each surface where multiple actors may touch (policies/, kit/ locally-owned components, platforms/{platform}/ artifacts, BACKLOG.md, inbox/):

- Lock-on-write boundary defined in HANDOFF.md or L5 dossier?
- Coordination mechanism named (Slack channel, PagerDuty schedule, formal review)?

If either missing: finding for the surface.

## Vocabulary consistency check

Scan all audited markdown for these terms used outside their BOOTSTRAP-BRIEF Section VI definitions:

| Term | Defined meaning |
|------|----------------|
| layer | One of L0-L7 as defined |
| maturity | Four-step scale (none / stubbed / partial / mature) |
| live | Relationship whose effect is verified end-to-end |
| declared-but-inactive | Relationship existing on paper without verification |
| ADR | Immutable record of 2+-real-options decision |
| mirror | One-way-synced copy with MIRRORED FROM header |
| pod | Self-contained unit with own governance scaffolding |

A term used with a non-standard meaning in a way that obscures audit intent is a finding. Everyday-language uses ("the lead is live") are not findings unless they create ambiguity.

## Failure-mode trigger check (BOOTSTRAP-BRIEF Section XI)

| Failure mode | Detection rule | Severity rule |
|--------------|---------------|---------------|
| Path-to-layer pattern matching | Any layer classification that traces only to folder paths without artifact analysis | High if shipping; medium if in drafts |
| Binary existence checks | Any layer status using "exists" or yes/no language | Medium |
| Missing L7 awareness | L7-glue.md has fewer than 6 concern rows OR a row with `N/A` lacking justification | High |
| Static inventory vs. assessment | An "audit" output that lists files without maturity classification | Medium |
| Overclaimed completeness | Use of "complete" / "done" / "shipped" / "ready" without per-layer maturity backing | High |
| Floating concepts | Terms appearing in artifacts that do not map to L0-L7 or named relationships | Low (note); High (if material to operating posture) |
| Untested relationships | Relationships described in present indicative ("inherits", "mirrors", "drains") without `last verified` evidence | High if mirror or cross-platform; Medium otherwise |

## Single highest-leverage next move

After all findings collected, apply this priority order to identify the single move:

1. Any blocking finding (must resolve before deployment can be declared complete)
2. Any L7 concern reporting `unknown`
3. Any layer demoted from `mature` to `partial` due to drift (drift resolution returns the layer)
4. Any relationship reporting `declared-but-inactive` that another mature layer depends on
5. Any missing ADR for a visible decision
6. Any memory-only behavior trigger
7. Any concurrent-actor surface without protocol
8. Any failure mode detection that is shipping
9. Any L6 refinement concern with target-miss
10. Any non-blocking finding with the largest downstream-unblocking effect

The validate skill picks the **first applicable** item from this priority order, and states the move as: what, who, when, why-it-unblocks-the-most.

## Findings categorization

| Category | Definition |
|----------|-----------|
| Blocking | Cannot declare deployment complete; deploy skill pauses on these; must be resolved or accepted |
| Non-blocking | Surface in scorecard; include in next-move candidates; do not block deployment |

Blocking finding examples:

- L7 concern reporting `unknown`
- Behavior trigger that is memory-only AND that trigger relates to a red line
- ADR missing for a visible compliance-affecting decision
- Validate has not been run on the instance before; first-time landing is not "complete" until first validate passes

## Scorecard output

Per template at `templates/MATURITY-SCORECARD-template.md`:

- Per-layer maturity table
- L7 six-concern table
- Per-relationship classification table
- ADR catalog
- Visible decisions missing ADRs
- Behavior trigger encoding check
- Concurrent-actor surface review
- Vocabulary consistency findings
- Failure-mode trigger check
- Single highest-leverage next move

Render to `{instance_root}/MATURITY-SCORECARD.md`. Cross-update OPERATING-MODEL.md's next-move section.
