| name | kaizen-improvement-system |
| description | Use when auditing or improving the proposal engine or any bid, tender, EOI, methodology, technical/financial proposal, or consulting product it produces. |
| metadata | {"portable":true,"compatible_with":["claude-code","codex"]} |
Kaizen Improvement System
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
Use When
- Auditing a proposal engine, bid, tender response, EOI, or consulting deliverable.
- Converting evaluator feedback, compliance misses, delivery lessons, or new evidence into a tested improvement.
Do Not Use When
- The task is only single-skill safety review.
- Current procurement, legal, market, finance, or technical claims lack verified source or evidence routing.
Required Inputs
| Artefact | Source/provider | Required? | Purpose | If absent |
|---|
| ToR/RFP, evaluation criteria, audience, proposal artefact, evidence register, compliance matrix, assumptions, and current score | Client brief and proposal project | yes | Set audit scope and evaluator bar | Stop or mark unassessed |
Workflow
- Read the local adoption plan, proposal router, profile/sector rules, and portfolio standard.
- Inventory section routes, references, templates, examples, visual/document handoffs, and release gates.
- Score every applicable dimension and product output. Publish
min(raw score, 65) and record blockers.
- Audit compliance, evaluator journey, evidence, methodology, feasibility, staffing, risk, M&E, budget separation, document fidelity, ethics, and submission readiness.
- Create a P0/P1/P2 plan targeting 95/100. Every action names a file, owner, measure, acceptance proof, and rollback.
- Run one time-boxed evaluator simulation or compliance red-team. If the result fails, stop, recover the last safe version, and revise.
- Run source-ingestion, anti-slop, document/render, and release gates; standardise successful learning and record the next review.
Outputs
| Artefact | Consumer | Acceptance condition |
|---|
| Capped audit, evaluator/evidence gap register, 95/100 plan, experiment result, and standardisation record | Proposal lead, reviewer, and release owner | Every finding has evidence, action, owner, acceptance proof, and re-audit date |
Evidence Produced
| Evidence | Consumer | Acceptance condition |
|---|
| Compliance matrix, evaluator score, red-team findings, source register, render review, and revision diff | Reviewer and release owner | Another reviewer can reproduce the decision and confirm the correction |
Capability Contract
Read and search are required. Proposal audits are read-only by default; edits, submissions, or external communication require explicit authority and permission. Route current facts to Digital Research.
Degraded Mode
If the ToR, evaluation grid, evidence, source, render, or reviewer is unavailable, return a qualified result, mark the gap not assessed, and withhold submission readiness.
Decision Rules
| Condition | Action | Failure or risk avoided |
|---|
| A value claim lacks evaluator-relevant proof | Narrow the claim or add evidence before release | Unsupported promise |
| A technical or financial envelope is required separately | Preserve the separation and re-check the submission package | Disqualification |
| A red-team finding remains unresolved | Block release or obtain a documented decision | Hidden compliance risk |
Quality Standards
A persuasive narrative never substitutes for compliance or proof. Keep technical and financial envelopes separate when required. Expert advice must stay within verified competence and compliance boundaries.
Mandatory 65-to-95 gate
Treat the first review as an initial analysis: show the raw findings but publish only
min(raw_score, 65), with missing evidence and mandatory blockers visible. Begin the
95/100 improvement cycle only after that baseline is frozen. Every action needs a
root cause, exact artefact or validator, owner, experiment, evaluator-facing measure,
guardrail, stop/rollback rule, acceptance proof, and re-audit date.
Run it at engine level (routes, templates, examples, validators, and handoffs) and
at product level (bid, EOI, methodology, technical/financial proposal, or report).
The product requires its own evaluator and evidence result.
Anti-Patterns
- Storytelling without evaluator evidence. Fix: link each value claim to proof.
- Generic methodology pasted into a ToR. Fix: map activities, outputs, risks, measures, and context.
- Inflated capability claims. Fix: scope, qualify, and verify.
- Improvement plans with only language edits. Fix: add fixture, test, or reviewer evidence.
- Uncontrolled book or OCR ingestion. Fix: retain independent synthesis only.
Worked Example
If a draft scores well on narrative but fails two mandatory ToR requirements, keep the score capped, block release, repair the compliance matrix and evidence, then repeat the evaluator simulation.
References
- Local adoption plan
- Portfolio standard: resolve
digital-research-engine through the global engine-routing table and read its docs/continuous-improvement/portfolio-kaizen-standard-2026-08.md file; if it is unavailable, apply Degraded Mode and mark the portfolio comparison not assessed.
skills/meta/ai-slop-audit/skills/strategy-positioning/critical-analysis-business-logic/
