Means and Result Obligations in Engineering: How to Structure the Technical Document

Understand means and result obligations under Law 14.133, how to divide scope portions, and how to structure the TCU-recommended Technical Document linking freedom, risk, and acceptance.

Check it out!

Means obligations and result obligations, 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.

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.

Law No. 14.133/2021 expressly addresses this separation in the concept of the risk matrix. 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.

The TCU’s 2026 Public Works Cost Engineering Guide develops this need further and proposes a practical implementation: a Technical Document 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 “Technical Document” 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.

In practice, the central question is not simply “is the contract based on results or means?”. In complex projects, the same scope may contain different portions, 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.

What distinguishes means obligations from result obligations under Law 14.133

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.

The distinction used by Law No. 14.133/2021 is directly associated with the freedom to innovate in the solution. This is more specific than the generic use of the expressions “means” and “result” in other legal fields.

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.

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.

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

O primeiro cuidado é não usar a expressão “resultado” como sinônimo de transferência irrestricted de responsabilidade. A contratada só pode responder adequadamente por aquilo sobre o que recebeu autoridade técnica, informação e capacidade de decisão. Transferir um risco sem transferir liberdade para gerenciá-lo cria uma assimetria contratual.

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.

Essa relação se conecta à risk-allocation matrix in engineering contracts. 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.

Why this classification needs to occur before procurement

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.

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.

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.

For this reason, the definition needs to arise during the planning phase. The Preliminary Technical Study for construction and engineering services 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.

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.

What is the Technical Document proposed by the TCU

The TCU’s 2026 Public Works Cost Engineering Guide proposes that the Administration use a Technical Document, 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.

The guide’s 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.

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. For each relevant system, subsystem, component, or package, it should allow the following questions to be answered:

• what result or solution is required;
• whether there is freedom for methodological or technological innovation;
• which elements remain frozen;
• which performance requirements are mandatory;
• which interfaces cannot be changed without authorization;
• which risks accompany the granted freedom;
• how performance will be demonstrated;
• how inspection will verify compliance;
• which evidence will be required for acceptance.

The document also needs to be consistent with the project’s level of development. Under integrated contracting, for example, the Administration starts from a preliminary design and transfers development of the basic and detailed designs to the contractor. This naturally creates more room for result-based solutions, but it does not mean the entire scope becomes technically unrestricted. Implementation constraints, minimum performance, safety, interfaces, institutional standards, environmental conditions, and legal requirements still apply.

Under semi-integrated contracting, the relationship is even more sensitive because a basic design exists and the contractor develops the detailed design, with solution changes potentially permitted within legally and contractually established limits. The article on execution regimes under Law 14.133 helps distinguish these structures before defining the applicable degree of freedom.

How to divide a scope into means and result portions

The decomposition should follow the project’s technical architecture. It is not enough to classify the entire contract with a single label. Complex systems consist of subsystems, interfaces, and requirements with different levels of freedom.

A practical method begins with the scope breakdown structure. The team identifies systems, packages, disciplines, or components with distinguishable technical responsibility. It then evaluates, for each portion, which decisions are already stabilized and which can be developed by the contractor.

A robust classification can follow five questions.

1. Does the Administration need to preserve a specific solution? If so, there should be a technical basis for the restriction.
2. Can performance be objectively described and verified? The better the result is defined, the greater the possibility of allowing solution freedom.
3. Does the contractor control the variables that determine this performance? Result responsibility should not be transferred for a variable that remains under the control of the Administration or third parties.
4. Does a solution change affect critical interfaces? The greater the interdependence, the greater the need to define limits and approval processes.
5. Are there reliable testing and acceptance methods? Solution freedom without objective verification turns performance into a promise that is difficult to inspect.

Consider a technology-infrastructure installation. The Administration may require a specific integration protocol because it must interoperate with an existing platform — a means or interface constraint. At the same time, it may allow the contractor to define the internal topology, equipment arrangement, or implementation method provided it achieves measurable availability, capacity, security, and performance — result elements.

In a civil works project, certain finishes, standardized materials, or elements integrating with existing assets may remain prescribed, while structural or construction solutions permitted under the regime may be developed to achieve loads, durability, service life, and other previously defined parameters.

The boundary needs to be sufficiently granular to guide decisions without turning the Technical Document into a complete reproduction of the design. The objective is to identify where freedom exists and which conditions limit that freedom.

The classification should be reviewed whenever the design, procurement strategy, or risk matrix changes. A seemingly small change can shift responsibility between the parties.

