---
name: validate
description: >
  Post-deployment audit skill. Encodes the failure-mode rubric from BOOTSTRAP-BRIEF Sections
  III, IV, X, and XI. Produces a maturity scorecard plus a single highest-leverage next move.
  Triggered by the deploy skill (Step 6) and on demand when the operator says: "validate this
  instance", "audit the deployment", "is this mature", "run the validate skill", "check
  maturity", "what's the audit say", "is the operating model intact". Refuses to mark any
  layer mature without naming evidence; demotes layers whose mirrors or relationships are
  declared-but-inactive; surfaces visible decisions that should have ADRs but do not. Outputs
  to {instance_root}/MATURITY-SCORECARD.md per the template.
---

# validate

Post-deployment audit. Maturity scorecard + single highest-leverage next move. Refuses to mark mature without evidence; demotes drifted relationships; surfaces missing ADRs.

## When to invoke

- Immediately after the deploy skill completes its template rendering (deploy Step 6)
- Operator says: "validate this instance", "audit the deployment", "is this mature", "run the validate skill", "check maturity", "what's the audit say", "is the operating model intact"
- On every material change (a layer artifact updated; a new ADR landed; a mirror sync ran; an L5 dossier added)
- Quarterly minimum per the deployed instance's MATURITY-SCORECARD review cadence

## Operating procedure

### Step 1: Read the rubric

