A precise definition
Attributable failure is a supported finding that a person, role, team, or organization with a defined responsibility made, or failed to make, a material technical or managerial decision, and that decision contributed meaningfully to an adverse outcome.
The definition is deliberately demanding. Project records often show that someone attended a meeting, appeared on a drawing, received a message, held a senior title, or worked for a company involved in the project. Those facts establish proximity. They do not, by themselves, establish responsibility or causation.
The record must establish more than “this person was there.” It must explain what they owned, what they knew, what they could control, and how their decision changed the result.
This distinction matters in engineering, construction, technology, operations, public infrastructure, and any other environment where decisions move across consultants, contractors, owners, vendors, reviewers, and operators.
The five elements of attribution
A defensible review tests five elements separately. If one remains unsupported, the conclusion must preserve that limitation rather than filling it with assumption.
- Responsibility. What duty, scope, authority, or control actually belonged to the role at the relevant time?
- Decision. What material act, omission, approval, instruction, design choice, escalation, or management judgment is under review?
- Contemporaneous knowledge. What information was reasonably available when the decision had to be made, rather than what became obvious afterward?
- Standard or reasoning. What requirement, accepted practice, contractual obligation, design basis, or documented rationale should the decision be measured against?
- Causal contribution. How did the decision contribute to the outcome, and which other credible causes must also be considered?
Attribution can be shared. A design assumption may combine with an owner instruction, a coordination gap, a field condition, and a later unauthorized change. A sound analysis does not force a single villain where the evidence describes a system of interacting decisions.
| Record shows | What it may establish | What it does not establish alone |
|---|---|---|
| A signed drawing | Authorship, issue state, represented design | Every later field condition or construction act |
| An email recipient | Transmission to an address at a stated time | Comprehension, acceptance, authority, or action |
| A meeting attendance list | Recorded presence | Decision ownership or agreement with all discussion |
| A senior title | Organizational position | Personal control over each project decision |
| A change order | Defined commercial or scope change | The complete technical cause unless linked records support it |
Technical and managerial failure are different
A technical failure concerns the substance of the work: a calculation, configuration, dimension, design assumption, testing method, installation requirement, safety control, or technical interpretation. The review asks whether the technical judgment was reasonable and whether the issued work accurately expressed it.
A managerial failure concerns how the work was framed, coordinated, approved, escalated, resourced, communicated, revised, or handed over. The underlying technical answer may be correct while the project still fails because a constraint was not communicated, a decision had no owner, a warning was not escalated, or a superseded revision remained in circulation.
Technical examples
- An assumption conflicts with known site information and the conflict was not resolved.
- A calculation uses the wrong input, unit, boundary condition, or governing requirement.
- A field observation reveals a material deviation but no technical disposition is recorded.
- A safety or recovery control exists in theory but was never tested under realistic conditions.
Managerial examples
- A critical interface between disciplines has no named decision owner.
- A warning is raised informally but never enters the controlled issue process.
- A revision changes the design basis without updating dependent documents.
- A handover transfers deliverables but not open assumptions, unresolved questions, or acceptance criteria.
Many serious outcomes are mixed. The technical defect matters, but the managerial system determines whether it is detected, communicated, corrected, and prevented from recurring.
Control hindsight distortion
Once the outcome is known, the path toward it can look linear and inevitable. That is hindsight distortion. It causes reviewers to overvalue records that fit the outcome, ignore uncertainty that existed earlier, and judge a decision using information that was not available when it was made.
A better review reconstructs the information state at each decision point. It identifies which records existed, who could access them, what was unresolved, what time pressure applied, and which options were realistically available. Later knowledge should be placed in a separate column rather than silently imported into the earlier moment.
A documented judgment can still be wrong. Documentation is not immunity. But it permits a fair evaluation of reasoning, assumptions, and authority. An undocumented judgment forces later reviewers to reconstruct motive from fragments, which increases uncertainty for everyone.
A six-step review method
- Define the outcome. Describe what occurred in neutral, measurable terms. Avoid assigning cause in the opening statement.
- Build the chronology. Put source records in time order, preserving issue dates, revisions, authors, recipients, and authentication status.
- Map responsibility. Link every material decision to the scope, role, delegated authority, reliance, and control that existed at that time.
- Reconstruct knowledge. Identify what each decision-maker could reasonably know, what remained uncertain, and which warnings or constraints were visible.
- Test causation. Compare the leading explanation with credible alternatives and ask what evidence would distinguish them.
- State confidence and limits. Separate established fact, supported inference, missing evidence, and unresolved expert or legal questions.
Questions a defensible record should answer
- What requirement, risk, or constraint made the decision necessary?
- Who owned the decision, and who only advised, reviewed, supplied, constructed, or observed?
- Which assumptions were material, and where were they recorded?
- What alternatives were considered and rejected?
- Which record represents the formally issued position?
- What changed afterward, who approved it, and which dependent records changed with it?
- What warnings, exceptions, or limitations were communicated?
- Which evidence supports the causal link, and which evidence weakens it?
- What remains outside the available record?
When those questions can be answered without relying on memory or reputation, the project is easier to operate, hand over, insure, investigate, and defend.