Design Errors in Public Works: Liability of the Designer and Responsible Technical Professional

Understand when a public-works problem constitutes a design failure, how to assess the liability of the designer and responsible technical professional, and which evidence Law 14,133 requires to establish causation and damage.

Check it out!

A design error in a public works project should not be treated merely as a drawing inconsistency that “appeared during construction.” When a failure of conception, sizing, specification, survey, coordination or detailing changes the cost, schedule, quality, safety or functionality of the project, it produces technical, contractual and professional-liability effects. Law No. 14,133/2021 expressly determines that, if changes to public works or engineering-services contracts result from design failures, the responsibility of the responsible technical professional must be investigated and the necessary measures adopted to recover damages caused to the Administration.

This does not mean, however, that every amendment, every RFI or every need for revision found in the field is automatically a “designer error.” Technically consistent accountability requires separating three different situations: a failure existing in the contracted design; a defect resulting from execution or the materials used; and a legitimate change caused by a supervening condition, a new need of the Administration or a risk that could not reasonably have been eliminated during design development. Without this separation, the process risks assigning liability by presumption, when the correct approach is to demonstrate the requirement, authorship, deviation, causal nexus and impact.

ART — the Brazilian Technical Responsibility Annotation — is an important part of this traceability because it identifies, for legal purposes, the technical professionals responsible for engineering activities. It does not replace analysis of the content actually contracted and produced, nor does it make a single professional responsible for every discipline of a multidisciplinary project. To determine responsibility for a failure, it is necessary to reconstruct who had responsibility for the technical decision in question, what level of development was required, what information was available, which design revision was released and how the problem generated the damage or need for change.

What constitutes a design failure in a public works project

Law No. 14,133 defines the basic design as the set of elements necessary and sufficient to define and size the work or service, with an adequate level of precision, and requires solutions detailed enough to avoid, during executive-design development and construction, reformulations or variants that affect quality, price and schedule. The executive design, in turn, must contain the elements necessary and sufficient for complete execution of the work, detailing the solutions provided in the basic design and specifying services, materials and equipment.

This logic is important because the expression “design failure” must be related to the level of development the document was required to have. An omission that could be acceptable in a preliminary study may be incompatible with a basic design ready for procurement. Likewise, a decision that might still be open in the basic design should not remain undefined when the corresponding construction work front depends on an executive design released for construction.

In practice, a failure may appear as:

• insufficient or technically inadequate sizing;
• a specification incompatible with actual installation conditions;
• quantities derived from an incomplete or incorrect survey;
• absence of a solution necessary to execute the scope;
• incompatibility among disciplines;
• an unresolved interface among structure, architecture, building systems or equipment;
• a normative or regulatory requirement not incorporated;
• a technical assumption inconsistent with the available data;
• detailing that does not allow the solution to be executed without significant redesign;
• an outdated document used as a construction reference;
• a change in one discipline not propagated to dependent documents;
• a solution that works in the drawing in isolation but does not meet the performance or functionality of the integrated system.

The existence of a field problem, however, is only the first indication. The diagnosis must determine whether the problem actually originated in the design documentation or resulted from divergent execution, substituted material, an unknown condition, an unrecorded interference or a later modification.

The article on Basic Design vs. Executive Design helps explain why failure analysis must consider the maturity required at each stage. The content on construction without an executive design addresses the legal gate for execution, while the focus here is different: technically determining origin and responsibility when an already-produced design proves inadequate.

How to distinguish design failure, execution error and legitimate change

The distinction is decisive because each origin leads to different responsibilities, records and contractual treatments.

Situation	Predominant technical origin	Typical evidence	Initial treatment
Design failure	Inadequate conception, calculation, specification, survey, coordination or detailing	Released design, calculation memorandum, requirement, revision, incompatibility	Technical review, causation analysis and possible investigation of responsibility
Execution error	Work executed contrary to the design, specification or procedure	Inspection, RDO, photos, tests, IFC drawing and built condition	Nonconformity, correction by the contractor and inspection
Inadequate material	Material supplied differs from the approved material or lacks required performance	Submittal, certificate, datasheet, receiving inspection	Rejection, replacement and contractual treatment
Unforeseen condition	Physical condition or interference not detectable with reasonable diligence	Field survey, investigation, records, discovery log	Risk assessment, technical solution and possible contract change
Administration change	New requirement, use, capacity or standard requested after the baseline	Formal request, meeting minutes, administrative decision, change request	Change management and impact analysis
Legitimate technical evolution	Optimization or adjustment permitted by the contractual regime and formally approved	Comparative study, approval, risk matrix	Change control and baseline update