How to write requirements for result obligations

A result obligation requires requirements that describe what must be achieved without unnecessarily removing the freedom granted to the contractor. This does not mean writing vague specifications.

The greater the technological freedom, the stronger the performance criteria need to be. The Administration should define function, capacity, reliability, safety, interoperability, service life, operating limits, environmental conditions, interfaces, physical constraints, and acceptance criteria applicable to the scope.

A useful requirement must be verifiable. Expressions such as “high quality,” “modern solution,” “robust equipment,” or “adequate performance” do not provide a sufficient basis for inspection. The requirement needs to indicate a quantity, condition, method, or evidence capable of demonstrating compliance.

A technical specifications for construction and engineering services should balance precision and competition. Under result obligations, this discipline becomes even more important: the Administration needs to protect what truly matters without implicitly designing a single solution and then calling the scope “result-based”.

Good drafting usually separates four layers:

Layer	Content
Function	what the system or component must do
Performance	capacity, availability, accuracy, productivity, durability, or service level
Constraints	standards, safety, interfaces, dimensions, compatibility, environment, operating limits
Verification	test, calculation, inspection, document, simulation, or acceptance test

This structure avoids two extremes: freedom without control and prescriptive specification disguised as a functional requirement.

How to write means obligations without creating gray areas

Under means obligations, the predefined solution needs to be sufficiently clear so that bidding, execution, and inspection start from the same reference. The contractor should be able to identify what is frozen and which execution choices remain under its normal responsibility.

The Administration should specify drawings, design narratives, standards, materials, interfaces, mandatory methods where applicable, and compliance criteria. It should also make clear whether minor detailing optimizations are allowed without changing the solution or whether any change requires formal approval.

The greatest risk is imposing an incomplete solution. If the Administration retains the technological choice but transfers to the contractor the obligation to fill essential design gaps, an undeclared hybrid zone emerges. The contractor may end up assuming engineering risk without receiving sufficient freedom or data to manage it.

This is where Design Review and review of procurement documents become valuable. Before procurement, the team needs to verify whether what was classified as a means obligation is actually defined at a level compatible with execution and the expected price.

Relationship among means, result, and the risk matrix

The risk matrix should not merely list future events. By its legal definition, it also identifies the portions of the scope with and without freedom to innovate. This brings together two decisions that are often treated separately: who chooses and who bears the risk of that choice.

When the Administration imposes a solution, it needs to assess the risks arising from that imposition. The contractor remains responsible for execution, quality, procedures, and obligations under its control, but it is not coherent to assign it the full design risk of an alternative it was not allowed to modify.

When the contractor receives freedom to develop the solution, it may assume additional engineering risks that it controls. These may include performance, sizing, internal compatibility, construction method, or technology, depending on the defined portion. The transfer, however, needs to be accompanied by clear data, requirements, and limits.

O engineering risk management can support this structure by relating event, cause, impact, responsible party, response, and residual risk. The contractual matrix should be a product of this analysis, not a substitute for it.

The classification also affects contingency. The contractor’s price tends to reflect the risks actually transferred and the freedom it has to mitigate them. If the Administration transfers performance risk while restricting the solution, the bid may include a high risk premium or lead to later disputes. If it grants freedom without defining the result, it may receive bids that are difficult to compare.

How classification affects cost estimating and price formation

Under means obligations, the reference estimate can be developed with greater alignment to the defined solution, provided the design has sufficient maturity. Quantities, cost compositions, methods, and productivity rates can be associated with concrete design elements.

Under result obligations, the Administration faces a different challenge: the market may achieve the same performance through different solutions. An estimate remains necessary to forecast procurement cost and evaluate bids, but its structure needs to respect the degree of freedom granted. It is inconsistent to require innovation while assuming that all bids will reproduce exactly the same technological composition as the reference estimate.

The TCU relates this issue to Cost Engineering and risk pricing. The estimate should reflect the intended scope, boundary conditions, risk allocation, and available maturity. Where alternative solutions exist, parametric analyses, benchmarks, reference costs, and modeling may be necessary to test the reasonableness of the estimate.

A development of public works cost estimates needs to be consistent with this architecture. The estimate should not induce a single solution where the tender documents grant freedom, nor conceal uncertainties arising from insufficient definition.

Legitimate efficiency is not the correction of a deficient design

One of the most relevant applications of this distinction arises when the contractor proposes a different solution that reduces cost or schedule. Not every saving represents a legitimate gain in contractual efficiency.

