User:Pooyan/Civil Engineering Project Risk Taxonomy

Review draft — version 0.10, August 10, 2026. Keep in Draft/User space; not yet approved for publication.

A civil engineering project risk taxonomy is a controlled vocabulary for identifying, organizing, comparing, and aggregating uncertainties that may affect the objectives of a civil-infrastructure project or program. The taxonomy presented here is designed for complex heavy-civil and transit work. It proposes fourteen control domains grouped into four clusters and supplements them with separate tags for uncertainty character, causal source, life-cycle stage, physical and contractual location, affected objective, and ownership.

The purpose is practical: a risk should be traceable from its source through the location or work affected, the party able to control it, the evidence that a response has been implemented, and the residual exposure retained by the project. The taxonomy is therefore more than a list of things that may go wrong, but less than a quantitative risk model.

This page complements Uncertainty and Risk in Civil Engineering Practice, which examines scientific, legal, economic, policy, and engineering taxonomies of uncertainty. That article asks how uncertainty arises and how knowledge can fail. This page asks where project risk is managed in civil-infrastructure practice.

Purpose and scope

A useful taxonomy should be sufficiently comprehensive to support risk identification, sufficiently stable to permit comparison over time, and sufficiently clear to permit aggregation across disciplines and contracts. It should not force every dimension of a risk into one hierarchy.

This taxonomy is intended to:

• provide a common language across owners, designers, construction managers, contractors, operators, oversight bodies, and funding agencies;
• reduce omissions during risk identification and stage-gate reviews;
• connect each risk with the professional process, control, and deliverable used to manage it;
• preserve traceability from program to reach, package, work breakdown structure (WBS), Standard Cost Category (SCC), estimate item, schedule activity, and contract provision;
• distinguish physical exposure from contractual allocation and financial bearing;
• support aggregation without creating duplicate “cost risk” and “schedule risk” records for the same underlying uncertainty; and
• provide structured inputs to qualitative assessment and quantitative risk analysis without predetermining either result.

The C01-C14 structure is a new 2026 working taxonomy informed by project experience and crosswalked to Federal Transit Administration (FTA) practice. Its empirical reliability and classification consistency have not yet been validated. It is not an official FTA category system, a risk tier, an SCC structure, or a contingency formula.

The codes are direction-neutral: the same domains may be used for threats and opportunities. Direction is recorded separately so that an opportunity is not forced into a threat-only vocabulary.

Development history and provenance

The 2017 archived article Uncertainty and Risk in Civil Engineering Practice compared scientific, legal, economic, policy/regulatory, and engineering approaches to uncertainty. It did not contain the C01-C14 structure. The present page is a 2026 applied extension developed for civil-infrastructure projects and should not be represented as recovered historical text.

Version	Source and status	Material editorial changes
Working source (2026)	Four clusters and C01-C14 labels presented in project risk-model working materials and an author review transcript. Not a published standard.	The source used “safe service and governance” for C12-C14 and placed support-of-excavation wording with utilities/relocations.
Draft 0.9 (2026)	First standalone article draft.	Renamed the fourth cluster “Assurance and governance”; placed ground-driven support-of-excavation uncertainty in C02 and method/temporary-works uncertainty in C08; separated taxonomy from the computational model.
Draft 0.10 (2026)	Review revision for subject-matter validation.	Added category-boundary rules, separated uncertainty character from causal source, corrected the FTA phase/profile distinction, qualified controls and evidence, and added provenance and publication safeguards.

Taxonomy, register, RBS, WBS, and impact classification

Construct	Function	Important boundary
Risk taxonomy	A reusable and version-controlled vocabulary of risk domains, definitions, inclusions, exclusions, aliases, and examples.	It does not contain the project's actual risk events and does not assign contingency.
Risk breakdown structure (RBS)	A hierarchical representation of sources or domains of risk. A taxonomy may be rendered as an RBS.	It is not the scope or work breakdown structure.
Risk register	The live set of identified project risks, including cause, uncertain event, effects, assessment, response, owner, evidence, and status.	A register uses the taxonomy; it is not the taxonomy.
Work breakdown structure (WBS), asset breakdown, SCC, and schedule	Descriptions of what will be designed, procured, built, tested, operated, paid for, or scheduled.	They locate exposure but do not by themselves explain why uncertainty arises.
Impact classification	The objectives affected, such as cost, time, safety, quality, environment, service, benefits, or community.	Consequences are tags, not primary source categories. One risk can affect several objectives.

