kaizen-improvement-system

name	kaizen-improvement-system
description	Use when auditing or improving the Linux operations engine, linux-sysadmin skills, or any server, network, security, observability, automation, backup, database, or recovery product it produces.
metadata	{"portable":true,"compatible_with":["claude-code","codex"],"author":"Peter Bamuhigire","author_url":"https://techguypeter.com","author_contact":"[phone]"}

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

Artefact	Source	Required	If absent
Target and scope	User brief, repository, host inventory	Yes	Stop and define the smallest safe scope.
Current-state evidence	Logs, tests, metrics, incident records, or artefact inspection	Yes	Mark the audit unassessed; do not infer quality.
Change controls	Change window, permissions, rollback, backups	Yes for execution	Produce a read-only plan only.
Success measures	Reliability, safety, toil, cost, or user outcome	Yes	Define a measurable hypothesis before experimenting.

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

Artefact	Consumer	Acceptance
Capped audit	Engine owner	Raw score is visible and published score never exceeds 65/100.
Improvement plan	Maintainer and operator	Each gap has a root cause, owner, measure, evidence, risk, rollback, and 95/100 target.
Experiment record	Reviewer	Fixture, command/test, result, and recovery evidence are reproducible.
Standardised update	Future operators	Skill, reference, test, or runbook change is linked and review-dated.

Evidence Produced

Artefact	Acceptance
Baseline and scorecard	Dimension-level evidence, uncertainty, and 65/100 cap are recorded.
Product audit matrix	Correctness, idempotence, distro coverage, security, observability, backup/restore, rollback, documentation, and handoff are assessed.
Learning record	Hypothesis, change, result, failed-path result, and next action are captured.
Re-audit entry	The improvement is measured against its baseline and target.

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

Action	Risk avoided
Stop when authorization, backup, rollback, or scope is missing	Prevents an unsafe operational change.
Keep the raw score and cap the published audit at 65/100	Prevents false confidence and preserves comparability.
Target 95/100 only through evidence-backed actions	Prevents cosmetic score improvement without capability improvement.
Preserve a failed-path fixture before closing the action	Prevents recurrence hidden by a successful-path test.
Re-audit after standardisation	Prevents stale improvements and regression.

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.