How One Operator Automated Their Hydraulic Model Builds

1Introduction: The Question the Model Could Not Answer

The story begins, as these stories usually do, with a commercial question on a deadline. A producer customer approached the operator (a North American midstream company; we will call them only "the operator" throughout, by agreement) with new volumes that needed a home: could the gathering system take the additional gas, and what would it do to pressures at the existing receipt points?

It is the kind of question a hydraulic model exists to answer, and the operator had a hydraulic model. What followed instead was a familiar sequence. The model file was found on the laptop of an engineer who had left eight months earlier. The model predated two looping projects, a compressor re-wheel, and an acquisition that had added a third of the system's mileage. The GIS had been updated for some of that; the model had been updated for none of it. The engineering manager did the responsible thing and commissioned a rebuild, and the rebuild did what rebuilds do: it consumed an engineer's attention across six calendar weeks of document hunting, transcription, reconciliation, and calibration, while the commercial question waited.

The detail worth dwelling on is that almost none of those hours were engineering. The system's true configuration existed, in pieces, in documents the operator already possessed: P&IDs, alignment sheets, GIS layers, equipment datasheets, as-built packages, and the historian. Those weeks were spent moving information from documents into a model, item by item, by a person whose judgment was needed for perhaps a tenth of the items. The operator's engineering leadership drew the conclusion this paper defends at length: the expensive part of hydraulic modeling is not the simulation; it is the data plumbing in front of the simulation, and that plumbing can be automated, with engineers verifying instead of transcribing.

This paper documents what the operator built and how their operating practice changed, in enough detail for another engineering leader to evaluate the approach: the structured asset data type that became the single substrate for every study (Section 5); the document-extraction pipeline that populates it (Section 6); version control for studies (Section 7); managed simulation artifacts (Section 9); continuous reconciliation between systems (Section 10); and the measured outcomes (Section 11). Throughout, identifying details have been altered or omitted; the numbers reported are limited to those the operator has approved for publication.

2The Anatomy of a Manual Model Build

To automate a process honestly, you have to account for where the time actually goes. The operator's post-mortem on their last fully manual build produced a breakdown that engineering leaders at other midstream shops will recognize. Table 1 gives the phases in qualitative form (the precise split varies by system and team, and the point survives any reasonable split).

Three observations from the table drive everything that follows.

The inputs already exist. Every fact the model needs is already recorded somewhere in the operator's document set or systems. A manual build is not data creation; it is data relocation, with error introduced at each hop.

The work is lost the moment it finishes. The transcription and reconciliation effort lives and dies inside one simulator input file. The next study, the next engineer, the next acquisition: each starts the hunt again. Nothing accumulates.

Staleness is structural, not negligent. The system changes continuously (MOCs, loops, re-wheels, acquisitions); the model changes only when someone burns weeks. Under that cost structure, a stale model is not a failure of discipline. It is the equilibrium.

3Why the Problem Persisted

If the waste is this visible, why had it survived a decade of digital-transformation budgets? The operator's diagnosis, which we endorse, is that prior attempts had aimed at the wrong layer.

Buying more simulator did not help. The operator owned capable, industry-standard simulation tools, and this paper is not an argument against them; the deep tools remain in the stack today. But every simulator purchase assumed the input problem away. The license made the mathematics faster; the model still arrived by hand.

Document digitization without structure did not help. Scanning the filing cabinet into PDFs made the document hunt faster and changed nothing else. A scanned alignment sheet is still read by a human and re-keyed by a human.

One-time data projects did not help for long. A consultant-led data cleanup produced a beautiful snapshot that began decaying the week it was delivered, because no mechanism existed to keep it true. This is the same equilibrium argument as Section 2: without changing the cost of staying current, every snapshot is temporary.

The knowledge kept walking out the door. The deepest version of the problem was demographic. The engineer who knew why the model said what it said, which segments were calibrated against which historian tags, and where the bodies were buried in the reconciliation, retired or changed jobs, and the model's trustworthiness retired too. The institution had results; it did not have provenance.

