Other Platforms Show You the Data, Store It, and File It Away. None of Them Do the Work.

Augusto Borella Hougaz
July 6th 2026
5 min read
Pattern

The first thing I do when I'm in a room with a prospect who already has one of these platforms running is agree with them. These are good products, and pretending otherwise is the fastest way to lose that room. Some of these vendors run the app store of drilling and completions: well over a hundred pre-built apps, strong dashboards, a mobile-first experience drilling teams genuinely like. Others are serious industrial DataOps platforms, unifying operational, IT, and engineering data into a contextualized knowledge graph. Still others are the historian: a trusted data infrastructure backbone with asset modeling for context and a visualization layer built on top of it. All of that is true.

Notice, too, that these are three different kinds of product, not one category with several vendors fighting for the same job: an app store, a data foundation, a historian. What they share is where they stop. A dashboard ends at visualization. A data foundation ends at contextualized, queryable data. A historian ends at the archive. And after the platform shows you the data, stores it, or contextualizes it, someone still has to do the work. The daily drilling report still gets typed by a person. The post-stage report still gets assembled by a person, at two in the morning. The invoice still gets reconciled by a person, after the fact. Every vendor that stops at data or visualization stops one step before the deliverable, and that last step is exactly where the hours, the errors, and the disputes live.

A Company Man's Morning, Before and After

Before Intelie, the company man is up before five. The night shift left notes. The drilling contractor has its own report. The mud engineer and the directional hand each have theirs. His tally book has a third version of the same numbers. His morning goes to reconciling those sources and retyping the result into the daily drilling report, the DDR, activity by activity, code by code, under IADC conventions. Depths that don't match get chased down by phone or by walking the rig floor. Then comes the morning call, where he defends numbers he assembled under pressure an hour earlier.

That's two to three hours a day of transcription and reconciliation, done by one of the most expensive and most experienced people on location, every single day. It carries a second cost nobody puts on a slide: manual reports mask events. Compress twenty-four hours of operations into typed lines before dawn and the details that matter get flattened into standard phrases.

Now, when he sits down the DDR already exists. Auto DDR generated it overnight from the operational data itself, structured to the IADC standard, using live rig data, detected rig states, and, where deployed, AI video detection as inputs. This has been achieved in a pilot run with a national oil company. His job changes from author to reviewer: he reads a finished draft, corrects what needs correcting, adds the context only a human on location knows, and approves it. Every change is tracked and versioned, so the report shows both what the data said and what he decided.

The morning call changes with it. Nobody argues about whose number is right, because there's one number with its lineage attached. The conversation moves to the operation itself: what happened, what it means, what to do next. That's what workflow-first means on a rig: the deliverable produces itself, and the human moves up one level, from typing to judgment.

Where the Two to Three Hours Actually Went

The company man owns the DDR, but he's really the integrator of half a dozen inputs: the driller's log, the contractor's daily report, the mud report, the directional report, service company tickets. Each arrives in its own format, on its own clock, with its own version of depth and time. The work was touching all of them, real-time traces on one screen, a contractor PDF on another, a spreadsheet on a third, a paper tally book, and merging them by hand into one coherent narrative of the last twenty-four hours.

The time went to three places. Transcription: retyping values that already existed digitally somewhere else. Classification: breaking the day into activity codes, deciding when tripping ended and circulating began, which is exactly the kind of judgment a rig-state engine now makes consistently. Reconciliation: hunting down why two sources disagree, which was pure waste and the single biggest consumer of the morning.

Nobody tracked this as a problem. It was invisible cost, absorbed as just how reporting works, priced into every day rate on every rig for decades. It only became visible as a number, two to three hours a day per company man, when it disappeared. Mechanically, Auto DDR inverts the flow: generation is scheduled, the system consumes operational data through the platform's MCP tools, applies the rig-state and event detection already running in Live, uses a language model to produce a human-readable report to the IADC standard, and hands it to the engineer to validate and enhance. The two-to-three-hour figure comes from that pilot, and it recurs because the before state is remarkably uniform across the industry.