A simple example is a pipe that clashes with a beam. The clash may represent a design-coordination failure. But it may also have been created because the structure was built out of position, because the installed pipe did not follow the planned route, or because a later architectural revision moved the room without updating the other disciplines. The final image of the clash is the same; responsibility is completely different.

For this reason, mature processes use Design Review, multidisciplinary coordination, interface review and revision control before issue for construction. The purpose is not to create a bureaucratic layer, but to reduce the probability that a documentary inconsistency passes through the design stage and becomes a construction cost.

Divergent execution does not automatically make the design responsible

Law No. 14,133 establishes that the contractor must repair, correct, remove, reconstruct or replace, at its own expense, the scope in which defects, deficiencies or inaccuracies resulting from execution or materials used are found. Inspection does not eliminate this responsibility.

Therefore, if the design correctly specified the element and the contractor executed a different solution without approval, the primary origin is not the design. It is also incorrect to attribute to the designer a failure introduced by commercial substitution of equipment, a field route change or a construction method incompatible with the approved solution.

Not every design revision is a failure

Designs are developed against a given baseline of requirements, surveys and assumptions. A later change in need, capacity, applicable law, boundary condition or implementation strategy may require revision without the original document having been technically wrong for the information available when it was issued.

This is why requirements management and change management are essential. Without requirements and configuration history, a legitimate change occurring months later may retrospectively be interpreted as an original error.

What Law 14,133 establishes regarding design failures

The central provision is art. 124, §1. It establishes that, when changes to public works and engineering-services contracts result from design failures, those changes will require investigation of the responsible technical professional’s liability and adoption of the measures necessary to recover damages caused to the Administration.

The text has three important practical consequences.

First, the need to change the contract does not close the matter. Technically resolving the work and formalizing an amendment may be necessary to preserve the project, but the Administration must still assess whether the change resulted from a design failure and whether associated damage occurred.

Second, accountability presupposes a demonstrable relationship between the failure and the change. The mere existence of an amendment does not prove a design error. Public works may be changed because of a legitimate modification by the Administration, a supervening condition, expropriation, licensing, demand change or other events provided for in the legislation itself.

Third, the text refers to the responsible technical professional. This makes traceability of authorship, attribution, ART, discipline and scope essential. In a multidisciplinary design, it is not technically appropriate to treat all professionals as indiscriminately responsible for any problem arising in the project.

Acceptance of the design does not extinguish liability for failure

Another relevant provision is art. 140. The Law determines that final acceptance of a design does not exempt the designer or consultant from strict liability for damage caused by a design failure.

This corrects a dangerous interpretation: administrative approval of the deliverable does not operate as absolute technical discharge. The Administration must review and accept the product according to its contracting process, but later discovery of a failure capable of causing damage does not automatically cease to be subject to analysis merely because the document had been accepted.

At the same time, this rule does not exempt the Administration from maintaining a technically robust review and acceptance process. Approving designs without criteria, evidence or technical capacity increases project exposure. Requirements, evidence and acceptance-criteria management reduces this weakness by making explicit what must be verified before each release.

ART, authorship and technical responsibility: what must actually be traced

Law No. 6,496/1977 determines that contracts for construction works or professional engineering services are subject to the Anotação de Responsabilidade Técnica — ART — and establishes that ART defines, for legal purposes, the technical professionals responsible for the engineering undertaking.

ART is therefore an essential traceability record. But the technical investigation should not stop at the document’s existence. The ART must be compared with the contract, discipline, scope actually produced, authorship of the documents, revisions and decisions that led to the element under question.

Law No. 5,194/1966 reinforces this logic when addressing authorship and responsibility of professionals collaborating on parts of a design. In complex projects, technical responsibility should be related to the portions actually developed and assumed by each professional.

A minimum traceability matrix usually includes:

