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.
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 procurement, market, legal, policy,
technology, finance, and lifecycle claims; quarantine unsupported claims as
NOT_ASSESSED. Apply the portfolio Kaizen currentness gate.
References
- Local adoption plan
- Portfolio standard: resolve
digital-research-enginethrough 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/- Book-driven value story and evaluator journey - evaluator evidence, human story, delivery system, and currentness.
- Book-driven Kaizen Wave 3 - evaluator evidence, red-team testing, evidence traceability, and controlled AI-assisted delivery.