Governance Embedded, Not Bolted On

Embedded means the approval step is a first-class object in the same platform that holds the data, not an email with a PDF attached. A report or a KPI set moves through explicit states: generated, in review, approved, published. Each transition is role-based, timestamped, and attributed to a named person. Every edit is tracked and versioned, so the published artifact carries its full history. Behind every number in the draft is its lineage: one click takes a reviewer from the KPI to the sensor data that produced it, in the same environment, without switching between apps, windows, or browser tabs to chase context.

The contrast is the bolt-on approval loop most organizations actually run: generate a report, export it, email it, collect comments, paste them back in. The moment the artifact leaves the platform, governance ends and archaeology begins. Embedded means it never leaves.

The human avoids becoming the bottleneck because the system changes what the human reviews. The data arriving at the workflow has already passed QA and QC at the edge. KPIs are calculated automatically at better than ninety-five percent accuracy. Anomalies are flagged. The reviewer isn't assembling or verifying line by line. They're reviewing a finished draft by exception, and effort scales with the number of exceptions, not with the volume of operations.

The human in the loop isn't a tax on automation. It's the feature that makes automation deployable. The objection sophisticated buyers raise, who's accountable when the machine writes the report, is exactly right, and the answer is the same person who was always accountable, except now their name is attached to an approval on an audit trail rather than to a typed document nobody can reconstruct. Automation without an approval loop is what operators are right to fear.

The Same Pattern, One Domain Over

A frac pad runs dozens of stages per well, around the clock, and after every stage someone has to produce the record of it: stage start and end, pumping time versus flat and idle time, volumes, proppant and chemical totals, pressures, screenout events, non-productive time. Before, that meant a completions engineer or data van analyst assembling it from van data by hand, stage after stage, sometimes at two in the morning, with every crew doing it slightly differently. The post-stage record isn't just an operational document. It's the basis of what gets invoiced, on both sides. Every inconsistency between crews eventually becomes a billing conversation.

We automate the full chain: stage, flat, and idle time detection from sensor data; KPIs standardized across stages, wells, pads, and crews, so benchmarking finally means something; the post-stage report generating itself and entering the same embedded review-and-approval loop; the approved output feeding the SOC 1 Type 2 certified billing interface. This is in full production deployment with a major service company running roughly eighteen frac crews, and it cut the engineering resources consumed by this workflow by about thirty-five percent.

The point worth landing here is platform depth, not drilling. This is the same Live foundation, the same workflow engine, the same governance pattern as the DDR story, applied to a different domain. Workflow-first, edge sensors to action, isn't a drilling feature. It's how the platform approaches every deliverable, which is also why the next domain costs a fraction of the first.

What Full Auditability Actually Proves

SOC 2, which many software vendors hold, attests to security and availability controls. It answers whether your data is safe with a vendor. SOC 1 attests to controls relevant to a customer's financial reporting. It answers whether the numbers a system produces can flow into that customer's financial statements. Type 2 means an independent auditor tested that those controls operated effectively over a period of months, not that they looked well designed on a single day. Our Completions Analytics workflow runs from field sensors at the edge, through automated stage detection and KPI validation, through the embedded approval loop, into the billing interface that feeds third-party invoice generation, and it's SOC 1 Type 2 certified end to end.

The end user never asks for SOC 1. The controller, the auditors, and procurement do. For them, a vendor without it is a control risk they have to assess themselves, at their own cost, on their own audit calendar. A vendor with it is a report they can rely on, which in practice converts into shorter procurement cycles and a deal that survives legal and finance review instead of stalling there. Nobody SOC 1-certifies a dashboard. The certificate exists because the workflow is real.

What a client can actually see and prove after the fact is the complete lineage of every published number: the raw sensor stream it came from, the transformation and model that computed it, every human edit with before-and-after values, who made each edit, who approved the final artifact, and when. That matters most in a billing dispute, where money and relationships collide. An operator questions invoiced quantities or hours: historically that opens weeks of dueling spreadsheets, each side reconstructing its own version from its own records, ending in a negotiation. With the audit trail, both sides open the same record: the sensor-detected stage sequence, the automatically computed KPI, the named reviewer who adjusted one value and why, the approval and its timestamp. The dispute closes on evidence.

