Kaizen Improvement System

Kaizen Improvement System

Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com.

Use When

• Auditing this engine or an operational product, runbook, script, service change, or recovery procedure.
• Turning incidents, drift, toil, failed recovery, user feedback, or new evidence into a safe improvement.

Do Not Use When

• Only a single skill safety audit is needed; use the narrowest applicable audit skill.
• A current distro, security, compliance, or vendor claim lacks source verification; route the claim to digital-research-engine first.

Required Inputs

Workflow

1. Read the local adoption plan, AGENTS.md, linux-sysadmin, and the portfolio Kaizen standard; inventory the engine or product. Stop if scope, authorization, or rollback is unclear.
2. Establish the baseline, score applicable dimensions, and publish min(raw score, 65) with safety and rollback blockers separate from the score.
3. Select one reversible improvement, define a 95/100 target, owner, hypothesis, command/test/fixture, acceptance evidence, and rollback; abort if risk exceeds the approved boundary.
4. Run the experiment on a safe fixture, validate Debian-family and RHEL-family paths where applicable, and recover or roll back on failure.
5. Check evidence, standardise only the verified change, teach the updated procedure, and schedule the next re-audit.

Outputs

Evidence Produced

Capability Contract

• May read/search engine files, product artefacts, tests, logs, references, and supplied evidence; may propose or author scoped documentation and skill updates when explicitly authorised.
• Must preserve least privilege, backups, explicit confirmation, rollback, and two-family support. Execution requires explicit authorization and a safe fixture; audit mode is read-only.
• May route current or uncertain claims to digital-research-engine and must record source status, date, and limitations.

Degraded Mode

If evidence is incomplete, the target is unassessed, or distro execution is unavailable, stop execution and produce the narrowest qualified read-only audit. Label unassessed dimensions, do not invent scores, separate evidence gaps from defects, and defer standardisation until verification is available.

Decision Rules

Quality Standards

Preserve two-family support, idempotence, least privilege, explicit confirmation, backups, rollback, verification, evidence traceability, and review dates. Never turn a historical book or vendor example into a current command without verification.

Mandatory 65-to-95 gate

The first pass is an initial analysis: calculate raw findings, publish only min(raw_score, 65), and keep missing fixtures, authorisation, backup, rollback, and distro evidence outside the score as explicit blockers. Only after that baseline is recorded may the operator target 95/100 with one safe change, a root cause, owner, command or fixture, guardrail, stop/rollback condition, recovery evidence, standardisation decision, and re-audit date. Run the gate at engine level (routers, runbooks, scripts, fixtures, validators, and handoffs) and product level (server change, script, service, backup, or recovery procedure). Product safety evidence is never inherited from an engine audit.

Anti-Patterns

• Measuring only successful execution. Fix: test failed paths and rollback.
• Removing safety prompts to save time. Fix: reduce toil around them, not the guardrail.
• Treating one distro as universal. Fix: validate both families or label the gap.
• Optimising a local step while increasing incident risk. Fix: inspect the full value stream.
• Closing an incident action without a regression test. Fix: add a fixture or script test.
• Treating missing evidence as a passing score. Fix: mark the dimension unassessed.

Worked Example

For a backup script that passes on Debian but has no RHEL fixture, baseline it as partially assessed, cap the audit at 65/100, and record the missing distro evidence as a gap. Add a safe RHEL-family fixture, test restore and failure recovery, update the script/reference, and re-audit toward 95/100 only after the evidence passes.

Mandatory Digital Research currentness gate

Every Kaizen cycle must begin with digital-research-skills source evaluation and source verification. Record scope, dates, freshness class, support status, uncertainty, and review date for current distro, package, protocol, security, vendor, command, and lifecycle claims; quarantine unsupported claims as NOT_ASSESSED. Apply the portfolio Kaizen currentness gate.

References

• Local adoption plan
• Safe reversible operations standard
• Value-stream, 5S, and QC Story
• Two-family validation and recovery
• Incident learning standard
• Linux product audit checklist
• Portfolio Kaizen standard: resolve digital-research-skills through the global engine-routing table, then read docs/continuous-improvement/portfolio-kaizen-standard-2026-08.md.
• Linux Kaizen operations loop
• meta/skill-safety-audit/
• 15-compliance-and-auditing/
• Current DNS operations and source gate - durable DNS operations, safe change, and current-version verification.
• Book-driven Kaizen Wave 3 - safe shell contracts, UNIX mental models, idempotence, observability, recovery, and current-command gates.