• company or professional contracted for the design;
• contracted scope and object;
• technical discipline;
• responsible technical professional and corresponding ART;
• authors and reviewers of each document;
• document code and revision;
• issue date;
• document status, such as preliminary, for approval or released for construction;
• requirement or assumption from which the solution originated;
• approvals and comments received;
• later changes and their respective responsible parties;
• document actually used by construction.

This chain is especially relevant when teams change, designers are replaced, disciplines are contracted separately or the design is developed by a consortium. Without it, the investigation may end up linking a problem to the wrong company or professional.

How to technically demonstrate that damage originated in the design

An investigation of responsibility should not begin with the question “who made the error?” but with an objective reconstruction of the event. The objective is to establish a verifiable chain:

applicable requirement → available information → designed solution → technical deviation → manifestation in construction → required change → cost/schedule/quality impact → technical professional responsible for the decision.

This sequence prevents conclusions based solely on field perception.

1. Identify the requirement that should have been met

The first step is to determine which requirement, standard, dimension, performance criterion, interface or condition should have been observed. Without a requirement there is no technical reference against which to characterize a deviation.

The source may be the program of requirements, Terms of Reference, basic design, technical standard, technical memorandum, manufacturer requirement, legislation, contract, interface matrix or formal decision of the Administration.

2. Determine what data were available to the designer

A solution may appear inadequate after new information emerges. The analysis must determine whether that information already existed or reasonably should have been obtained during surveys and design development.

Examples include:

• topography;
• records of existing networks;
• geotechnical investigation;
• architectural survey;
• load data;
• operational requirements;
• utility-company information;
• characteristics of existing equipment;
• environmental conditions;
• implementation constraints.

If the contract included a survey and the relevant data could have been identified with the contracted method, its absence may form part of the failure. If the condition was hidden and not detectable through the reasonable diligence provided for, the analysis changes in nature.

3. Establish the correct documentary baseline

It is necessary to know which revision was valid when construction made the decision. In many disputes, the analysis fails because it compares the built condition with a PDF that was not the current revision.

Document governance should make it possible to identify issue, revision, transmittal, approval and distribution. Loose emails or files with names such as “final_v2_corrected” are not a reliable baseline for a significant project.

4. Technically characterize the deviation

The deviation should be described in measurable terms. “Bad design” is not a technical conclusion. It is necessary to state, for example, that the calculated cross-section was insufficient for the design load, that there was inadequate physical space for maintenance, that two disciplines occupied the same volume, that the specification did not meet the environment, or that the quantity did not correspond to the available survey.

5. Demonstrate the causal nexus

Next, it must be demonstrated that the deviation produced the alleged consequence. A failure may exist without causing the claimed damage; another may have contributed together with an execution error, delayed decision or later modification.

Causation analysis should separate root cause, contributing factors and consequences. In complex cases, root cause analysis techniques help prevent the first visible deviation from being treated as the only cause.

6. Quantify the incremental impact

The damage resulting from the failure is not necessarily equal to the total value of the corrective solution. Part of the cost might have existed even if the design had been correct from the beginning.

The analysis should separate:

• cost that would already have been necessary in the original scope;
• demolition or rework cost caused by the failure;
• lost materials;
• unproductive hours;
• additional mobilization;
• effect on the critical path;
• indirect cost of schedule extension when demonstrated;
• new designs, tests or permits required exclusively because of the correction;
• other effects directly attributable to the event.

This separation is essential to avoid overestimating the damage.

Multidisciplinary failures require interface analysis, not a search for one culprit

Many significant design problems do not exist within a single discipline. They appear at boundaries: structure vs. building systems, architecture vs. equipment, electrical vs. automation, drainage vs. earthworks, utilities vs. process, civil works vs. manufacturer.

A pipe may be correctly sized and still be impossible to install because the structural penetration was not coordinated. An electrical panel may be electrically correct while lacking access and maintenance space. Equipment may meet its specification but require power, exhaust, foundation or network infrastructure that was not incorporated by the other disciplines.

For this reason, interface management should define who provides information, who receives it, which document records the interface and who verifies closure. Without this structure, a later investigation may find multiple documents that are technically correct in isolation and a globally unworkable system.