The conclusion the operator reached: the missing layer was not simulation and not storage. It was a data discipline for engineering models, with three properties borrowed deliberately from how software teams treat code: a canonical, versioned source of truth; changes tracked with history and provenance; and automation doing the mechanical work while humans review. The rest of this paper is that discipline, as implemented.

4The Design: Three Pillars

The operator's implementation, built on the FlowSync platform, reduces to three pillars. We state them plainly because each addresses one of the failure patterns of Section 2:

1. No data entry. GIS, documents, and operating data flow into the model substrate automatically. Engineers verify extractions; they do not transcribe.
2. Don't duplicate results. Studies and their artifacts are version-controlled and indexed. Work accumulates instead of evaporating; no one re-runs a study because they could not find or trust the last one.
3. Reconcile between systems. The substrate is continuously checked against GIS, documents, and live data. Drift is detected and either auto-resolved or flagged as a work item, so the model cannot quietly go stale.

A fourth element runs through all three pillars without being a pillar itself: agents assist in a controlled way. Extraction, drift reconciliation, and study preparation are agent-assisted, but the actions are bounded, the output is traceable to its source document, and an engineer reviews before the record changes. Nothing enters the Golden Record that a human did not accept, and nothing the agents produce arrives without a citation to the drawing, sheet, or tag it came from. The working posture at the deployment fits in one sentence: the agents do the typing, and the engineers do the judgment.

5The Golden Record: A Data Type for Pipeline Assets

The foundational decision was to treat the asset model as a data type, not a file. The distinction is worth making precise.

A simulator input file satisfies none of these clauses: it is unstructured outside its tool, unversioned beyond filename conventions, unqueryable, and provenance-free. The Golden Record satisfies all of them, and the practical consequences are what an engineering team feels day to day: any model for any tool can be generated from the record rather than built; any question of the form "what changed on this segment since March?" is a query, not an archaeology project; and any disputed value resolves by following its provenance to the source document instead of by meeting.

Two design choices in the schema earn their keep repeatedly. First, provenance is a first-class field, not metadata bolted on: when the record says a segment is 10.75 inch OD, it also says which alignment sheet revision asserted it. PHMSA's traceable-verifiable-complete expectations for records (PHMSA, 2012) turn out to be precisely the discipline a living model needs anyway; the compliance posture and the engineering posture converge on the same schema. Second, the record is tool-neutral: it exports to the operator's existing industry-standard simulators rather than replacing them. The deep tools keep their licenses and their roles; they stop being fed by hand.

6Building the Record from the Documents You Already Have

The Golden Record would be just another empty schema if populating it cost weeks of engineering time. The population mechanism is the part of the operator's story that changed the economics: a document-extraction pipeline that reads the engineering document set the way an engineer would, and proposes record entries with citations.

6.1The pipeline

Five stages, each a specialized agent, each producing output an engineer can inspect:

1. Drawing classification. Sorting the inbound set into P&IDs, alignment sheets, isometrics, datasheets, cutsheets, as-built packages, and the irrelevant.
2. Symbol and tag recognition. Identifying equipment, instruments, line numbers, and tags on the classified drawings, including the scanned and photocopied generations of drawings that real document sets contain.
3. Topology extraction. Tracing flowpaths and connectivity: what connects to what, through what, in which direction.
4. Specification extraction. Pulling diameters, ratings, materials, setpoints, and equipment parameters from datasheets and schedules into typed fields.
5. Reconciliation. Cross-checking the extracted assertions against each other and against GIS: agreements merge quietly; disagreements become flagged items with both sources cited.

6.2The engineer's new job: verify, not transcribe