If the portion is result-based and the tender documents authorize technological freedom, the contractor may develop an alternative that meets requirements with a more efficient solution. This competitive space is one of the very reasons for allowing innovation.

A different situation occurs when the saving results from a deficiency in the design provided by the Administration. If the basic design oversized an element, omitted information, or adopted an unsuitable solution and correction becomes necessary to make the scope viable, the change should not automatically be treated as voluntary contractor innovation.

The analysis needs to reconstruct the cause:

1. was the change within the freedom previously granted?
2. did the performance requirements remain unchanged?
3. was the original solution technically valid or deficient?
4. was there a scope change or only methodological optimization?
5. to which party was the corresponding risk allocated?
6. is there an impact on price, schedule, operations, or maintenance?

This distinction protects both the Administration and the contractor. It prevents design deficiencies from being artificially converted into “value engineering” without addressing contractual effects, and prevents legitimate innovation from being blocked out of fear of change.

How to inspect result obligations

Inspecting results does not mean abandoning process control. Inspection needs to verify that the chosen path remains compatible with requirements, standards, interfaces, and performance criteria.

The inspection plan may combine document review, hold points, witness points, inspections, calculations, tests, FAT, SAT, integrated testing, and indicator monitoring. The type of evidence depends on the nature of the contracted result.

For a result obligation, the acceptance process should answer at least four questions:

• was the deliverable provided in the approved document configuration?
• were functional and performance requirements demonstrated?
• do interfaces with other systems operate under the specified conditions?
• does the documentation demonstrate traceability, testing, corrections, and final configuration?

A engineering documentation as a condition for measurement and acceptance is especially relevant at this stage. A technical result without verifiable evidence creates weakness for inspection and future operation.

Contractor freedom also requires change governance. Even under a result obligation, a change affecting an external interface, safety condition, permit, existing asset capacity, or institutional requirement may require approval. The Technical Document should indicate these boundaries.

How to inspect means obligations

Under means obligations, inspection places greater emphasis on alignment between execution and the predefined solution. This involves materials, methods, drawings, specifications, tolerances, procedures, inspections, and records.

Even so, visual conformity alone is not enough. The scope remains subject to performance and quality requirements. The fact that the solution was imposed does not eliminate the contractor’s responsibility to execute it correctly.

Inspection needs to distinguish three types of occurrence:

• execution nonconformity, when the contractor does not comply with the defined solution;
• design inconsistency or deficiency, when the provided solution itself contains conflict, omission, or infeasibility;
• improvement proposal, when a potentially advantageous alternative exists but the portion does not grant automatic freedom to adopt it.

Each case requires a different decision flow. Mixing them creates imprecise records and makes it difficult to assess responsibility, cost, and schedule.

Quando a equipe interna precisa de suporte multidisciplinar para manter essa rastreabilidade, o Technical Support for Inspection of Construction and Engineering Contracts can structure inspections, evidence, change analysis, and compliance controls without replacing the authority of the designated inspector.

How to integrate the Technical Document, Preliminary Technical Study, design, tender documents, and contract

The Technical Document only works if it is aligned with the other procurement artifacts. A result classification contradicted by prescriptive specifications, for example, creates an interpretive conflict. Likewise, a means obligation without a sufficiently defined design transfers gaps to the contractor despite the absence of formal freedom.

Document consistency can be verified through a traceability matrix.

Decision	Preliminary Technical Study	Preliminary design/design	Technical Document	Risk matrix	Tender documents/contract	Acceptance
solution preserved	justification	defined	means	compatible risks	compliance required	inspection/compliance
open solution	justification	requirements and limits	result	transferable risks	bounded freedom	performance/testing
critical interface	need	interface defined	constraint	risk owner	change governance	integrated test
performance requirement	objective	parameter	result esperado	noncompliance risk	contractual obligation	measurable evidence

Essa leitura transversal é uma aplicação prática de Technical Planning for Engineering Procurement. The problem is not drafting each document separately; it is ensuring that all of them represent the same technical strategy.

Uma boa revisão deve procurar contradições. Se o Technical Document classifica determinado sistema como result, mas o projeto prescreve marca, modelo, arquitetura e método sem justificar restrições, a liberdade talvez seja apenas aparente. Se classifica como means, mas o projeto deixa parameters essenciais para definição posterior, a Administração talvez esteja transferindo engenharia sem reconhecer formalmente essa transferência.

When to review the Technical Document during procurement preparation