Responsibility may be shared when different professionals had complementary obligations over the interface. But this conclusion must arise from contracts, technical attributions and records, not from an arbitrary division of percentages.

Integrated and semi-integrated contracting change the allocation of design risk

The contractual execution regime changes the analysis. Under integrated contracting, the contractor develops the basic design from the preliminary design and assumes the risks associated with the design under the Law and the contract. Under semi-integrated contracting, the basic design is provided by the Administration, but the contractor may be permitted to change it with authorization and demonstration of the superiority of the innovation, assuming the risks associated with the change.

This means the question “who designed it?” is insufficient. It is necessary to identify which version of the solution belongs to which party, who had freedom to modify it, which risk was allocated and which document was actually approved.

The risk allocation matrix must align with the regime, design maturity and interfaces. Generic clauses that transfer “all design risks” without consistency with the documents provided tend to create disputes rather than governance.

The role of inspection when a possible design error appears

The inspector should not improvise a new solution in the field without a formal process. When identifying a condition potentially resulting from a design failure, the record should preserve the evidence and prevent the correction from destroying the history required for analysis.

A technically prudent sequence includes:

1. record the condition found in the RDO or equivalent system;
2. identify the current related documentation;
3. stop only the affected work front when necessary for safety or rework risk, without automatically turning the event into a total stoppage;
4. issue an RFI, technical query or nonconformity according to the contractual process;
5. obtain a statement from the designer or party responsible for the solution;
6. assess alternatives and impacts;
7. formalize the decision through the competent authority;
8. update documents, budget and schedule when applicable;
9. preserve the event dossier for a possible investigation of responsibility.

Law No. 14,133 allows third parties to be contracted to assist and support the inspector with technical information. technical support for inspection is particularly useful when the scope has high multidisciplinary complexity or when the public team does not internally possess all necessary specialties. This support does not replace the inspector’s statutory authority; it improves the quality of evidence and technical decisions.

How to correct the problem without erasing evidence of the failure

There is a practical tension: construction must continue, but the Administration must also preserve the elements needed to determine origin and impact. The worst approach is to correct the problem quickly without recording the previous baseline and then try to reconstruct the event months later.

Before intervention, the following should be preserved as relevant:

• drawings and models in the current revision;
• calculation memoranda;
• specifications;
• photos and videos of the condition found;
• dimensional survey;
• RDO;
• RFI and responses;
• decision minutes;
• original item budget;
• correction budget;
• schedule for the affected work front;
• material already procured or installed;
• inspection records;
• identification of professionals involved.

When the correction requires a contract change, the technical analysis of amendments should separate the objective need to modify the contract from the investigation of who should bear the damage arising from the origin of the change.

This separation avoids a false dilemma: recognizing the need for an amendment does not automatically mean recognizing that the Administration should absorb all of its costs.

How to prevent design failures before procurement

Prevention begins before the procurement notice is published. The earlier an inconsistency is found, the fewer decisions, purchases and construction services need to be undone.

Surveys appropriate to project risk

Reliable design depends on reliable data. Existing-condition surveys, topography, geotechnical investigation, inspections, utility data and operational requirements must be proportional to the complexity and decision level of the stage.

Saving on diagnosis to “gain time” may merely transfer uncertainty to construction, where each discovery costs more to resolve.

Objective maturity criteria

The Administration can use readiness gates to prevent a package from advancing merely because the planned date has arrived. Content on Project Readiness and PDRI shows how scope maturity can be treated systematically.

A package ready for procurement should allow answers to questions including:

• are requirements defined and traceable?
• have critical surveys been completed?
• are disciplines coordinated?
• have relevant interferences been addressed?
• are technical memoranda and drawings consistent?
• do quantities reflect the documentation?
• is the budget traceable to the designs?
• are licensing and utility requirements incorporated?
• have residual risks been made explicit?
• do documents have controlled revision and status?

Independent review at points of greatest consequence

Not every design requires the same review effort. A risk-based approach concentrates Design Review, independent calculation, clash detection and Project Assurance on the elements whose failure would have the greatest effect on safety, cost, schedule or operations.

The Design Review service for engineering projects acts precisely at this boundary: verifying consistency, maturity, interfaces and risks before the document becomes an expensive construction instruction.