The pipeline's output is not silently committed. It arrives as a review queue: each proposed entry with its confidence and its citation, disagreements up front. The engineer's interaction is accept, correct, or escalate, and a correction teaches the pipeline about that document family's conventions. The operator's experience matches the design intent: review of a proposed extraction runs orders of magnitude faster than transcription, because reading-and-judging is what engineers are for, and typing is not. This is the concrete meaning of the no data entry pillar, and it is also where the controlled-agent posture is most visible: the agent proposes with citations; only the engineer commits.

For the operator's acquisition workflow, this stage is where the change was most dramatic. An inbound acquisition package (the proverbial 400-page PDF plus a GIS export of uncertain vintage) became something the team ingests in the ordinary course of a week, with the diligence questions answered against an extracted, cited model rather than against a binder.

7Version Control for Studies

The second pillar treats the study, the unit of engineering work, the way software treats code. The operator's engineers, several of whom had never used a version-control system, now describe their work in its vocabulary, because the mapping is exact:

Three operating consequences followed at the deployment.

No study starts from scratch. A new question starts from the current record and the nearest prior study, not from a blank input deck. The marginal cost of the next study is where the compounding shows up; Section 11 quantifies it.

Provenance survives personnel. The question "why does the model derate this compressor in summer?" is answered by the study history (who set it, when, citing what), not by the memory of someone who may have retired. The institutional-knowledge exposure of Section 3 is structurally reduced: the reasoning is in the repository.

Review became normal. Because a study is a discrete, diffable object, peer review of studies (the engineering equivalent of a pull request) became a lightweight habit rather than a ceremony. Errors get caught at the diff, not at the regulator meeting.

8The Acquisition Test

Midway through the deployment, the approach met its hardest realistic test: the operator closed on an acquisition that added a material fraction of new mileage, arriving in the form every corporate-development team will recognize. A data room of scanned documents of mixed vintage. An export from the seller's GIS, schema unlike the buyer's, last reconciled against the field at an unknown date. A seller's hydraulic model in a simulator the buyer did not run, calibrated by a contractor no longer reachable. And a transition-services clock already ticking.

Under the operator's previous practice, integrating an acquisition's engineering data was a multi-quarter project that, candidly, usually just never finished: the urgent studies got done by heroics against the seller's artifacts, and the systematic rebuild stayed on the backlog until the next acquisition buried it.

Under the new operating model, the acquisition package was treated as one more inbound document set:

1. The data room went into the extraction pipeline as-is: classification first (which of these 11,000 pages are alignment sheets, P&IDs, datasheets, MOC records?), then tag, topology, and specification extraction, each assertion cited to its page.
2. The seller's GIS export was ingested as another source for reconciliation, not as truth: where it agreed with the extracted documents, the record merged quietly; where it disagreed, the disagreement entered the drift queue with both citations, which is exactly where a diligence engineer wants their attention directed.
3. The verification sprint ran with the buyer's engineers reviewing proposals rather than re-keying a stranger's filing system. The unfamiliarity of the seller's drawing conventions cost accuracy in the first review batches and then stopped costing it, as corrections taught the pipeline the conventions.
4. The acquired system's studies began life in version control. There was no legacy pile to migrate, and the first capacity study on the acquired mileage is now the oldest entry in that system's history, with its assumptions readable by whoever runs the tenth.

Two observations from that integration generalize. First, acquisitions are the worst case for manual model building and the best case for extraction, because the document set is large, foreign, and arrives all at once: precisely the conditions under which human transcription is slowest and least reliable. Second, the drift queue is a diligence instrument. The disagreement list between a seller's GIS and a seller's documents, produced mechanically in the first week, is a more honest map of integration risk than anything in the data room's index, and the operator's corporate-development team now asks for it by name.

9Managed Simulation Artifacts

The third pillar is the least glamorous and was, by the operator's accounting, the most immediately felt: an organized artifact store for simulation inputs and results, indexed by record version and study.

