PDCA plus CIPDA: Two Control Spines for Different Types of Work

Source article at IJQRM https://doi.org/10.1108/IJQRM-01-2026-0029

PDCA (Plan-Do-Check-Act) is the classic quality management cycle developed by Sherwoood in the 1930s and extended and popularised by Deming in the 1950s. It assumes you can define what “done” looks like before you begin: plan your approach, execute it, check the results against your plan, and learn from the outcome. PDCA works brilliantly for bounded tasks where methods are established, inputs are clear, and success criteria are stable. Writing a technical specification, conducting a financial calculation, or implementing a known procedure—these all suit PDCA because the reference frame is shared and the method is repeatable. The control logic is simple: did we do what we said we would do, and did it produce the expected result?

CIPDA (Context-Intent-Plan-Deliver-Assure) extends this logic for work that requires interpretive judgment before execution can begin. It adds two critical stages at the front: establishing shared Context (what situation are we in, what constraints apply, what assumptions are we making?) and clarifying Intent (what are we really trying to achieve, what does “good” look like in this specific case?). Only then can planning begin. The final stage shifts from Check to Assure—because you’re not just verifying outputs against a predetermined specification, you’re validating that the reasoning was sound and the solution actually addresses the original intent. CIPDA is essential for governance assessments, policy interpretation, strategic analysis, or any task where “meeting the requirement” demands normative judgment rather than procedural compliance. The control logic asks: did we understand the problem correctly, and does our solution remain valid under scrutiny?

Structured Primers add a governed starting point to both CIPDA and PDCA. Neither cycle, by itself, determines what assumptions, constraints, definitions, evidence rules or professional expectations should shape the work before the cycle begins. A Primer makes those conditions explicit. It establishes the frame within which Context is understood in CIPDA, or the Plan is formed in PDCA, reducing the risk that an AI system quietly substitutes its own interpretation of the task.

This is especially important for AI-supported work because the same instruction can be interpreted differently across models, sessions or agents. A Primer therefore acts as a persistent interpretive reference: it defines what matters, what must not be assumed, what evidence is acceptable, where human judgement is required, and how uncertainty should be treated. CIPDA can then govern the reasoning and delivery of the task, while PDCA can govern subsequent human level checking and improvement. The Primer does not replace either cycle; it gives them a stable, visible foundation from which to operate.

ROMER adds the trace of what actually happened inside the governed cycle. Where the Primer establishes the starting frame, and CIPDA or PDCA structures the conduct of the work, ROMER (Reasoning, Observations, Method, Evidence, Results), captures the interpretive path through it: the reasoning applied, observations made, method used, evidence relied upon, and results reached. It therefore turns a process from something that was merely performed into something that can subsequently be examined, challenged and, where possible, reconstructed.

This matters particularly when AI is involved because a satisfactory answer is not sufficient evidence that a satisfactory process occurred. ROMER exposes the connection between instruction, evidence, reasoning and result, making departures from the Primer or the intended CIPDA/PDCA process visible. In that sense, the Primer governs the starting conditions, CIPDA or PDCA governs the activity, and ROMER provides the record needed to assure what was done. Together they provide a relatively simple architecture for moving from governed intent to defensible outcome.

For the Meta-Primer system, this distinction drives the entire routing architecture. When you submit a task, the AI triage doesn’t ask “is this hard?”—it asks “can we execute this without first negotiating what success means?” If yes, you follow the PDCA-based non-complex route and receive a structured method statement. If no, you enter the CIPDA-based complex route and work through a topical primer that builds shared understanding before proposing solutions. This isn’t just process design—it’s ensuring that the control framework matches the actual nature of the work, preventing the common failure mode where AI

Non-complex (Plan Do Check Act):

• Assumes stable reference frame
• Method is identifiable upfront
• Checks can be defined before execution
• Simple cycle: plan what you’ll do, do it, check it, learn

• Assumes interpretive ambiguity
• Must establish shared understanding first
• Context and Intent precede planning
• Assurance replaces Check (because you’re validating reasoning, not just outputs)

This isn’t just a labeling difference—it’s a fundamental distinction in governance logic.

PDCA assumes you know what “done” looks like before you start.
CIPDA assumes you must negotiate what “done” means as part of the work.

Why This Matters

When you document this for academic publication, the bifurcation isn’t arbitrary categorisation—it’s driven by presence or absence of normative interpretation:

“Assess whether our data governance program meets ‘appropriate security’” → interpretive, normative → CIP

The triage decision is actually asking: “Can we execute without first establishing shared meaning?”