Kaizen Improvement System

Kaizen Improvement System

Use this skill to turn observed defects, incidents, feedback, source changes, or audit gaps into small, reversible, evidence-backed improvements. It keeps domain judgement with the owning engine and makes learning discoverable.

Use When

• Auditing or grading the engineering catalogue or a product made with it.
• Turning defects, incidents, user feedback, or new evidence into a tested improvement.
• Planning a major iteration, quarterly engine review, or post-release re-audit.

Do Not Use When

• A single-skill safety review is the only task; use skill-safety-audit.
• A current external claim is needed before source evaluation and verification.
• The proposed change is cosmetic and has no measurable effect on routing, quality, safety, or delivery.

Required Inputs

• Engine or product path, intended audience, output types, owner, and constraints.
• Current routes, references, tests, user or product evidence, and known failure modes.
• Baseline scoring method, improvement target, acceptance evidence, rollback condition, and re-audit date.

Prerequisites

• Read docs/continuous-improvement/kaizen-adoption-2026-08.md.
• For portfolio or current-standards claims, use the Digital Research engine's source-evaluation and source-verification routes.

Workflow

1. Observe. Inspect the real route, output, users, constraints, evidence, and failure mode.
2. Baseline. Inventory applicable dimensions and score them with named evidence. Keep raw scores, blockers, uncertainty, and NOT ASSESSED items visible. Publish the repository policy cap of min(raw_score, 65) for permanent audits.
3. Select. Choose the smallest high-leverage root cause. Prefer repeated defects, user harm, safety issues, missing proof, and routing failures over added prose.
4. Experiment. Name the exact skill, reference, fixture, validator, or gate; hypothesis; owner; measure; risk; rollback; stop condition; and re-audit date.
5. Check. Re-run relevant validators, tests, source checks, user or product checks, and independent review. Preserve negative evidence.
6. Standardise. Promote a successful result into the owning skill, reference, template, fixture, router, or release gate. Do not promote a one-off observation.
7. Teach and re-measure. Update discoverability and handoffs, re-score the changed dimensions, and leave the next improvement visible.

Core content

For a product, assess the applicable combination of requirements, architecture or document correctness, security and privacy, accessibility, reliability, performance, user value, deployment or handoff, rollback, and evidence quality. For an engine, assess doctrine, taxonomy and routing, skill depth, applied proof, standards currency, output readiness, hygiene, safety, and integrity. For client-facing web or dashboard work, also load references/purpose-fit-premium-ux-implementation.md and require an implementation slice that preserves the client's design thesis rather than copying a reference product.

Quality Standards

• Scores cite concrete evidence and a one-line deficiency statement.
• A target of 95/100 is an improvement target, not an achievement claim.
• Do not award 70+ without extraordinary, specific proof or claim production readiness without executable or rendered evidence.
• Structural, behavioural, render, system, and production evidence are labelled separately.
• Missing execution, source, approval, or artefact evidence is NOT ASSESSED.
• A safety, legal, financial, privacy, security, or release blocker remains a blocker regardless of score.
• Lessons are stored only when repeatable, generalisable, significant, actionable, and likely to prevent recurrence.

Anti-Patterns

• Adding a skill without a demonstrated routing or ownership gap. Fix: inventory and test the collision first.
• Awarding a high score because headings or checkboxes exist. Fix: require outcome-level evidence.
• Treating a green unit or structural test as product proof. Fix: add the smallest relevant behavioural, failure, render, or handoff check.
• Closing an action because prose changed. Fix: close only when named acceptance evidence exists and a fresh agent can find the result.
• Hiding an unavailable check inside an overall score. Fix: mark it NOT ASSESSED with an owner and date.
• Keeping every retrospective note forever. Fix: promote durable learning and remove redundant narrative.
• Treating a polished screenshot as a premium implementation. Fix: test real content, critical states, responsive reflow, keyboard/focus, reduced motion, performance, and recovery.
• Copying a recognisable competitor surface. Fix: implement the user principle and the client's visual thesis, then retain a rationale and originality review.

Outputs

Evidence Produced

Read next

• skill-engine-audit for the engine rubric and evidence matrix.
• skill-safety-audit for changed or imported skill safety review.
• advanced-testing-strategy for risk-scaled validation.
• world-class-engineering for delivery gates and operational handoff.

Mandatory Digital Research currentness gate

Every Kaizen cycle must begin with digital-research-engine source evaluation and source verification. Record scope, dates, freshness class, support status, uncertainty, and review date for current standards, APIs, frameworks, packages, security, platform, and lifecycle claims; quarantine unsupported claims as NOT_ASSESSED. Apply the currentness gate at C:/wamp64/www/digital-research-skills/docs/continuous-improvement/kaizen-currentness-gate.md.

References

• docs/continuous-improvement/kaizen-adoption-2026-08.md - local adoption plan.
• C:/wamp64/www/digital-research-skills/docs/continuous-improvement/portfolio-kaizen-standard-2026-08.md - cross-engine standard.
• skills/sdlc-meta/skill-engine-audit/ - audit dimensions, scoring, and report structure.
• skills/sdlc-meta/skill-safety-audit/ - safety and source-ingestion gate.
• skills/sdlc-meta/kaizen-improvement-system/references/purpose-fit-premium-ux-implementation.md - implementation patterns for friction reduction, dashboards, state feedback, and authored visual systems.

Inputs

Capability contract

Read and search are required. Execution is preferred for validators and tests; editing requires an authorised improvement scope. Without execution, report the exact checks as NOT ASSESSED. Network research is optional and must use source-disciplined routes.

Degraded mode

If a validator, source, user result, render, system environment, or independent review is unavailable, keep the gap visible and state its consequence. Return a conditional plan or verdict; never convert unavailable evidence into a pass.

Decision rules

The book-wave operating contract is book-driven system decision and agent orchestration. Current technology and security claims must pass Digital Research verification.

The 2026-09-02 cross-engine study is Book-driven Kaizen Wave 3; use it for currentness-gated contracts, testing, Git recovery, secure input handling, protocol semantics, and agent evaluation.