The before-state deserves honest description because it is ubiquitous: results scattered across personal drives and email threads; filenames as version control (final_v3_ACTUAL_winter.xlsx); the same case re-run by two engineers in the same month because neither could find, or trust, the other's output; and presentation decks quoting numbers from runs whose inputs no one could reconstruct.

Under managed artifacts, every run's inputs, record version, solver settings, and outputs are stored together and indexed. The operating rules are simple: a result without provenance does not get quoted, and a case that already ran does not get re-run, it gets retrieved. The don't duplicate results pillar is mostly this store plus the discipline it enables. The artifact store also closed the loop with the operator's existing deep simulators: where a study runs in an external industry-standard tool, the record generates the input deck, and the tool's output files are captured back into the same index, so even the work done outside the platform stops evaporating.

10Reconciling Between Systems

A model built once from clean extraction would still decay; Section 2 argued staleness is an equilibrium, not an accident. The pillar that changes the equilibrium is continuous reconciliation: the Golden Record is permanently compared against the systems around it.

• Against GIS. Topology and attributes are re-checked as GIS edits land. A new segment in GIS that the record lacks, or a diameter edit that contradicts an alignment sheet, raises a drift flag with both sources cited.
• Against documents. New MOCs, revised drawings, and as-built packages enter the extraction pipeline on arrival; the record is re-proposed where they touch it. The model cannot go six months stale, because the staleness mechanism (documents accumulating unread) now feeds the model instead of starving it.
• Against operating data. Simulated and measured pressures are compared on a schedule. Persistent disagreement on a segment is itself a signal: a calibration drifting, a record error, or something in the ground that is not in any drawing. Each lands in a queue as a work item with evidence attached.

Disagreements auto-resolve where one source is authoritative by policy and the change is below materiality; everything else is flagged to an engineer, with the same propose-verify contract as extraction. And where the record proves the source system wrong (the GIS segment that was never as-built), the correction flows back to the source, so the next consumer of GIS inherits the fix. Reconciliation is bidirectional, which is what distinguishes a data layer from another data silo.

The cultural effect at the operator surprised them: the drift queue became the engineering team's equivalent of the operations morning meeting, a short, evidence-based review of where reality and records disagree. Several finds that began as drift flags (a mis-recorded wall thickness on a segment near a contractual delivery point being the example the team retells) would previously have surfaced, if at all, during an incident review or an audit.

11What Changed for the Operator

The operator has approved two quantitative claims for publication, and they are the two that matter.

Model builds: from weeks of manual effort to minutes of verification. The headline claim requires precise statement. What took weeks was the manual build-and-calibrate cycle of Section 2. What takes minutes today is the engineer-facing work of producing a current, runnable model for a study: the record is already current (reconciliation), the model is generated (no transcription), and the residual minutes are verification and case setup. Those weeks did not move to a different desk; the transcription and reconciliation labor was eliminated by extraction and by the fact that the substrate never goes stale. The study that waited six weeks in the opening anecdote is, under the new operating model, an afternoon, with the constraint now being engineering thought rather than data relocation.

Scale: 2,000-plus miles of pipeline modeled. The Golden Record at this deployment covers more than 2,000 miles of gathering and transmission assets, stated at the reconciled model-inventory mileage and built from the operator's existing document set and GIS rather than from a new survey program. The number matters as an existence proof: document-driven model building is not a pilot-scale trick; it carries a system the size of a real midstream operation.

The qualitative changes the operator reports are consistent with both numbers and, in their telling, matter as much. Commercial questions get hydraulic answers inside the deal window. Acquisition diligence runs against extracted, cited models instead of data rooms. The study backlog stopped being rationed by who could afford a rebuild. New engineers become productive against the record and its history rather than against tribal memory, which, given the demographics of the senior modeling cohort, was a primary motivation all along. And the engineering team's relationship with its deep simulation tools improved rather than ended: the tools run more studies than before, because feeding them stopped costing weeks.