Initial classification should occur while the procurement strategy is being structured, but it needs to be reviewed as the design matures. Changes in requirements, surveys, reference solution, execution regime, or risk matrix may alter the boundary between means and result.

Three gates are particularly useful.

After the Preliminary Technical Study and selection of the alternative

At this point, the Administration should know why it selected a particular solution model and how much freedom it intends to grant to the market. The classification may still be high-level, but it needs to guide subsequent development.

Before finalizing the tender documents

The design, requirements, estimate, and risk matrix should already allow a precise classification. This is the point to verify whether the Technical Document is consistent with all attachments.

Before publication

An independent review should look for ambiguities, overlaps, inconsistencies, and risks without a clear owner. Changes at this stage are still much less costly than clarifications, challenges, or disputes during execution.

A Technical Review of Tender Documents and Attachments for Engineering Procurement fits this gate because it reviews scope, requirements, designs, risks, measurement criteria, and acceptance as an integrated set.

Recurring errors when defining means and result obligations

The first error is classifying the entire scope uniformly. Multidisciplinary projects rarely have the same degree of freedom across all portions.

The second is calling a fully prescriptive specification result-based. If the Administration defines all relevant components and methods, there is no substantial technological freedom even if the tender documents use performance language.

The third is classifying an incomplete solution as means-based. Lack of freedom does not correct insufficient design; it merely creates conflict when the contractor must make decisions to make the scope executable.

The fourth is separating classification from the risk matrix. As a rule, the party choosing a solution should bear a coherent share of the risks arising from that choice, subject to legal and contractual particulars.

The fifth is defining a result without an acceptance method. A requirement that cannot be objectively demonstrated weakens inspection, measurement, and accountability.

The sixth is ignoring interfaces. A solution may be internally flexible while remaining tightly constrained at interfaces with existing systems. This distinction needs to appear in the Technical Document.

The seventh is turning the document into a legal artifact without sufficient engineering. Classification depends on real knowledge of the solution, disciplines, market, risks, and verification methods.

How to structure an auditable Technical Document

There is no single mandatory model for all procurements, but a useful structure should allow the decision to be traced. The document may begin with identification of the project, scope, execution regime, and reference documents. It should then decompose the scope and classify the relevant portions.

A central matrix may contain:

Field	Purpose
portion ID	traceability
system/package	location within the scope
classification	means or result
justification	technical basis for the choice
solution/requirement	what is prescribed or which result is required
permitted freedom	innovation limits
interfaces	points that cannot be changed in isolation
associated risk	connection with the risk matrix
evidence	document, calculation, inspection, or test
acceptance criterion	objective compliance condition
party responsible for verification	governance

In addition to the matrix, the document may include general rules for change proposals, design submittals, technical review, interface validation, and configuration management.

A traceability é o elemento mais importante. Um auditor, projetista, licitante ou fiscal deve conseguir reconstruir por que determinada parcela foi classificada daquela forma e qual efeito essa escolha produz.

When to engage specialized support to structure this division

The need for support increases with technical complexity, the number of interfaces, and the freedom granted to the contractor. Integrated and semi-integrated procurement, EPC-like arrangements, critical systems, and multidisciplinary projects are situations in which the distinction can materially affect risk and price.

Warning signs include a generic risk matrix, design packages at different levels of development, many expected clarification requests, technology with multiple possible architectures, existing assets that constrain interfaces, performance criteria not yet quantified, and internal uncertainty over which decisions should remain with the Administration.

Under these conditions, specialized work may combine the Preliminary Technical Study, Design Review, requirements engineering, risk analysis, estimate review, and tender-document review. The engagement should produce verifiable deliverables, not merely meetings or generic opinions.

How to procure preparation or review of the Technical Document

The service scope should make clear that the objective is to structure and validate the distribution of technical freedom and responsibility among portions of the scope, consistently with Law No. 14.133/2021, the execution regime, designs, and risk matrix.

A consistent scope may include:

1. analysis of the Preliminary Technical Study, preliminary design or basic design, and other engineering documents;
2. technical decomposition of the scope into relevant systems, subsystems, and packages;
3. identification of functional, prescriptive, and performance requirements;
4. preliminary classification of portions as means or result;
5. analysis of interfaces and dependencies;
6. alignment with the risk matrix and estimate;
7. definition of verification, testing, measurement, and acceptance criteria;
8. technical workshop with discipline leads;
9. issuance of the consolidated Technical Document;
10. cross-review against tender documents, contract, and final attachments.

