{"id":81926,"date":"2026-09-21T09:53:41","date_gmt":"2026-09-21T12:53:41","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&p=81926"},"modified":"2026-09-21T09:54:08","modified_gmt":"2026-09-21T12:54:08","slug":"means-result-obligations-engineering-technical-document-law-14133","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/en-us\/content\/technical-articles\/means-result-obligations-engineering-technical-document-law-14133\/","title":{"rendered":"Means and Result Obligations in Engineering: How to Structure the Technical Document"},"content":{"rendered":"\n

Means obligations and result obligations<\/strong>, in the context of construction and engineering services procurement governed by Law No. 14.133\/2021, define the degree of freedom the contractor will have to alter or develop methodological and technological solutions in different portions of the scope. Under result obligations, the Administration establishes the expected performance or result and allows room for contractor innovation within defined limits. Under means obligations, the solution has already been predefined and execution must remain consistent with the preliminary design or basic design.<\/p>\n\n\n\n

This distinction is not merely conceptual. It changes how the scope is designed, estimated, risk-allocated, bid-compared, inspected, measured, and accepted. When the Administration defines a portion as a result obligation, it must precisely specify which functional requirements, performance levels, interfaces, constraints, and verification criteria cannot be violated. When it defines a means obligation, it must provide a sufficiently determined solution so that the contractor knows exactly which technical configuration must be followed.<\/p>\n\n\n\n

Law No. 14.133\/2021 expressly addresses this separation in the concept of the risk matrix<\/strong>. Article 6, XXVII, requires that, for result obligations, the portions of the scope in which there will be freedom for methodological or technological innovation be established; and, for means obligations, the portions in which that freedom will not exist be specified. The classification therefore should not remain implicit or depend on later interpretation during execution.<\/p>\n\n\n\n

The TCU\u2019s 2026 Public Works Cost Engineering Guide develops this need further and proposes a practical implementation: a Technical Document<\/strong> attached to the tender documents, capable of objectively identifying which parts of the scope are treated as result obligations and which remain means obligations. The name \u201cTechnical Document\u201d is a TCU reference-structure recommendation; Law No. 14.133\/2021 does not create, under that specific name, an autonomous mandatory document for every procurement.<\/p>\n\n\n\n

In practice, the central question is not simply \u201cis the contract based on results or means?\u201d. In complex projects, the same scope may contain different portions<\/strong>, some with a frozen solution and others open to optimization. Engineering needs to define these boundaries before procurement so that freedom to innovate, technical responsibility, economic risk, and acceptance criteria are mutually consistent.<\/p>\n\n\n\n\n

What distinguishes means obligations from result obligations under Law 14.133<\/h2>\n\n\n\n

Defining means and result obligations is part of the technical structuring of the scope and its performance criteria. To place this topic within the full lifecycle, see What the TCU reviews in construction and engineering services procurement<\/a>.<\/p>\n\n\n\n

The distinction used by Law No. 14.133\/2021 is directly associated with the freedom to innovate in the solution<\/strong>. This is more specific than the generic use of the expressions \u201cmeans\u201d and \u201cresult\u201d in other legal fields.<\/p>\n\n\n\n

Under a result obligation, the Administration defines what must be achieved and establishes the conditions the solution must satisfy. The contractor may develop or modify methodological and technological aspects of the previously outlined solution, provided it respects requirements, performance, interfaces, legal constraints, and other procurement conditions.<\/p>\n\n\n\n

Under a means obligation, the Administration has already decided the solution applicable to that portion. The contractor does not receive equivalent freedom to replace the concept, technology, or method with its own alternative. Its responsibility is to execute consistently with the predefined solution, subject to the characteristics of the execution regime.<\/p>\n\n\n\n

Aspect<\/td>Means obligation<\/td>Result obligation<\/td><\/tr>
Technical solution<\/td>predominantly predefined<\/td>allows development or innovation within limits<\/td><\/tr>
Contractor freedom<\/td>restricted<\/td>greater, according to the defined portion<\/td><\/tr>
Specification focus<\/td>solution, components, methods, and compliance<\/td>performance, function, interfaces, and result criteria<\/td><\/tr>
Solution risk<\/td>greater retention by the Administration when the solution is imposed<\/td>a greater share may be transferred to the contractor for what it can control<\/td><\/tr>
Inspection<\/td>checks compliance with the solution and requirements<\/td>also verifies performance and achievement of the contracted result<\/td><\/tr>
Methodological change<\/td>normally depends on a formal change or appropriate authorization<\/td>may fall within the permitted freedom if requirements and contractual limits are not changed<\/td><\/tr>
Acceptance<\/td>compliance with the defined solution and technical criteria<\/td>compliance with requirements, performance, and expected result<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

O primeiro cuidado \u00e9 n\u00e3o usar a express\u00e3o \u201cresultado\u201d como sin\u00f4nimo de transfer\u00eancia irrestricted de responsabilidade. A contratada s\u00f3 pode responder adequadamente por aquilo sobre o que recebeu autoridade t\u00e9cnica, informa\u00e7\u00e3o e capacidade de decis\u00e3o<\/strong>. Transferir um risco sem transferir liberdade para gerenci\u00e1-lo cria uma assimetria contratual.<\/p>\n\n\n\n

The second precaution is not to confuse a means obligation with over-specification. For certain components, the solution genuinely needs to be preserved for reasons of compatibility, safety, standardization, interoperability, maintenance, or integration with existing assets. In such cases, predefinition may be technically justified. The problem arises when the Administration freezes details unnecessarily while expecting the contractor to be responsible for performance that depends precisely on choices it was not allowed to make.<\/p>\n\n\n\n

Essa rela\u00e7\u00e3o se conecta \u00e0 risk-allocation matrix in engineering contracts<\/a>. The classification between means and result should not exist in isolation: it needs to be consistent with who controls the variable, who chooses the solution, who bears the impact, and which contractual mechanism will apply if the event occurs.<\/p>\n\n\n\n\n

Why this classification needs to occur before procurement<\/h2>\n\n\n\n
\n

The classification of means and result needs to arise from the procurement strategy. When tender documents transfer performance responsibility without defining corresponding freedom, requirements, and risks, the price tends to incorporate uncertainty and execution becomes dependent on later interpretation.<\/p>\n\n\n\n

Technical Planning for Engineering Procurement<\/a><\/p>\n<\/div>\n\n\n\n

Classifying portions of the scope only after contract award creates a problem at the source. Bidders have already developed price, schedule, execution strategy, and contingencies without clearly knowing how much freedom they would have to develop the solution.<\/p>\n\n\n\n

When this boundary is ambiguous, different bidders may interpret the same tender documents differently. One bidder may price full compliance with a predefined solution, while another assumes it can optimize components or methods. The bids cease to be fully comparable because they do not reflect the same allocation of responsibilities.<\/p>\n\n\n\n

The ambiguity also tends to reappear during execution. A proposed change may be viewed by the contractor as permitted optimization and by inspection as a design deviation. Insufficient performance may be attributed by the contractor to the imposed solution and by the Administration to execution. Savings obtained through a technological change may trigger disputes over who captures the benefit and whether the change was contractually permissible.<\/p>\n\n\n\n

For this reason, the definition needs to arise during the planning phase. The Preliminary Technical Study for construction and engineering services<\/a> is the appropriate environment to justify the strategy: which decisions should remain under Administration control, which can be transferred to the market, and why a given allocation produces a better balance among performance, competition, risk, and governance.<\/p>\n\n\n\n

This decision then affects the preliminary design or basic design, risk matrix, estimate, execution model, measurement criteria, tender documents, and contract. If each document treats contractor freedom differently, the classification loses its usefulness.<\/p>\n\n\n\n\n

What is the Technical Document proposed by the TCU<\/h2>\n\n\n\n

The TCU\u2019s 2026 Public Works Cost Engineering Guide proposes that the Administration use a Technical Document<\/strong>, attached to the tender documents, to state which portions of the scope are result obligations and which are means obligations. The proposal seeks to operationalize what Law No. 14.133\/2021 requires the risk matrix to contain.<\/p>\n\n\n\n

The guide\u2019s stated inspiration relates to Law No. 13.303\/2016, which, for certain integrated contracts of state-owned enterprises, uses a technical document intended to characterize the scope and its elements. In the context of the TCU guide, the idea is to use a specific technical instrument to remove the classification from the implicit realm and make it verifiable.<\/p>\n\n\n\n

The Technical Document should not be treated as just another bureaucratic attachment. Its value lies in functioning as a map of technical freedom and responsibility<\/strong>. For each relevant system, subsystem, component, or package, it should allow the following questions to be answered:<\/p>\n\n\n\n