The Terms of Reference should define what an accepted design means

If the Terms of Reference merely require “delivery of executive design” without defining disciplines, minimum content, review criteria, format, coordination, calculation memoranda, responsibilities and approval process, the contract creates a future dispute over what should have been produced.

A technical review of the Terms of Reference before procurement reduces this risk by determining whether engineering deliverables are verifiable and sufficient for the decision they are intended to support.

When an independent failure analysis makes sense

An independent analysis tends to add more value when the event has one or more of these characteristics:

• significant economic impact;
• risk of stoppage;
• multiple designers or contractors involved;
• conflict among inspection, designer and contractor;
• need for a significant amendment;
• possible request for economic-financial rebalancing or claim;
• safety or performance risk;
• need to investigate responsibility;
• absence of a public-sector team in the necessary specialty;
• extensive documentation or conflicting versions.

The scope should not be formulated as “find the culprit.” A good independent analysis defines the event, reconstructs requirements and the baseline, identifies causes and contributing factors, verifies contractual responsibilities, quantifies impacts and presents conclusions supported by evidence.

Owner’s Engineering can perform this technical integration role throughout the project, creating the governance needed so that divergences are identified before they become disputes.

Practical example: foundation change during construction

Consider a project in which, after excavation, the team concludes that the planned foundation cannot be executed as designed. Immediately stating that “there was a design error” is premature.

The analysis should ask:

1. which geotechnical investigations were required and which were performed;
2. was the condition found represented in the investigation logs?
3. did the designer receive those data?
4. did the calculation memorandum use parameters consistent with the results?
5. did construction reach the specified elevation and location?
6. was the facility location changed after the investigation?
7. was there a localized geotechnical condition not captured by a reasonably sized investigation campaign?
8. which solution would have been necessary even if the condition had been known earlier?
9. what portion of the correction is incremental cost caused by the event?

If the investigation clearly indicated the condition and the calculation disregarded the data, the evidence points toward a design failure. If the contracted investigation campaign was inadequate because of a deficiency in the Administration’s own scope, the analysis may involve a planning failure. If the condition was geologically unforeseeable at a reasonable level of investigation, the event may belong to another contractual risk.

The value of engineering is to produce this distinction before the administrative decision.

Practical example: equipment does not fit in the designed room

Another common case occurs when specified equipment cannot be installed, transported or maintained in the available space.

Possible causes include:

• equipment dimensions were known but not coordinated by architecture;
• equipment was changed later without updating the layout;
• the supplier delivered a model different from the approved one;
• the transportation route was not considered;
• built infrastructure reduced the usable space;
• maintenance requirements were not defined.

The corrective solution may be identical — enlarge an opening, modify the layout, disassemble components — but origin and responsibility change according to the documentary chain.

This type of problem demonstrates why design is not merely a set of drawings. It is a system of requirements, interfaces, decisions and configurations that must remain consistent until delivery of the asset.

Checklist for investigating a possible design error

Before concluding that the designer is responsible, verify whether the process can answer:

• Which requirement was not met?
• Which document was supposed to satisfy the requirement?
• Which revision was current?
• Who prepared and who assumed technical responsibility for this portion?
• Has the corresponding ART been identified?
• What information was available when the solution was developed?
• Did the design meet the contracted level of maturity?
• Did construction fully follow the designed solution?
• Was there a later change in requirement, equipment or boundary condition?
• Are there contributing factors from execution, procurement or inspection?
• Has the deviation been technically demonstrated?
• Is there a causal nexus between the deviation and the alleged damage?
• Was the incremental impact separated from the cost that would normally have existed?
• Is the correction formally approved and reflected in current documentation?
• Was the evidence existing before the correction preserved?

If these questions cannot be answered, the priority should be to complete the technical record before formulating a conclusion on responsibility.

Final considerations

Law No. 14,133 made explicit an obligation that, technically, should already be part of sound public-works governance: changes resulting from design failures cannot be treated merely as spreadsheet adjustments. The Administration must investigate technical responsibility and take measures to recover damages when they are demonstrated.

The quality of this investigation depends less on retrospective opinions than on traceability built throughout design and construction. Clear requirements, ART, revision control, Design Review, field records, RFIs, measurements and change management turn a potential dispute into a technically analyzable issue.

