EoR in practice in medium-sized companies: from appointment to auditable governance.

When risk grows faster than governance.

In medium-sized companies, technical risk often grows faster than governance. Operations accelerate, asset portfolios diversify, teams become multifunctional, and critical decisions begin to occur through informal channels with low traceability. The result is predictable: uncontrolled project changes, ambiguous operational criteria, critical pending issues aging in the backlog, and excessive dependence on specific individuals. In this context, "having an Enterprise of Risk" cannot be treated as a job title, a seal of approval, or a simple signing ritual. It needs to be understood as an operational system of technical governance, capable of converting risk into structured decisions, clear responsibilities, and auditable evidence.

EoR as a system of accountability and evidence.

The Engineer of Record concept, and its pragmatic adaptation for smaller-scale companies, the Engineer of Record model, works when anchored in a simple principle: every critical technical decision must have a person responsible, an accountable person, independent verification, and a package of evidence. This architecture prevents the organization from operating "by memory" and protects the company in the areas where it usually fails: team transitions, short-term pressures, incremental changes that erode safety margins, and communication gaps between engineering and operations.

The three pillars that support EoR throughout the lifecycle.

When properly implemented, EoR supports three pillars throughout the asset lifecycle. The first is the design basis, that is, the set of assumptions, criteria, hypotheses, applicability limits, and uncertainties explicitly accepted. The second is the asset conformity (As-built), which connects what was designed to what was actually built, maintained, and operated, reducing the risk of a "nominal design" disconnected from the field. The third is change management, which ensures that any relevant alteration in assumptions, geometry, drainage, instrumentation, or operating regime is treated as a formal decision, with analysis, approval, and verification. These pillars do not exist to create bureaucracy. They exist to prevent risk from growing through the silent accumulation of deviations.

Organizational design before document volume

Transforming EoR into real governance begins with the correct organizational design, not the volume of documentation. In medium-sized companies, the most efficient arrangement is usually a layered functional organizational chart, in which the chain of command and the technical chain are clearly connected. At the institutional layer, there should be an Accountable Executive for each asset, usually a general manager, operations director, or technical director, who is responsible for prioritization, resources, and formal acceptance of residual risk. This point is crucial: technical risk is not delegable. The organization can delegate analyses and recommendations, but institutional responsibility for decisions affecting safety and integrity always returns to whoever controls the budget, people, and priorities.

Technical authority with real power.

At the technical level, the central role is that of the technical authority over the asset, approving or conditioning relevant changes and escalating impasses. In medium-sized companies, this role needs to be deliberately protected against two common deviations. The first is becoming a "signer" without real power. The second is becoming a bureaucratic bottleneck that replaces operations. The technical authority exists to define minimum standards, ensure traceability, and support decisions under pressure. It does not exist to operate the asset. Therefore, a non-negotiable attribute of this design is a direct line of communication between the technical authority and the responsible executive when there is a conflict between production and control.

Front line and independent review

At the forefront, governance is materialized through the Site Geotechnical Lead, responsible for monitoring, inspections, data quality, triggering actions, and executing operational responses, and through an Independent Reviewer, who tests assumptions, challenges decisions, and verifies the actual closure of critical outstanding issues. The sensitive point here is independence. Independent review "when it's convenient" or only in times of crisis is not review. It's reaction. In a lean model, the review can be quarterly or semi-annual, but it needs to be formal, recurring, and evidence-driven.

Governance requires rhythm: rituals that produce decisions.

An organizational chart without cadence becomes mere intention. Therefore, the Engineering of Results (EoR) needs to be translated into objective rituals with verifiable outputs. Experience shows that medium-sized companies achieve better results with fewer inviolable rituals than with large committees and lengthy meetings. A weekly routine should exist to control performance and anomalies in a timely manner, connecting instrumentation, inspections, water, and critical interventions, and producing clear actions and escalations. The monthly routine, structured as a Technical Review Board, should prioritize pending issues, approve relevant changes, validate conformity between design and operation, and establish investment and sequencing decisions. On a quarterly basis, the Risk and Control Review should assess the integrity of barriers, the performance of trigger and response plans, and the status of independent recommendations. On an annual cycle, a formal review consolidates the year, revalidates the design baseline, reassesses capacity and robustness, including hydraulics and performance under extreme events, and defines the annual engineering and governance plan.

