Frac Stage Data Software: Why Designed Versus Pumped Still Takes a Week Per Well

Why completions data breaks the moment a second pumping contractor shows up

You have a four well pad, sixty stages each, and two pressure pumping companies across the program because one fleet was released mid campaign and another picked up the back half. Your completions engineer wants one thing: for each stage, the designed proppant and fluid against what actually went downhole, at what rate, with the treating pressure signature attached. That question should take ten minutes. It takes a week, because the data left location as a folder of files written by whatever acquisition system happened to be in the van that month.

The files are not the same and never will be. One contractor exports one second data with headers like TP, SLURRY_RATE and PROP_CONC. Another writes the same physical measurements as PRESS1, RATE_TOT and PPA, in different units, with stage boundaries defined in a separate job summary rather than in the time series itself. A third hands over a proprietary job file plus a stage report as a PDF. So the engineer opens them in Excel, guesses at the channel mapping, trims pump on and pump off by eye, sums the proppant, and types the number into the completions tracking workbook. Sixty stages, four wells, one week of an engineer who was hired to design completions. Then the next pad lands.

The cost of this is not the week. It is that nobody ever goes back. Once the summary is typed, the one second data is archived on a network drive and never opened again. So when production comes in low on wells 2 and 3, the diagnostic conversation is conducted from memory and from the daily reports, not from the pressure signatures that would actually show you the two stages that screened out and the four that never broke down properly.

Problem 1: normalizing the van file is the whole job, and it never ends

Every operator who tries this in house builds a parser for the current contractor, then discovers that the contractor changed acquisition software versions between pads and the header row moved. The parser is a maintenance obligation, not a one off script. A serious ingestion layer treats the channel mapping as data rather than code: a registry that says for this contractor, this acquisition system, this version, the channel called PRESS1 is treating pressure in psi, and the channel called RATE_TOT is slurry rate in barrels per minute. New file arrives, the system matches it to a known signature, and if it cannot, it quarantines the file and asks a human to map three channels rather than failing silently or, worse, ingesting kilopascals as psi.

Stage segmentation is the second half of the problem and it is the part people underestimate. The van file is a continuous record across the whole day including wireline runs, pressure tests and the pumpdown. Splitting it into stages by hand is what eats the week. It can be detected reliably from rate and pressure behaviour plus the perforation and plug events, but the detection rules have to be tuned to how your crews actually operate, including simul frac and zipper operations where two wells are being treated in an interleaved pattern and one file covers both.

Problem 2: designed versus pumped is the entire question, and it should be a chart not a project

Your frac design is a stage sheet: pounds of proppant per stage by mesh size, barrels of fluid, target rate, diverter drops, acid volume. Your actual is in the van file. The comparison is the single most valuable output in completions and almost nobody has it running automatically across a program.

What a proper build produces per stage, computed rather than typed:

• Proppant placed against proppant designed, by mesh, with the flush volume excluded correctly
• Clean and slurry volumes against design, and the fluid system actually used
• Average and maximum treating pressure, breakdown pressure, instantaneous shut in pressure and the calculated gradient
• Achieved rate against target, and the time spent below target rate
• Screenout and near screenout flags with the pressure signature that triggered them, so the engineer can confirm or reject the call
• Stage duration and non productive time between stages, which is where fleet efficiency actually lives

Once that runs automatically, the useful comparisons open up. Stage level results across pads, across contractors, across fluid systems. A well where 12 of 60 stages placed under 80 percent of design is a different well than the daily reports described. That is the finding that changes the next design, and it is invisible when the summary is a typed number.

Problem 3: the stage record does not connect to cost, chemistry or the offset wells

Three joins matter and all three are missing in the spreadsheet world. First, cost. Completion spend dominates well cost, and the pumping invoice is billed by stage, by pump hour, by pounds of sand and by chemical volume. If the stage record and the field ticket never meet, you are approving invoices against a daily report rather than against the measured job. Second, chemistry. You file chemical disclosure to FracFocus per well, and the numbers on that filing should be derivable from the same rate and concentration channels that produced the stage summary, not assembled separately from contractor paperwork weeks later. Third, offset wells. If you are monitoring parent well pressure during a child completion, those gauges produce a separate time series that only means something when it is aligned to the stage clock. Doing that alignment by hand across a pad is a research project each time. Doing it automatically turns frac hit response into an operational report.

What Corva, Well Data Labs and Petro.ai actually do, and where they stop