The products can be measured by deliverables: classification matrix, inconsistency report, preliminary version, validation workshop, and final version. Acceptance criteria should require traceability and closure of critical outstanding items.

The required team depends on the scope. In multidisciplinary projects, a single specialty is unlikely to define all interfaces alone. Engineering coordination, design disciplines, Cost Engineering, risk, and procurement need to work together.

Quando o documento já existe, mas há dúvida sobre sua consistência com projeto e edital, a Technical Review of Terms of Reference for Construction and Engineering Services and technical review of the attachments can be used to test the consistency of the set. When the difficulty arises earlier and involves the procurement strategy itself, Technical Planning is more appropriate.

Final considerations

Means and result obligations should not be treated as abstract legal labels. Under Law No. 14.133/2021, they represent a concrete decision about where the contractor may innovate, where it must adhere to the predefined solution, and how that freedom connects to risk, price, inspection, and acceptance.

The Technical Document recommended by the TCU provides a useful way to make this decision explicit. Its value lies in decomposing the scope, recording justifications, establishing innovation limits, connecting the classification to the risk matrix, and indicating how each obligation will be verified.

The more complex the project, the more important it is to make this definition before procurement. A well-structured boundary improves bid comparability, reduces gray areas during execution, and creates a stronger basis for technical decisions, change management, and accountability.

Technical references

[1] TRIBUNAL DE CONTAS DA UNIÃO. Cost Engineering in Public Works: A Guide of Questions and Answers. Brasília: TCU, 2026.

[2] BRASIL. Lei nº 14.133, de 1º de abril de 2021. Public Procurement and Administrative Contracts Law. Available at: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm

[3] BRASIL. Lei nº 13.303, de 30 de junho de 2016. Legal Statute of Public Companies, Mixed-Capital Companies, and Their Subsidiaries. Available at: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2016/lei/l13303.htm

Frequently asked questions

What is a means obligation under Law 14.133?

It is the portion of the scope in which the contractor does not have freedom to innovate in the methodological or technological solution and must adhere to the solution predefined in the preliminary design or basic design, considering the characteristics of the execution regime.

What is a result obligation under Law 14.133?

It is the portion of the scope in which the contractor receives freedom to develop or modify methodological or technological solutions within the procurement limits and must deliver the specified result and performance.

Must every contract be entirely means-based or entirely result-based?

No. The legal definition itself works with portions of the scope. The same project may contain prescriptive components and components for which solution freedom exists.

Does Law 14.133 require a document called the Technical Document?

The Law requires the risk matrix to identify means and result portions, but it does not create an autonomous mandatory document under that name for all procurements. The TCU’s 2026 Cost Engineering Guide recommends the Technical Document as a way to materialize this classification objectively.

What is the relationship between a result obligation and integrated contracting?

Integrated contracting expands contractor responsibility for design development and tends to create more room for result-based solutions, but freedom is not unrestricted. Requirements, interfaces, performance, safety, and other conditions in the preliminary design and tender documents continue to delimit the solution.

Does a result obligation allow any design change?

No. Freedom exists only in the defined portions and within contractual limits. Changes affecting requirements, interfaces, safety, permits, scope, or other protected conditions may require formal analysis and approval.

How should an item classified as a result obligation be accepted?

Acceptance should be based on verifiable requirements and specified evidence such as calculations, inspections, tests, performance tests, FAT, SAT, documentation, and integrated testing, according to the nature of the scope.

Who should prepare the Technical Document?

Institutional responsibility lies with the contracting Administration within the procurement-planning structure. Preparation or review may receive specialized engineering support while preserving the decision-making authority of public officials.

Complementary technical materials

Related services

• Technical Planning for Engineering Procurement
• Preliminary Technical Study (ETP) for Construction and Engineering Services
• Technical Review of Terms of Reference for Construction and Engineering Services
• Technical Review of Tender Documents and Attachments for Engineering Procurement
• Engineering Risk Management
• Technical Support for Inspection of Construction and Engineering Contracts

Main content on the topic

• Risk Allocation Matrix in Engineering Contracts
• Execution Regimes under Law 14.133
• Preliminary Design under Law 14.133
• Technical Specifications for Construction and Engineering Services
• Scope Execution Model under Law 14.133

Related technical content

• Engineering Documentation as a Condition for Measurement and Technical Acceptance
• Design Review in Engineering Projects
• Risk Management in Public Works
• Public Works Cost Estimating
• Scope of Work (SOW) in Engineering