---
name: sustainment-audit
description: "Whether a kaizen event's commitments actually held after it closed — a checklist against the specific practices it was supposed to leave behind, honestly naming which are at risk of lapsing. Use when: An event closed a while ago and you want an honest check on whether its changes actually stuck. You want specific, verifiable practices to check — not a vague \"is it still working?\" gut check. You want lapsed practices named directly so they can be fixed, not quietly forgotten. Not for: The event just closed — give it real time to settle before auditing it; a same-week audit tells you nothing about sustainment. You don't have a real charter or objective to audit against — sharpen that first, or the checklist will be as vague as the input. You're looking to blame someone for a lapsed practice rather than fix it — this is a maintenance tool, not a performance review."
---
<!-- Auto-generated from content/templates.ts by scripts/generate-skills.ts -- do not edit this file directly. Edit the kata's guide content and regenerate. -->

# Sustainment audit

Whether a kaizen event's commitments actually held after it closed — a checklist against the specific practices it was supposed to leave behind, honestly naming which are at risk of lapsing.

Family: Kaizen events · Format: .xlsx · Domain: core

## What it is

Most kaizen events are checked once, at the report-out, and never again. A sustainment audit is the follow-up: weeks or months after an event closes, restate what it was supposed to change and get a checklist of specific, verifiable practices to check against reality. It's fine, and honest, if some have lapsed — the whole point is catching that before it's forgotten entirely, not confirming everything is still perfect.

## When to use it

Use it when:

- An event closed a while ago and you want an honest check on whether its changes actually stuck.
- You want specific, verifiable practices to check — not a vague "is it still working?" gut check.
- You want lapsed practices named directly so they can be fixed, not quietly forgotten.

Not when:

- The event just closed — give it real time to settle before auditing it; a same-week audit tells you nothing about sustainment.
- You don't have a real charter or objective to audit against — sharpen that first, or the checklist will be as vague as the input.
- You're looking to blame someone for a lapsed practice rather than fix it — this is a maintenance tool, not a performance review.

## How to fill it in

- **originalObjective** — What was the event's original objective?
- **checks** — Drafted from what was supposed to change — specific, checkable practices. Verify each one and check off what's actually still holding.
- **narrative** — Drafted from the sustainment checklist.

## What good looks like

The example below audits the kaizen event charter's own worked example — the onboarding ticket resolution event — sixty days after it closed. Four of six practices are still holding and two are honestly flagged at risk, rather than the checklist being quietly marked all-clear.

Full worked example, on-screen and as a downloadable .xlsx: https://www.katafacts.com/katas/sustainment-audit

## Common mistakes

- **Auditing too soon after the event, before practices have had time to either stick or lapse.** — A sustainment audit measures whether change survived contact with normal operations — that takes weeks, not days.
- **Marking a practice as holding because it mostly is, rather than actually verifying it.** — The audit only has value if it reflects reality — a generously-marked checklist can't catch a real lapse before it compounds.
- **Treating an at-risk finding as a failure to hide rather than a gap to close.** — Sustainment naturally decays without attention — naming the gap is what makes it fixable, not a verdict on the original event.

## What it connects to

Upstream:

- **Kaizen event charter** (`kaizen-charter`) — The charter's objective and commitments are exactly what this audit checks — audit against the real charter, not a vague memory of the event.

## Where AI helps

Judgement — stays with you:

- Deciding how much time to give an event before auditing it
- Deciding what to do about a practice that's flagged at risk

Analysis — AI helps:

- Drafting specific, verifiable checks from a description of what was supposed to change
- Drafting the narrative from the checklist actually built

Drudgery — automated:

- Tallying how many practices are still holding
- Identifying which practices are at risk
- Exporting to xlsx in the house format

---

Sustainment audit is licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Attribution: Katafacts (katafacts.com).

## Using this skill

Apply this method as part of whatever broader task, instructions, or deliverable you're already working on -- it's a method to use, not a standalone conversation to start. There is no generation tool for this catalogue yet, so draft the artifact's actual content yourself, following the fields above, the same way a person filling this out by hand would. The canonical guide page and a downloadable worked example (.xlsx) are at https://www.katafacts.com/katas/sustainment-audit.