The objective is not to eliminate every change — unrealistic in complex projects — but to consistently distinguish avoidable failure, inadequate execution, supervening condition and legitimate change. This distinction protects the public interest, reduces disputes and improves the quality of engineering decisions.

Technical references

[1] BRAZIL. Law No. 14,133, of April 1, 2021. Procurement and Administrative Contracts Law. Available at: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm. Available at: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm.

[2] BRAZIL. Law No. 5,194, of December 24, 1966. Regulates the practice of the professions of Engineer, Architect and Agronomist Engineer. Available at: https://www.planalto.gov.br/ccivil_03/leis/l5194.htm. Available at: https://www.planalto.gov.br/ccivil_03/leis/l5194.htm.

[3] BRAZIL. Law No. 6,496, of December 7, 1977. Establishes the Anotação de Responsabilidade Técnica for engineering, architecture and agronomy services. Available at: https://www.planalto.gov.br/ccivil_03/leis/l6496.htm. Available at: https://www.planalto.gov.br/ccivil_03/leis/l6496.htm.

[4] TRIBUNAL DE CONTAS DA UNIÃO. Procurement and Contracts: TCU Guidance and Case Law. Available at: https://licitacoesecontratos.tcu.gov.br/. Available at: https://licitacoesecontratos.tcu.gov.br/.

Frequently asked questions

Does every construction amendment caused by a design revision constitute a designer error?

No. An amendment may result from a legitimate Administration change, supervening condition, contractual risk, requirement change or execution failure. To characterize a design failure, the requirement, technical deviation, authorship, causal nexus and impact must be demonstrated.

What does Law 14,133 say about design errors in public works?

Art. 124, §1 establishes that contract changes resulting from design failures require investigation of the responsible technical professional’s liability and adoption of the measures necessary to recover damages caused to the Administration.

Does approval or final acceptance of the design eliminate the designer’s liability?

No. Law 14,133 provides that final acceptance of a design does not exempt the designer or consultant from strict liability for damages caused by a design failure.

Does ART define who must answer for any failure in the project?

ART identifies the responsible technical professionals for legal purposes, but the investigation must relate the ART to scope, discipline, authorship, revision and the technical decision actually associated with the failure. Multidisciplinary projects may involve distinct or shared responsibilities.

How do you distinguish a design error from an execution error?

The built condition must be compared with the current document, requirements and specifications. If the designed solution was correct and construction diverged from it, the origin tends to be execution. If the released solution itself was insufficient or incompatible, there is an indication of design failure.

Who should analyze a possible design error in a public works project?

The Administration should develop the record through its inspection team and competent responsible parties and may use specialized technical support. In complex events, an independent engineering analysis can reconstruct the baseline, causes, responsibilities and impacts without replacing the statutory powers of the manager and inspector.

How should damage caused by a design failure be calculated?

The calculation should consider only impacts attributable to the event, separating the cost that would already have been necessary in the original scope from rework, material loss, schedule extension, additional mobilization and other directly demonstrated incremental effects.

Complementary technical materials

Related solutions

• Requirements, Evidence and Acceptance-Criteria Management
• Issues, RFIs and Nonconformities Management
• Process, Workflow and Technical-Approval Management
• Contract, Scope and Deliverables Management

Related services

• Design Review for Engineering Projects
• Executive Engineering Design
• Owner’s Engineering
• Technical Support for Public Works and Engineering-Contract Inspection
• Technical Analysis of Amendments, Scope Changes and Claims in Engineering Contracts

Main content on this topic

• Construction without an Executive Design? What Law 14,133 Requires Before Starting
• Executive Engineering Design: Definition, Stages, Detailing and Deliverables
• Basic Design vs. Executive Design in Engineering Consulting Procurement

Related technical content

• Design Review in Engineering Projects: Technical Review, Interfaces and Design Maturity
• Multidisciplinary Engineering Design: Disciplines, Coordination, Interfaces and Deliverables
• Risk Allocation Matrix in Engineering Contracts
• Contract Amendments in Public Works and Engineering Services
• Project Readiness in Engineering
• Owner’s Engineering: Executive Framework for Procurement, Governance and Acceptance
• Complete Guide to Engineering Consulting