The standard caveat applies and is worth stating plainly: these are one operator's outcomes, from one document set, one GIS posture, and one team's operating discipline. A different operator's mileage will differ with the quality of its records and its willingness to run the verify-not-transcribe contract honestly. What transfers is the architecture and the cost structure: extraction plus reconciliation makes staying current cheap, and version control makes study work accumulate, and those two properties, not any single number, are the case for the approach.

12The Operating Model for the Engineering Team

The technology stack of Sections 5 to 10 came with an operating contract, and the operator credits the contract for the adoption sticking where prior initiatives had not.

Agents are assistants with boundaries. Every agent action is bounded (extraction proposes, never commits; reconciliation flags above materiality, never silently rewrites), traceable (output cites its source document or tag), and reviewable (an engineer accepts or corrects). The team's trust in the record grew from auditing the citations, in exactly the way trust in a junior engineer grows from checking their early work.

The engineer's time moves up the stack. The hours that left transcription went to analysis, calibration judgment, and review. The team did not shrink; its throughput grew into the study backlog that had been silently rationed for years. Engineering leaders evaluating this approach should expect the constraint to move, visibly, from data preparation to engineering capacity, and should plan for the better problem.

Deep tools stay for deep work. The operator continues to run industry-standard simulators for the analyses that demand them. The platform's job is to feed them current, verified inputs and to capture their outputs into the managed store. The decision the operator made was not to replace the simulator; it was to stop hand-feeding it.

Review is the safety system. The same posture the industry applies to field automation applies here: confidence is expressed honestly, low-confidence extractions route to a human, and nothing bypasses review into the record. A model that feeds commercial commitments and regulatory filings earns trust through provenance, not through assertion.

13The Compliance Dividend

Nothing in the operator's program was designed primarily for the regulator, and that is precisely why the compliance effect is worth a section: it arrived as a by-product of an engineering discipline, which is the only way compliance effects reliably arrive.

The records expectations that govern this asset class, PHMSA's traceable, verifiable, and complete standard for the records behind MAOP and related determinations (PHMSA, 2012), describe properties a document pile does not have and a Golden Record has by construction. Every value in the record carries its source citation (traceable). Every value can be followed to a document image or a system of record and checked (verifiable). Coverage gaps are visible as empty typed fields rather than as silence (complete, or honestly incomplete, which is the prerequisite for becoming complete).

The operating consequences at the deployment:

• The audit posture inverted. Records requests that formerly launched document hunts became queries. The segment's MAOP basis, the supporting documents, and the change history come back together, because they were never stored apart.
• MOC stopped being a parallel universe. Because new MOCs flow through extraction into the record, the management-of-change file and the engineering model can no longer quietly diverge. The MOC that re-rated a segment is linked to the segment it re-rated.
• The engineer and the auditor read the same record. There is no separate compliance copy of reality to maintain, and no reconciliation project before an audit, because reconciliation is not a project; it is the system's resting state.

A caution, to keep the claim honest: a data discipline does not discharge a compliance program, and nothing here substitutes for the operator's regulatory counsel and integrity-management processes. The claim is narrower and operational: the same provenance and versioning that make a hydraulic model trustworthy for engineering happen to be the properties regulators keep asking the industry's records to have, and building them once, for engineering reasons, means not building them twice.

14An Adoption Path for Engineering Leaders

The operator's rollout, reconstructed with the benefit of hindsight, suggests a path other teams can follow without heroics:

1. Pick one system and one question. A single gathering subsystem with a live commercial or capacity question makes the value test honest. Avoid starting with the whole asset base; the record earns expansion.
2. Ingest read-only. GIS, the document set, and historian tags flow in without touching any system of record. The first deliverable is the extracted, cited draft record and its disagreement list, which is itself usually a revelation about the document set.
3. Run the verification sprint. Engineers work the review queue. This is where the team learns the verify-not-transcribe rhythm and where the extraction learns the team's drawing conventions.
4. Answer the question. Run the live study against the verified record, in the platform or by generating the deck for the incumbent simulator. Compare the elapsed time against the team's last manual equivalent; this becomes the internal benchmark.
5. Turn on reconciliation, then expand. Drift detection runs on the pilot system while the next system ingests. Studies begin accumulating in version control from day one, so the compounding starts with the pilot.