Risk, uncertainty, and deviation from good practice

ISO 31000 frames risk around the effect of uncertainty on objectives and emphasizes integration of risk management into governance, strategy, planning, reporting, policy, values, and culture. This broad framing accommodates threats and opportunities and avoids reducing risk to a synonym for failure.

A deviation from context-appropriate good practice can be an important source of risk because it may weaken detection, analysis, decision-making, implementation, or assurance. It is not, however, a complete definition of risk. Ground variability, floods, market shocks, third-party decisions, and other sources of exposure may remain even when the project follows good practice.

The defensible proposition is therefore:

Good practice does not eliminate risk. When it is appropriate, current, implemented, and effective, it may reduce avoidable epistemic uncertainty, reduce likelihood or consequences, or improve detection and preparedness. It supports making residual risk more visible, allocable, and governable.

For that reason, each category below is mapped to illustrative controls and evidence. An artifact supports a claim of implementation only when it is current, actually used, independently checked where appropriate, and shown to satisfy stated acceptance criteria. A plan or stated intention alone does not demonstrate that risk has been reduced.

A faceted model

Every risk should be coded across several independent dimensions. The fourteen categories answer only the control-domain question below.

Facet	Question answered	Typical values
Uncertainty character	Is the uncertainty primarily reducible through knowledge, inherent variability, or both?	Epistemic; aleatory; mixed
Causal-source tag	What kind of mechanism originates the uncertainty?	Physical/natural; technical; organizational/behavioral; institutional/legal; economic/market; mixed
Control domain	Which professional process has primary responsibility for managing the source?	C01-C14
Local stage/maturity tag	At what actual maturity is the affected unit or package?	Project development; engineering; procurement; award; construction; testing; closeout
Physical and commercial location	Where does the exposure reside?	Program; reach; site; asset; package; WBS; SCC; estimate item; schedule activity; contract clause
Impact	Which objectives may be affected?	Cost; time; safety; quality; environment; community; service; performance; benefits; reputation
Control and allocation	Who originates, controls, bears, monitors, and accepts the residual exposure?	Owner; designer; contractor; supplier; operator; third party; shared

This faceted structure preserves the insight of the earlier uncertainty taxonomies while producing a vocabulary suited to project controls. A single flat list cannot reliably represent cause, stage, location, consequence, and ownership at the same time.

Four clusters and fourteen control domains

The category codes are intended to remain stable through the life cycle after validation and adoption. Their relative importance changes with actual maturity, delivery strategy, context, and demonstrated controls.

K01 — Definition and site

Code	Domain	Includes and typical risk sources	Illustrative controls and evidence (tailor to context)
C01	Scope, requirements, and configuration	Business need; operating concept; alternatives; functional and performance requirements; physical limits; exclusions; scope growth; inconsistent baselines; unapproved changes; benefits and acceptance criteria.	Project-definition book; requirements register and traceability matrix; approved scope narrative and boundary maps; configuration/change-control procedure and authority; WBS/SCC/schedule scope bridge; assumptions, exclusions, and decision log.
C02	Geotechnical and subsurface	Ground and groundwater model; geological hazards; contamination; obstructions; mixed face; settlement; tunneling and excavation behavior; support of excavation; ground treatment; production and downtime; differing site conditions.	Hazard-led investigation program; geotechnical data and factual reports; conceptual and updated ground model; Geotechnical Design Report and Geotechnical Baseline Report where appropriate; independent review; baselines by reach/package; instrumentation, monitoring, action levels, and response plans; explicit estimate/schedule links.
C03	Utilities, SUE, and relocations	Incomplete records; unknown or mislocated utilities; ownership; utility condition and criticality; conflicts; betterments; outages; approvals; relocation design; protection; cost sharing; enabling work.	Utility-owner matrix; Subsurface Utility Engineering quality plan and verified mapping; conflict and criticality matrix; utility agreements; relocation/protection designs; outage and handback plans; advance-work schedule; cost, package, and schedule responsibility map.
C04	Right-of-way, property, and access	Permanent and temporary acquisition; easements; relocation and resettlement; condemnation; railroad possession; work zones; shafts and portals; staging, laydown, haul routes, and community/business access.	Real estate acquisition and management plan; parcel and ownership map; appraisal/acquisition/relocation schedule; access and possession agreements; staging and logistics plan; lawful-right dates aligned to package need dates; engagement and grievance evidence where people or businesses are affected.
C05	Environmental, permits, and commitments	Environmental review; permits; environmental justice and distributional effects; cultural resources; contaminated media; noise and vibration; water; air; biodiversity; waste; mitigation commitments; climate and natural-hazard requirements.	Environmental and social assessment; permit and approval matrix; environmental-commitment register; mitigation hierarchy and monitoring plan; climate-vulnerability/resilience assessment where material; condition-to-drawing/specification mapping; responsible owner and acceptance evidence.