One Deployment, Measured

One client's edge-to-billing deployment replaced a field operation that ran on roughly twenty engineers making manual daily site visits, with all the cost, data inconsistency, and staff turnover that implies. Before, getting from a reading in the field to a correct invoice took six manual interactions: the site visit to collect readings, manual validation and cleanup of what was collected, a reconciliation call when numbers disagreed, assembly and submission of the daily report, the chase for sign-off, and the billing query cycle when the invoice didn't match the field record. Not one of those six is engineering. Each existed to compensate for the same root defect: data that couldn't be trusted at its source. When the measurement is manual, every downstream step needs a human to check, explain, or defend it, and the interactions multiply.

Moving trust to the source made all six unnecessary. Field sensors and edge devices capture and validate the data at the point of generation. The workflow carries it automatically through processing, reporting, and KPI approval into back-office billing. The embedded approval loop handles exceptions. The audit-ready record replaces the reconciliation conversation, because both sides look at the same lineage instead of comparing recollections. The interactions didn't get faster. They stopped needing to exist. Zero interactions doesn't mean zero people. The engineers came off windshield time and data babysitting and went back to engineering and optimization work, which is also the honest answer to the turnover problem the client started with.

The same deployment cut remote communications from around the clock to an estimated ninety minutes a day. What generated that volume before was simple: the humans were the telemetry. When the remote side couldn't see the operation directly, or couldn't trust what it saw, people narrated it over radio, phone, and chat: what stage, what count, did the pressure spike, has the report gone out, effectively around the clock, because operations run around the clock. Once stage detection announces the stage, state detection announces the state, the KPIs compute themselves, and the report files itself into the approval queue, the entire category of status-transfer communication disappears, because there's no longer any status one side knows that the other doesn't. What remains is the communication worth having: exceptions, judgment calls, decisions. In remote operations running on satellite links, cutting that channel from continuous to an estimated ninety minutes a day is a direct infrastructure saving on top of the labor one. The six-to-zero interaction figure is measured. The ninety-minutes figure is the deployment team's estimate, not an audited number. Both point the same direction: the mechanism is what's transferable, not the exact figures.

Defending the Number

A single big cost-reduction percentage invites disbelief, and it should. Decomposed, the case is four auditable line items: labor, the manual field-data workload eliminated and costed at fully loaded rates against the site count; communications, the estimated infrastructure saving from cutting a satellite-linked channel from continuous to roughly ninety minutes a day; rework, the billing corrections, re-issued invoices, and dispute handling that finance can pull from its own records; and working capital, the value of invoices that are faster and audit-ready moving cash forward. The labor line is the one that's actually measured, and it's the one this piece stands behind.

Each line rests on assumptions a CFO can check, and naming them is what buys credibility. The labor line uses fully loaded rates against the number of sites and crews in scope. The operation already had instrumentation at the edge, so this was a workflow deployment, not a greenfield sensor investment. And the engineering savings assume redeployment, not layoffs. On this deployment, the labor line alone, the direct reduction in engineering FTE cost from eliminating manual site visits, ran about thirty-five percent. Strip the model to that single conservative line, ignore communications, rework, and cash entirely, and the project still clears any reasonable hurdle rate. Everything else is upside. That's the number worth defending in a room: not a headline percentage, but a labor line a CFO can rebuild with their own inputs and still reach the same conclusion.

Intelie Live's workflow engine automates the deliverable itself, the DDR, the post-stage report, the invoice, with an embedded human review-and-approval loop and full auditability built in from the edge to the back office. To learn more, visit intelie.com.

More Than a Technology Provider

Intelie works alongside customers as a long-term innovation partner—helping organizations adapt and evolve as AI, automation, and industrial operations continue to advance.