The measurement frame is four numbers an engineering leader already understands: study turnaround (request to defensible answer), model freshness (age of the model behind the latest study), engineer-hours per study (the labor content, separated from elapsed time), and drift backlog (open disagreements between record and sources, which should trend toward a small, actively worked queue). The operator's experience is that the first number moves within the pilot, the second moves the day reconciliation turns on, and the third is the one the CFO eventually asks about.

15Conclusion

The operator in this story did not buy a better simulator, and did not run a data project. They changed the cost structure of knowing their own system: documents they already possessed became a structured, versioned, cited record; the record became the single substrate for every model and every study; studies became durable, diffable objects instead of files on laptops; and reconciliation made staying current the default instead of the exception. Agents did the reading and the typing, within boundaries, with citations; engineers did the judging, which is the work they were hired for.

The result is the headline: a build cycle that consumed weeks of an engineer's attention compressed to minutes of verification, across 2,000-plus miles of pipeline modeled, reported at this deployment. But the durable change is quieter and shows up in sentences the operator's engineers now say without noticing: the model is current. The study from March is right here, with its reasoning. The drawing disagrees with GIS, and the queue caught it. For an engineering organization, that is what it means to stop rebuilding models and start maintaining one, and it is available to any operator whose filing cabinets are full of documents that already know the answer.

Appendix A The Golden Record Schema, One Level Deeper

Table 4 expands the three domains of Table 2 to the level of detail at which engineering leaders usually want to pressure-test the idea. The schema shown is representative rather than exhaustive; the structural point is that every entity is typed, every field is provenance-bearing, and every change is versioned.

Appendix B Questions Engineering Leaders Ask First

The following are the questions the operator's leadership asked before committing, with the answers as they stand after deployment.

Our documents are a mess. Does this work on bad document sets? The document set in this story included scanned scans, superseded revisions filed next to current ones, and drawings annotated by hand. Extraction quality degrades with document quality, which is why the architecture routes everything through engineer verification with confidence flags rather than committing silently. The honest statement: a bad document set slows the verification sprint; it does not change the architecture, and the extraction-plus-reconciliation pass is, in practice, the first complete inventory of how bad (or good) the document set actually is.

Do we have to abandon our existing simulators? No, and the operator did not. The record generates inputs for the industry-standard tools the team already licenses and trusts, and their outputs are captured back into the managed artifact store. Consolidation onto fewer tools is a choice some teams make later, for their own reasons; it is not a precondition.

What keeps an agent from quietly corrupting the record? The commit boundary. Agents propose; only an engineer's acceptance changes the record; every change is versioned with its author, basis, and citation; and any change can be inspected and reverted. The failure mode of a wrong extraction is a flagged, attributable, reversible entry, which compares favorably with the failure mode of a wrong manual transcription: silent, unattributed, and discovered during an emergency.

Who owns the record, engineering or GIS? Both, with the reconciliation queue as the working boundary. GIS remains the system of record for what GIS is the system of record for; the Golden Record is the engineering substrate that consumes it, checks it, and returns corrections. The operator's experience is that the relationship between the two teams improved, because disagreements became shared work items with evidence instead of inter-departmental folklore.

Where does this start, and how do we know in 90 days whether it is working? Start with one subsystem and one live question (Section 14), and watch four numbers: study turnaround, model freshness, engineer-hours per study, and the drift backlog. If study turnaround on the pilot system has not moved by the end of the first verification-and-study cycle, the approach is not working for your document set, and you will know cheaply, which is itself a feature of starting at the data layer rather than with a platform program.