K02 — Design and interfaces

Code	Domain	Includes and typical risk sources	Illustrative controls and evidence (tailor to context)
C06	Third-party, railroad, and stakeholder interfaces	Partner agencies; railroads; municipalities; utilities; authorities having jurisdiction; operator and emergency-service requirements; adjacent projects; community commitments; force-account work; approvals and agreements.	Stakeholder and interface management plans; interface register; Interface Control Documents; responsibility and approval matrix; cross-package boundary drawings; signed agreements; integrated interface schedule; decision/escalation path; bilateral acceptance record.
C07	Design completeness, coordination, and quality assurance	Design criteria; surveys and data; discipline coordination; quantities; specifications; errors and omissions; design maturity; constructability inputs; value engineering; model fitness; novel technology or methods.	Basis of design and controlled criteria; design management and QA/QC plans; maturity and quantity-confidence assessment; interdisciplinary and independent reviews; calculation checks; comment and decision logs; BIM/common-data-environment controls where used; reconciled basis of estimate.
C08	Constructability, temporary works, and production	Construction method; sequencing and staging; workfront availability; temporary support; groundwater control; maintenance of traffic/operations; spoil and material movements; site logistics; contractor methods; productivity and downtime.	Constructability and value-engineering reviews; construction-method and staging studies; site-utilization plans; temporary- and enabling-works register; production and logistics ranges; early market/contractor input when permitted; owner performance criteria; implemented-action log.

K03 — Commercial and delivery

Code	Domain	Includes and typical risk sources	Illustrative controls and evidence (tailor to context)
C09	Market, procurement, escalation, supply chain, and workforce	Inflation and price volatility; bidder appetite; package scale; labor and specialist capacity; supplier concentration; long-lead materials/equipment; logistics and trade restrictions; bonding, insurance, domestic-content, and competition constraints.	Market sounding; procurement and packaging strategy; year-of-expenditure escalation basis; bidder/supplier and workforce capacity assessment; long-lead and critical-supply register; prequalification where appropriate; independent price checks; price-shock triggers and fallback actions.
C10	Delivery, contract, claims, and risk allocation	Delivery-method fit; packaging; design responsibility; ambiguous scope; incentives; measurement/payment; insurance; bonds; differing site conditions; changes; notices; records; disputes; counterparty default; transferred, retained, shared, or uninsurable risk.	Delivery-options and sponsor-capability analysis; package map; responsibility and risk-allocation matrices; commercial principles; equitable geotechnical and quantity mechanisms; change/notice/record procedures; claims-avoidance review; dispute ladder; accepted contract terms and retained-risk provision.
C11	Schedule model, access integration, logistics, and controls	Missing or defective schedule logic; calendars; resources; production assumptions; forecasting and progress data; integration of property, utility, permit, interface, access, operating-window, logistics, cash-flow, and handoff dependencies; critical and near-critical paths; float consumption.	Integrated master schedule and basis; traceable calendars and production assumptions; package and external-interface logic; risk-to-activity links; quantitative schedule risk analysis when appropriate; integrated access/logistics plan; milestone ownership; forecast validation; mitigation and schedule-contingency decisions. Use the originating physical, commercial, or third-party category when the schedule is only a consequence.

K04 — Assurance and governance

Code	Domain	Includes and typical risk sources	Illustrative controls and evidence (tailor to context)
C12	Safety, physical security, and quality	Worker and public safety; fire/life safety; malicious physical acts; emergency preparedness; code and authority requirements; quality failure; inspection and test capability; nonconformance; safety/security certification.	Hazard analysis and controlled hazard log; safety and security management/certification plans; threat and vulnerability assessment; QA/QC plans; independent assurance; inspection and test plans; nonconformance/corrective-action records; verified mitigation and formal acceptance.
C13	Systems integration, digital/cyber, testing, and commissioning	Civil-systems interfaces; requirements and configuration; software and legacy systems; BIM/data interoperability; IT and operational technology; cyber and vendor exposure; reliability, availability, maintainability, and safety; integration testing; training; operational readiness and handover.	Systems engineering management plan; architecture and requirements baseline; Interface Control Documents; verification/validation matrix; RAM and cybersecurity/OT plans; data governance; integrated test and commissioning plan; safety certification; training, O&M, asset-information, and handover acceptance.
C14	Governance, management, and funding	Sponsor authority and capacity; decision rights; organizational interfaces; leadership continuity; staffing and competence; ethics and integrity; risk culture; estimate/schedule governance; funding and cash timing; contingency authority; independent oversight; information and AI governance.	Project Management Plan and subplans; Risk and Contingency Management Plan; governance/RACI and delegated authorities; management-capacity and staffing plan; financial plan; risk/change/contingency committees and thresholds; independent review; controlled decision, source, model, and configuration records.

