System Integrity Has Three Parts: Design, Implementation, and Use
When a system fails, the first explanation is often too broad.
The process is broken.
The tool does not work.
The team failed to execute.
The software is bad.
The policy is ineffective.
Those statements may be directionally true, but they do not yet identify where the failure lives.
The 2010 seminar materials collected under A New Model of Integrity: The Missing Factor of Production offer a useful three-part distinction for objects and systems. A system can be whole and complete only when three things line up:
1. the design is capable of delivering the intended purpose;
2. the design is implemented completely and accurately;
3. the system is used for the purpose and in the way it was designed to be used.
This framework is valuable because the remedy for a design problem is different from the remedy for an implementation problem, and both are different from a use problem.
Without the distinction, organizations can spend months improving the wrong layer.
1. Design: can this system produce the intended result?
Start before execution.
A design has integrity when its parts, rules, capacities, and assumptions are capable of delivering the purpose for which the system exists.
Consider a customer-support process designed to respond within one hour.
If one person is expected to monitor five channels continuously, handle every case, attend meetings, and approve refunds, the process may fail even if that person performs exactly as instructed.
The design itself cannot reliably deliver the promised result.
The same applies to software.
If an architecture requires a single service to handle more load than it can support, perfect implementation will not rescue the design.
Or consider a policy.
A company may require every purchase to receive six approvals while also promising same-day purchasing. If those two rules cannot coexist under normal conditions, the system contains a design conflict.
Design questions include:
- Is the stated purpose clear?
- Is the system capable of producing that purpose under realistic conditions?
- Are its parts sufficient?
- Are there unnecessary parts that create friction?
- Do any requirements contradict one another?
- Are critical assumptions actually true?
- Does capacity match expected demand?
A design problem should be repaired at the design level.
Demanding more effort from users rarely solves it for long.
2. Implementation: was the design actually built?
A sound design can fail because it exists only on paper.
The workflow specifies four checks, but only two were implemented.
The software design includes access controls, but one service bypasses them.
The operating procedure says ownership transfers at a specific step, yet no role was assigned.
The policy requires a review, but the review never became part of the real process.
This is an implementation integrity problem.
The question is not whether the design would work.
The question is whether the real system corresponds to the design closely enough for that claim to matter.
This distinction is especially important when organizations point to documentation as evidence of control.
A diagram can be complete while the deployed system is incomplete.
A policy can be clear while practice ignores half of it.
A checklist can exist while the team never receives the information needed to complete it.
Implementation questions include:
- Were all required components actually created?
- Are they connected as intended?
- Are configurations accurate?
- Are permissions, roles, and dependencies complete?
- Does the deployed version match the approved design?
- Have temporary workarounds quietly become permanent?
- Is any part present in documentation but absent in reality?
A system should be evaluated by what is implemented, not by what the design intended.
3. Use: is the system being used as designed?
A capable design can be implemented correctly and still fail in use.
A security process exists, but people share accounts to save time.
A project board is accurate, but decisions are made in private messages and never recorded.
A reporting system contains the right fields, but teams enter placeholder values because the data is inconvenient to collect.
A machine is maintained properly but repeatedly operated outside its intended limits.
A calendar is current, but nobody treats the appointments as commitments.
These are use integrity problems.
The system itself may be sound.
Its actual relationship with the people using it is not.
Use questions include:
- Are people using the system for its intended purpose?
- Are they bypassing steps?
- Are important decisions happening outside it?
- Are inputs accurate and timely?
- Have incentives made non-compliance more attractive than proper use?
- Does the system fit real work closely enough that people can use it as intended?
- Are users trained for the decisions the system asks them to make?
A use problem cannot always be solved with more enforcement.
Sometimes persistent misuse is evidence that the design is too difficult, slow, or disconnected from real work.
That is why the three dimensions need to be examined together.
A familiar failure: blaming implementation for design
Many organizations have an execution reflex.
When results fall short, the first response is to ask people to execute better.
More accountability.
More follow-up.
More status meetings.
More discipline.
That response is appropriate when the design is sound and the implementation is complete.
It is wasteful when the system was never capable of producing the desired result.
Imagine a delivery process with a three-hour promise but a required upstream step that normally takes four hours.
The team can be coached.
Dashboards can be added.
Managers can escalate delays.
None of that changes the arithmetic.
The system is being asked to do something its design cannot support.
Calling that an execution problem hides the actual repair.
Another failure: redesigning what was never implemented
The opposite mistake also happens.
A company replaces a process because it performed poorly.
Later, it becomes clear that the original process was never implemented as specified.
The organization did not learn whether the design worked.
It learned that an incomplete version failed.
This matters because redesign has a cost.
New systems require training, migration, testing, communication, and adjustment.
Before replacing a design, it helps to ask whether the organization has evidence from the actual design or only from a partial implementation.
Use can reveal design weakness
The three dimensions are distinct but not isolated.
Repeated misuse can be a signal.
If almost everyone bypasses the same step, it may be tempting to conclude that the users lack discipline.
Sometimes that is true.
Sometimes the bypass is evidence that the step is poorly designed.
Perhaps it duplicates information already available.
Perhaps it adds delay without improving a decision.
Perhaps the required input cannot be known at that stage.
Perhaps the tool is inaccessible in the environment where the work occurs.
A use failure can therefore send the investigation back to design.
The framework is diagnostic, not a blame allocation system.
A three-pass review for any failing process
When something is not working, review it in this order.
Pass 1: Design
State the purpose.
Then ask whether the system, as designed, can realistically deliver it.
Do not use current execution failures as evidence yet. Examine the model itself.
Pass 2: Implementation
Compare the real system with the design.
Look for missing components, wrong configuration, incomplete handoffs, and undocumented substitutions.
Pass 3: Use
Observe what people actually do.
Do not rely only on what the procedure says they do.
Look for bypasses, workarounds, shadow systems, stale data, and incentives that pull behavior away from the intended use.
The result may show one primary failure or a chain across all three.
Integrity is not perfection
A whole system can still encounter breakdowns.
Unexpected demand can exceed capacity.
A component can fail.
People can make mistakes.
A sound system is not one that never experiences trouble.
Its integrity lies in whether the elements required for its purpose are present, correctly implemented, and used in a way that keeps the system workable.
That is a more useful standard than asking whether a process feels polished or whether everyone followed instructions.
Diagnose before adding effort
When a system underperforms, effort is often the easiest resource to demand.
People can work later.
Managers can watch more closely.
Teams can add meetings.
But effort applied to the wrong layer can make an organization busier without making the system more workable.
The three-part integrity test slows down that reflex.
Is the design capable?
Was it implemented?
Is it being used as designed?
Those questions turn a vague complaint that the system is broken into a repairable diagnosis.
And once the failing layer is visible, the organization has a better chance of fixing the system instead of repeatedly asking people to compensate for it.