Read `RUBRIC.md` (in this skill's directory) for the failure-mode checks and per-layer evaluation rules.

Read `BOOTSTRAP-BRIEF.md` Sections III (maturity scale), IV (relationship semantics), X (audit standard), XI (failure modes).

### Step 2: Inventory the instance

Walk `{instance_root}/`:

- `policies/` - L0 through L3 artifacts
- `kit/` - L4 components and contracts
- `platforms/` - L5 dossiers
- `cross-platform/` - L7 concerns
- `decisions/` - ADR catalog
- `inbox/` - inbox files
- `sessions/` - session logs
- `BACKLOG.md`, `HANDOFF.md`, `OPERATING-MODEL.md`, `LOCALIZATION-ANSWERS.md`, `inbox-topology.md`

For each artifact: read frontmatter; read body; classify against the maturity scale.

### Step 3: Per-layer maturity

For each of L0-L7 (skipping L1 if N/A-explicit and L6 which lives inside L5 dossiers):

1. Read the layer artifact
2. Apply the four-step scale (`none`, `stubbed`, `partial`, `mature`)
3. Identify the gap if not `mature`
4. Identify retrofit risk (low / medium / high) if gap exists

Refuse to mark `mature` without naming evidence in the scorecard row. Evidence shapes:

- Last-reviewed date within cadence
- Recent session log confirming the layer was operated against
- Validate-scoped check that the artifact's content is non-stubbed (no "TBD", no template placeholders left unsubstituted)

### Step 4: L7 concern check

Per `cross-platform/L7-glue.md`:

For each of the six concerns (shared memory, shared identity, handoff protocol, consent flow, alerting fabric, monitoring base):

1. Read the concern's artifact
2. Classify state (`exists-mature`, `exists-partial`, `declared-not-built`, `none-applicable`)
3. Verify owner is named (not "the team")
4. Verify last-verified-live date is present and within reasonable window

`unknown` is not a permissible state per Q8's hard rule. If any concern reports `unknown`, that is a blocking finding.

### Step 5: Per-relationship classification

Walk `HANDOFF.md`'s "Cross-pod relationships" table plus `kit/PLATFORM-KIT.md`'s mirror manifest:

For each relationship:

1. Determine type (mirror / inbox-outbox / handoff / cross-platform / inheritance / runtime-call / runtime-write / runtime-subscribe)
2. Classify status: `live` (verified end-to-end recently) or `declared-but-inactive` (drift exists or never verified)
3. Note last-verified date

Default assumption is `declared-but-inactive` until evidence shows otherwise. A relationship reported as `live` without evidence in this audit gets demoted.

If a layer's maturity depended on a relationship being `live` (e.g., L4 depends on mirrors being current), and that relationship is now `declared-but-inactive`, demote the layer.

### Step 6: ADR catalog scan

Walk `decisions/`:

1. List all ADRs with status, title, date
2. Cross-check session logs and inbox-drained entries for decisions that should have ADRs but do not (per BOOTSTRAP-BRIEF Section VII criteria)

Findings: missing ADRs surface in the scorecard's "Visible decisions that should have ADRs but do not" section.

### Step 7: Behavior trigger encoding check

For each behavior trigger in BOOTSTRAP-BRIEF Section V:

- Encoded somewhere persistent (a doc, a skill, a checklist, a runbook)?
- Or memory-only?

Memory-only triggers are findings.

### Step 8: Concurrent-actor surface review

For each surface where multiple actors may touch:

- Lock-on-write boundary defined?
- Coordination mechanism (Slack, PagerDuty, session log) named?

Surfaces without protocol are findings.

### Step 9: Vocabulary consistency check

Scan all audited artifacts for use of BOOTSTRAP-BRIEF Section VI vocabulary (`layer`, `maturity`, `live`, `declared-but-inactive`, `ADR`, `mirror`, `pod`).

Findings: any term used with a non-standard meaning in a way that obscures the audit.

### Step 10: Failure-mode trigger check

For each failure mode in BOOTSTRAP-BRIEF Section XI:

- Detect instances in this instance's artifacts
- Severity: high / medium / low based on whether the failure is shipping (in production behavior) or contained (in drafts)

Per failure mode:

- **Path-to-layer pattern matching:** any layer classification that traces only to folder paths
- **Binary existence checks:** any layer status using "exists" or "yes/no"
- **Missing L7 awareness:** any audit table with fewer than the expected L7 rows or `N/A` without justification
- **Static inventory vs. assessment:** any "audit" output that lists files without classification
- **Overclaimed completeness:** any "complete" / "done" / "shipped" / "ready" without per-layer maturity backing
- **Floating concepts:** terms appearing in artifacts that do not map to a layer or relationship
- **Untested relationships:** relationships described in present indicative without verification

### Step 11: Determine single highest-leverage next move

From all findings + all gaps + all retrofit risks, identify the **one** move that:

- Matures the most layers, OR
- Repairs the most relationships, OR
- Closes the most behavior-trigger gaps, OR
- Resolves the highest-severity finding

Not three. One. State it specifically: what, who, when, why-it-unblocks-the-most.

### Step 12: Write the scorecard

Render `{instance_root}/MATURITY-SCORECARD.md` per the template in `templates/MATURITY-SCORECARD-template.md`.

Update `{instance_root}/OPERATING-MODEL.md`'s "Single highest-leverage next move" section to match the scorecard.

### Step 13: Return findings classification

Categorize findings:

- **Blocking:** cannot declare deployment complete (e.g., L7 concern is `unknown`; behavior trigger is memory-only and that trigger relates to a red line)
- **Non-blocking:** include in scorecard; surface as next-move candidates

Return both lists to the caller (typically the deploy skill or the operator).

## Refusal conditions

- **Refuse to mark a layer mature** without naming evidence in the scorecard row
- **Refuse to mark a relationship live** without naming the verification event
- **Refuse to omit an L7 concern** even if `none-applicable` (must include row with justification)
- **Refuse to declare an instance complete** if any blocking finding exists

## Cross-references inside the kit

- `BOOTSTRAP-BRIEF.md` Sections III, IV, X, XI - the rubric source
- `QUESTIONS.md` - Q8 hard rule on L7 unknown
- `templates/MATURITY-SCORECARD-template.md` - the output shape
- `examples/martech-mature-instance/MATURITY-SCORECARD.md` - reference example
- `RUBRIC.md` (in this skill's directory) - per-check details
- `skills/architect-audit/SKILL.md` - the layer-mapping skill (this skill calls it for layer scoping)
- `skills/architect-lifecycle/SKILL.md` - paired for staleness checks against frontmatter
- `skills/architect-kit-mirror/SKILL.md` - paired for Mode C drift detection during Step 5
- `skills/deploy/SKILL.md` - invokes this skill during Step 6