Primary-category decision rules

Select the category that best represents the dominant source and the professional process with practical control. Do not choose a category merely because it contains a likely consequence. Use a secondary category only when a distinct coupled cause materially affects the response or ownership.

Boundary	Use the first category when…	Use the second category when…
C02 / C08 / C10	C02: the dominant uncertainty is ground, groundwater, contamination, obstruction, or subsurface behavior. C08: it is the selected construction method, temporary works, production, or workfront sequencing.	C10: the dominant uncertainty is the contractual baseline, allocation, payment mechanism, notice, change, or claims treatment. A ground condition does not become C10 solely because it may produce a claim.
C03 / C06	C03: the dominant uncertainty is utility identity, position, condition, conflict, outage, relocation, or protection.	C06: the dominant uncertainty is a utility owner's agreement, approval, decision, force-account performance, or organizational interface.
C04 / C11	C04: the dominant uncertainty is the legal or physical right to property, possession, easement, staging area, or access.	C11: the right exists, but schedule logic, operating windows, sequencing, logistics integration, progress data, or forecasting is uncertain.
C05 / C06	C05: the dominant uncertainty is a substantive environmental condition, permit requirement, mitigation commitment, or compliance condition.	C06: the requirement is understood, but a third party's review, approval, agreement, or coordination is the uncertain mechanism.
C07 / C13	C07: the dominant uncertainty concerns discipline design criteria, calculations, coordination, quantities, specifications, or design QA.	C13: it concerns system architecture, cross-system requirements, software/data interfaces, cybersecurity/OT, verification, integrated testing, commissioning, or operational handover.
C09 / C10	C09: the dominant source is the external market, competition, escalation, workforce, supplier capacity, long-lead supply, insurance, or bonding market.	C10: it is the owner's delivery choice, procurement/contract structure, responsibility, risk allocation, commercial terms, change, or claims process.
C12 / C13	C12: the dominant uncertainty is a safety, physical-security, quality, inspection, certification, or assurance outcome.	C13: it is the integration, configuration, verification, test, or commissioning process. A safety consequence remains an impact tag unless safety assurance is itself the uncertain mechanism.
C11 / impact tags	C11: the schedule model, control data, forecasting, or integration of access/logistics dependencies is itself the source.	Use time as an impact tag when delay is the consequence of a source classified elsewhere, such as an unknown utility (C03) or late permit (C05).

Cross-cutting 2026 lenses

Several important exposures cross multiple control domains. Creating a new primary category for each would encourage duplication, so they should be retained as mandatory secondary lenses or flags.

• Climate, natural hazards, resilience, and cascading dependencies. Apply where present or future climate conditions, acute hazards, chronic changes, recovery, service continuity, or dependence on power, communications, water, transportation, or other infrastructure materially affects the risk. Climate-risk assessment should address both vulnerability and present/future conditions.
• Digital engineering, cyber/OT, data, and AI. Apply where a common data environment, BIM, digital twin, automation, cloud/vendor dependency, AI-assisted decision, software, SCADA, IoT, or operational technology is a material source or control. OT has distinct safety, reliability, and performance requirements and should not be treated as ordinary office IT.
• Social acceptance, equity, and affected communities. Apply where distributional effects, land/resettlement, cultural heritage, vulnerable groups, transparency, consultation, disclosure, or grievance resolution are material. These are governable project conditions rather than public-relations afterthoughts.
• Supply-chain and workforce concentration. Apply where lower-tier suppliers, specialist labor, critical materials/equipment, geopolitical/trade constraints, industrial action, or logistics concentration create correlated exposure.
• Emerging, systemic, interdependent, and cascading risk. Apply when the mechanism is novel, weakly understood, capable of affecting several packages or objectives, or capable of propagating through connected systems. The flag triggers wider scenario and dependency review; it is not an “other” category.