What differentiates governance from theater?

The difference between governance and theater lies in the outputs. Effective meetings always end with three deliverables: decision, action, and evidence. If the meeting ends in alignment without a formal record of what was decided, who approved it, why it was approved, and how it will be verified, the organization remains vulnerable. This is why an operational procedure should mandate three simple and dynamic records, maintained continuously. The first is the technical decision log. The second is the deviation/non-conformity log. The third is the recommendations log. Simplicity is intentional. When the record is too cumbersome, it is not maintained. When it is light and mandatory, it creates discipline.

Change management as the core of the discipline.

The core of the discipline, in turn, is Management of Change. For medium-sized companies, the most effective policy is one based on objective triggers. Change becomes formal change when it alters design assumptions or criteria, relevant geometry, drainage system and hydraulic capacity, operating regime, critical instrumentation, operational limits, response triggers, sensitive geotechnical interfaces such as foundations and abutments, or any decision that reduces safety margins, such as freeboard reduction or loss of redundancy. The minimum change management flow should be short. First, the change and the reason are described. Then, criticality is classified. For medium and high criticality changes, a technical analysis with alternatives and residual risk is performed. Then, approval is obtained in defined instances. Finally, implementation is completed with verification and final registration. What destroys governance is the normalization of small deviations that never become formal decisions. By adding up small deviations, the company creates an asset that no longer corresponds to its own design and discovers this too late, during an audit, an operational occurrence, or an extreme event.

From monitoring to operational control.

In parallel, EoR needs to translate monitoring into control. This occurs when the company establishes clear operational boundaries and implements trigger action response plans, connecting trigger levels, responsible parties, response times, actions, and escalation chain. Without this, instrumentation becomes data collection, not management. With this, instrumentation becomes an operational barrier: it signals loss of control in advance and triggers proportional responses before the organization is pushed towards reactive decisions.

Evidence as a basis for auditing and robustness.

None of this holds up without evidence. Mature audits and robust organizations don't look for pretty reports. They look for traceability. Therefore, implementation should culminate in an evidence package per asset, live, versioned, and with a clear index. This package needs to consolidate the project baseline, as-built records, key operational procedures, including operation, maintenance and surveillance, instrumentation data inventory and quality, trigger and response plans, decision and deviation records, relevant technical reports, independent reviews and evidence of actual closure, as well as competency trails and emergency preparedness when applicable. The rule of thumb is straightforward: a document without an owner, revision date, and connection to a decision becomes a liability.

Pragmatic implementation in short cycles

Successful implementation in medium-sized companies follows a logic of maturity and focus, not perfection. A typical 90-day path begins with defining the pilot and establishing the chain of command, ensuring formal appointment of the responsible executive, the EoR technical authority, and the independent reviewer, as well as a simple change management policy. Next, the minimum cadence is implemented with weekly and monthly rituals and mandatory record keeping. Following this, the project base, operational limits, and trigger and response plans for the pilot asset are consolidated. Finally, the cycle closes with an independent review, verification of the closure of recommendations, and adjustments to the model before rolling it out to other assets.

EoR reality test in operation.

The reality test is simple. An EoR (Expected Reasoning) is working when operations can explain, unambiguously, what the triggers are, who decides, and what will be done if a trigger occurs; and when leadership can see, on a single page, the top technical risks, critical barriers, and the actual status of pending issues being closed. The model fails when relevant changes continue to happen through informal channels, when recommendations are "closed" by response and not by verification, and when the system depends on specific individuals to maintain consistency.

EoR as a decision architecture, not as a formality.

Ultimately, EoR is not a signature and it's not just an organizational chart. It's a decision architecture. For medium-sized companies, the EoR model offers a pragmatic path: few rituals, high discipline; few records, high traceability; few rules, high preventative power. The question that should guide the design is uncomfortable, but useful: if tomorrow it becomes necessary to explain a critical decision to an auditor, a regulator, or potentially impacted individuals, can the organization present the complete chain of assumptions, analysis, decision, approval, implementation, and verification? If the answer is not "yes, and it's here," then governance is still a promise, not practice.