Be fair about these before you decide to build. Well Data Labs is genuinely built for exactly this problem and is good at it: they take the messy van files, normalize and segment them, and give completions engineers stage level analytics. If your requirement is stage data processing and analysis and nothing else, they are the honest first call and you should try them before you spend a dollar on a build. Corva is strongest as a real time operations platform with an app framework, so it shines while the job is pumping and while a drilling rig is turning to the right. Petro.ai positions as a data and analytics layer across the well lifecycle.

Where all three stop is the same place: they are their platform, with their data model, and your questions eventually run past the edge of it. The joins in the previous section are the usual trigger. Your AFE and field ticket data lives in your accounting system. Your offset gauge data comes from a different service company. Your design of record lives in a simulator or a stage sheet template that is yours. Your production data lives in your production accounting system. When the analysis you want requires four of your own systems plus the stage data, you are either exporting from the vendor platform into a warehouse anyway, or you are asking the vendor to build your integration on their roadmap. Operators with large stage counts and their own data teams usually reach the point where owning the pipeline is cheaper and faster than renting the front end.

What a custom completions data build has to include

Order matters here. The pipeline first, the interface second, because the interface is easy and the pipeline is where projects die.

• A file intake that accepts whatever the contractor drops, including SFTP delivery, a shared bucket and a manual upload, with a contractor and version aware channel mapping registry
• Unit normalization at ingest with an explicit unit on every stored channel, so a kilopascal file can never quietly become a psi record
• Automatic stage segmentation with human review on anything the rules are unsure about, and full support for zipper and simul operations
• A design of record object per well and per stage that is versioned, so a redesign mid pad does not silently overwrite what was intended for the first two wells
• A computed stage summary layer, recalculated on demand, never typed
• Time aligned offset well pressure and any microseismic or fiber data you acquire, keyed to the same stage clock
• Chemical disclosure assembly from the measured concentration channels and the supplier product sheets
• An export path that puts stage level results into whatever your reservoir and production teams already use, because the value compounds when completions data meets production data

One honest note on artificial intelligence here. The useful application is not a chatbot over your well files. It is classification: pattern recognition on the pressure signature to flag screenouts, poor breakdowns and diverter response, trained on the calls your own engineers made on historic stages. That is a real model doing a real job, and it works because you have thousands of labelled stages sitting in the archive nobody has opened.

What this costs and how long it takes

From Digital Heroes delivery experience on data pipeline and industrial analytics projects of this shape, a first release covering multi contractor ingestion, normalization, segmentation and designed versus pumped reporting runs $70,000 to $150,000 and ships in 12 to 18 weeks. The full platform, adding cost reconciliation, chemical disclosure, offset pressure alignment, a real time feed and the classification models, runs $180,000 to $450,000 phased across 6 to 12 months.

What moves the number up: the count of distinct pumping contractors and acquisition systems in your history, because each one is a mapping and a test set. Historical backfill, if you want ten years of archived pads loaded and not just new work. Real time streaming from the van, which is a different engineering problem than batch file ingestion and needs a connectivity plan for pads with poor coverage. Fiber optic sensing data, which is large enough to change your storage architecture. What keeps it down: starting with your current active contractor, your last two years of pads, and the single question of designed versus pumped.

When you should not build this

If you pump under about 200 stages a year with one contractor and one fleet, do not build. Buy the vendor product, spend the savings on the completion itself. If your real complaint is that reporting is slow rather than that the underlying data is unusable, you have a dashboard problem and a two week engagement will fix it. And if you do not have a design of record in a structured form, meaning your stage sheets live as PDFs with handwritten changes, fix that first, because designed versus pumped requires a designed and you do not have one yet.

How to choose a developer for completions data work

Ask them to describe how they would handle a file from a contractor they have never seen. If the answer does not include quarantining unknown signatures and asking a human to map channels, they are going to write a brittle parser and hand you a maintenance liability.

Ask what they will do about units. The correct answer is that units are stored per channel and conversions happen at read time, never a silent assumption at ingest. This one question separates people who have done industrial time series work from people who have not.

Ask how they will validate stage segmentation. There should be a labelled test set of stages your engineers have already reviewed, and the segmentation should be measured against it before anyone trusts a summary number.

Ask who owns the code, the cloud accounts and the data. You should own all three from the first commit, with the right to hire anyone else to continue the work. Get it in writing before kickoff, not in the final contract review. A good next step is to pull three job folders from three different contractors and send them to whoever you are evaluating: the quality of the questions they come back with tells you more than any proposal.