Risk statement and minimum record

Each risk should be written as a causal proposition:

Because of [source/cause], there is uncertainty that [event or condition], which may affect [objective(s)] by [consequence].

At minimum, a governed record should contain:

1. unique risk ID and common snapshot date;
2. cause, uncertain event/condition, and consequences;
3. one primary C01-C14 category and no more than two justified secondary categories;
4. uncertainty character: epistemic, aleatory, or mixed, plus one or more independent causal-source tags;
5. threat, opportunity, or mixed direction;
6. program, reach/site, asset, package, WBS, SCC, estimate, schedule, and contract links as applicable;
7. actual maturity profile of the affected unit, not merely the program's administrative milestone;
8. affected objectives and time proximity;
9. source owner, response/action owner, party with practical control, contractual bearer, and residual owner;
10. inherent assessment, current controls, evidence reference, and residual assessment;
11. treatment action, cost, due date, acceptance criteria, reviewer, and decision authority;
12. dependencies, common causes, correlations, and linked risk-chain IDs;
13. retirement test and specific conditions requiring reopening; and
14. mapping to baseline uncertainty, estimate adjustment, schedule allowance, or discrete risk event to prevent double counting.

Worked example

Because available records and field verification do not establish the horizontal and vertical position of a critical utility, there is uncertainty that the station excavation will encounter an unplanned conflict, which may require redesign, relocation, and delayed access to the workfront.

• Primary category: C03 — Utilities, SUE, and relocations.
• Secondary category: C06 only if utility-owner decisions or agreement interfaces materially drive the uncertainty.
• Uncertainty character: principally epistemic. Causal-source tags: technical, plus organizational/behavioral if a third party controls access, design, or approval.
• Impacts: cost, time, service, and possibly safety; these are tags rather than separate risks.
• Physical links: station, excavation package, utility WBS/SCC items, affected schedule activities, and relevant contract provisions.
• Controls/evidence: verified SUE, test pits, conflict matrix, accepted relocation/protection design, utility agreement, outage window, and integrated schedule.
• Retirement: only after the utility is verified and the conflict is physically avoided, protected, or relocated and accepted. Substantial progress alone is not closure.

FTA terminology and local stage/maturity tags

FTA Oversight Procedure 40 uses four risk-register types—Requirements, Design, Market, and Construction—in Appendices E and O. Its cost model in Appendix J separately uses four partial Beta Range Factors (BRFs), plus a fixed Post-Construction factor. These are related constructs, but they are not five equivalent risk-register types.

OP40 also uses risk profile for a nonduplicated cost/phase partition in its quantitative process. The term should therefore not be used for the local maturity labels below. The C01-C14 domains may be crosswalked to the four FTA risk-register types when an FTA review requires it, but the two structures answer different questions.

Projects may define local stage/maturity tags when each tag has objective entry/exit evidence. The following list is illustrative and must be tailored rather than treated as a universal FTA sequence:

1. concept and option development;
2. FTA Project Development, where applicable—use the current statutory and FTA entry/exit criteria, not a local design-percentage proxy;
3. Entry into Engineering, where applicable—an administrative program milestone with formal prerequisites, not a synonym for a design percentage or record of decision;
4. grant agreement or other funding commitment—a funding/commercial gate, not a design-maturity proxy;
5. controlled design-maturity review, such as a locally defined 60-percent package review;
6. solicitation and procurement, ending at contract award;
7. award and notice to proceed—record separately when they occur on different dates;
8. early and mid-construction, using package-specific physical progress and completed hold points rather than program-wide percentages alone;
9. completion of dominant high-exposure subsurface or structural work, if the project defines a local “deep-work complete” hold point with scope, evidence, and reopening conditions;
10. systems integration, testing, safety certification, and operational readiness;
11. revenue service or beneficial use; and
12. contractual closeout and final account, recorded separately from operational opening.

Different packages and reaches may carry different tags on one program snapshot. Each affected unit should be assigned the tag supported by current evidence. A local tag should never be presented as an FTA term unless the governing FTA document uses it.

No risk is retired simply because a project passed a named stage. FTA guidance similarly cautions that risks should be retired only when the relevant condition is actually resolved and may need to be reopened when circumstances change.

Relationship to controls, evidence, and residual risk

For each material category at a stage gate, the project should be able to demonstrate:

1. the relevant source of uncertainty and affected unit have been identified;
2. an accountable owner and decision authority have been assigned;
3. a proportionate control has been designed and implemented;
4. an artifact or record demonstrates implementation;
5. a competent reviewer has compared the evidence with stated acceptance criteria;
6. WBS/SCC/estimate/schedule/contract links remain current;
7. residual exposure and its bearer are explicit; and
8. retirement and reopening conditions are defined.

Contractual transfer does not remove the underlying physical risk. Transfer may change price, incentives, control, or the party that initially bears a loss, but the program retains exposure to performance failure, insolvency, interface effects, disputes, service delay, and other residual consequences. The taxonomy therefore records practical control and contractual/financial allocation separately.

Relationship to quantitative analysis and contingency

The taxonomy is an identification and governance structure. It does not assign a probability, tier, weight, or contingency percentage to a category.

Quantitative analysis should distinguish:

• base or background uncertainty in quantities, unit rates, production, and duration;
• identified project-specific threats and opportunities represented as discrete or conditional events; and
• bias, correlation, and common-cause effects that can invalidate a simple sum of independent estimates.

FTA's risk process likewise separates general uncertainty from project-specific risks and requires category, SCC, contract-package, and schedule linkages in the risk register. The taxonomy supports that process by improving completeness and traceability. The approved agency/owner quantitative risk method determines funding contingency; category counts and management tiers do not.

Reliable cost and schedule analysis should be grounded in the technical baseline, WBS, assumptions, data, estimating/scheduling methods, sensitivity and risk analysis, documentation, and updates with actual performance.

Coding and maintenance rules

1. Classify the dominant control domain, not the consequence. Cost and schedule are normally impact tags.
2. Use one primary category. Use no more than two secondary categories and state why they are necessary.
3. Distinguish risk from an issue already occurring, an assumption, a fixed constraint, and routine baseline variability.
4. Do not duplicate a risk in several registers. Use common IDs and linked records across program, package, and discipline views.
5. Use “other” only as a temporary code. Review all such entries and update the taxonomy when a recurring gap is demonstrated.
6. Once version 1.0 is approved, keep C01-C14 stable through the life cycle. Add detail below the top level or through secondary lenses rather than frequently renumbering categories.
7. Record the code version and maintain a mapping for merged, renamed, or deprecated subcodes.
8. Review the taxonomy at formal stage gates and after material changes in delivery strategy, regulation, technology, market conditions, or operating context.
9. Test whether controls and evidence are associated with improved outcomes before using taxonomy-based scores as predictive coefficients.
10. Preserve identified-risk and background-uncertainty boundaries so contingency is not counted twice.

Governance and proposed status

This page is proposed as version 0.10 for professional review. Before adoption:

• assign an overall taxonomy owner and a discipline steward for every category;
• complete a crosswalk to the project's FTA, owner, or agency risk categories;
• test classification consistency using historical risks and independent reviewers;
• review category boundaries with geotechnical, utilities, real estate, environmental/social, design, construction, commercial, project-controls, safety/security, systems/cyber, operations, finance, and governance specialists;
• document disputed classifications and revise definitions, inclusions, and exclusions;
• validate every internal link and category against the approved canonical-title crosswalk; keep this review version in a Draft/User namespace without production categories; and
• approve version 1.0 through configuration control.

Calibration of weights, stage distributions, management tiers, or cost/schedule outcomes is a separate research and model-governance activity. Those values should not be inferred from this page.

Limitations

No taxonomy proves that all risks have been identified. Categories can improve the breadth and consistency of inquiry, but novel and interacting risks may cross boundaries or remain unrecognized. Classification also involves judgment; reasonable practitioners may select different primary categories when causal chains are complex.

The C01-C14 structure deliberately organizes risk around the professional process that primarily controls it. It is therefore an operational governance taxonomy rather than a pure ontology of causal sources. Cause-event-effect statements, cross-cutting lenses, dependency links, and the other facets above are necessary to avoid mistaking a convenient filing system for a complete explanation of risk.

See also

• Uncertainty and Risk in Civil Engineering Practice
• Project Definition
• Project Life Cycle and Phase Models
• Project Delivery Methods
• Management Control
• Management Plans and Sub-Plans

References

• Federal Transit Administration, Project and Construction Management Guidelines, January 2025.
• International Organization for Standardization, ISO 31073:2022, Risk management — Vocabulary.
• International Electrotechnical Commission, IEC 31010:2019, Risk management — Risk assessment techniques.
• World Bank, Environmental and Social Standards.