LDAR and Methane Compliance Software: Proving the Repair Happened in Time

Why the repair clock is the whole compliance problem

An optical gas imaging crew walks a tank battery on a Tuesday. The camera shows a plume off a thief hatch. The technician records it, the crew moves on, and the finding lands in the contractor's deliverable, which arrives as a PDF report plus a folder of video clips eleven days later. By then the repair may or may not have been done, by a different contractor, whose record is a line on a field ticket.

The regulation does not care about your contracting arrangements. It gives you a small number of days to make a first repair attempt, a short window to complete the repair, and a requirement to verify it with a follow up survey. Every one of those steps has to be evidenced. When an inspector or an auditor asks you to demonstrate that a specific leak found on a specific component was repaired inside the window, you need a record with dates, a technician, a verification result and the clip that started it. What most operators can produce is a PDF, an email chain and a field ticket that says repaired hatch.

Multiply by the component count. A mid size upstream operator with a few hundred sites is carrying tens of thousands of monitored components, and once compressors and larger facilities are included the number climbs fast. At that scale, compliance is a data problem wearing a field operations costume.

Problem 1: nobody owns the component register

Ask an operator for a current, authoritative list of monitored components by site and you usually get one of three answers: the survey contractor has it, it is in a spreadsheet from the last audit, or it is derived each time from the site drawings. All three mean the register belongs to somebody else or to nobody.

That single gap causes most of the downstream mess. If you do not own the register, you cannot compute survey coverage yourself, so you cannot know that four sites were missed in a quarter until the contractor's summary tells you. You cannot mark components as difficult or unsafe to monitor with a documented basis. You cannot attribute a detection to a component, because the detection references the contractor's tag scheme and you have no map to it. And when you change survey contractors, which operators do regularly, the register walks out the door with the old one.

The register is the first thing a build creates and it is not glamorous work. Site, equipment, component, tag, type, service, monitoring designation, applicable rule basis, and the survey history attached to each one. Everything else in the system hangs from it.

Problem 2: three detection technologies produce three incompatible truths

You now have detections coming from at least three directions and they do not describe the same thing.

• Optical gas imaging crews produce component level findings with a video clip, which is the only source that tells you which valve or hatch is leaking
• Continuous monitors installed at a pad produce a concentration time series with a wind derived source bearing, which tells you something is emitting on that pad and roughly where, but not which component
• Aerial and satellite screening produces a geolocated plume with an estimated emission rate, which tells you a site is emitting on a given day at a scale worth investigating and nothing more

These have to reconcile against one register or they generate three separate work queues that duplicate each other. The reconciliation logic is genuinely operator specific: how close a plume centroid has to be to a site boundary to attribute it, how a continuous monitor alert converts into a survey task, what happens when an aerial detection arrives for a site that an imaging crew walked clean two days earlier. There is no packaged answer to those questions because they depend on your site density, your terrain and your monitoring mix.

The critical design decision is that unattributed is a legitimate state. A detection that cannot be tied to a component should sit in a queue with an investigation task, not be forced onto the nearest tag so the record looks tidy. Forced attribution is how a register becomes fiction.

Problem 3: the repair record lives with whoever did the repair

Leak found by contractor A. Repair scheduled by your operations group. Repair executed by contractor B or by a lease operator. Verification survey by contractor A again on their next rotation, which may be a month out. Four handoffs, four systems, one clock.

What a build has to do is make the leak the object that moves, not the paperwork. A detection creates a repair task with a due date computed from the rule that applies to that site. The task carries the evidence forward: the original clip or reading, the tag, the site, the technician who found it. First attempt, parts on order, delay of repair with its justification when a shutdown is genuinely required, completion, and then a verification survey scheduled automatically rather than waiting for the next routine rotation. Every state change is timestamped with a person attached.

Two design details matter more than they sound. Field capture must work offline, because the sites where this happens do not have signal and a technician will not walk back to the truck to sync. And evidence has to be captured at the point of work: geotagged photo of the tag, the reading, the clip reference. Evidence assembled afterwards from memory is what turns a compliance question into a compliance finding.

Problem 4: quantification and reporting are still a separate spreadsheet

Separately from the leak workflow, you report emissions. Greenhouse gas reporting under Subpart W has its own methods and its own equipment counts, and in most companies it is produced annually by an environmental analyst pulling equipment counts, survey results and operating data into a workbook.

The source data is the same register and the same detections. If the register is authoritative and the detections are structured, the reporting roll up becomes a report rather than a project, and more usefully it becomes something you can run mid year to see where you are trending. That matters because emissions based fee exposure has been the subject of both rulemaking and legislative challenge, so what you want is a model you can run under different scenarios rather than a single number computed once a year. Confirm the current state of any fee obligation with counsel, and build the model so the rate and the applicability are configuration rather than code.

What LDARtools, Project Canary and Highwood actually cover

LDARtools is strong in the instrument based, tag and monitor world that grew up around refineries and chemical plants, with hardware and software built around portable analyser workflows. That heritage is exactly why it fits awkwardly on upstream and midstream estates where imaging crews, continuous monitors and aerial screening all feed the same programme across hundreds of remote sites.

Project Canary does continuous monitoring properly and their platform presents their own sensor data well. The limitation is structural rather than a criticism of quality: it is a vendor platform anchored to their measurement product, and what you need is an operator owned register that can absorb their alerts alongside a third party imaging contractor's findings and an aerial provider's detections without any of them being privileged. Highwood Emissions Management is genuinely expert on measurement programme design and alternative technology evaluation, and they are worth engaging, but advisory work does not become your transactional repair system of record.

What a custom LDAR build must include

• An operator owned site and component register with tag hierarchy, monitoring designations and the applicable rule basis per site
• Survey planning and coverage tracking that computes what is due and what was missed, per site, without waiting for a contractor summary
• Detection intake from imaging deliverables, instrument readings, continuous monitor APIs and aerial or satellite providers, each retaining its native evidence
• A reconciliation engine that attributes detections to site, equipment and component where possible and treats unattributed as a tracked state with an investigation task
• A repair workflow with rule derived clocks, first attempt and completion states, delay of repair justification, and automatic scheduling of the verification survey
• Offline capable mobile capture with geotagged evidence, technician identity and timestamps
• Report generation for the periodic reports your rule set requires plus inputs to greenhouse gas reporting
• A configurable emissions and fee exposure model that can be run as scenarios rather than a hardcoded calculation

What this costs and how long it takes

From Digital Heroes delivery experience on field compliance and evidence systems, a first release covering the register, survey coverage, the repair workflow with clocks and offline field capture runs $70,000 to $150,000 across 12 to 18 weeks. The full platform adding multi technology detection reconciliation, quantification roll up, fee scenarios and work management integration runs $180,000 to $400,000 phased over 6 to 12 months.

Cost drivers specific to this category: the number of distinct rule sets you sit under, because federal requirements, state plans and any approved alternative programme each define different frequencies and deadlines. Component count, which changes how you think about mobile performance and sync. Integration with continuous monitor and aerial vendors, each of which has its own feed and its own idea of what a detection is. And integration with an existing work management system such as Maximo or SAP if repairs must be executed as work orders there rather than in your new tool. Building the initial register through field verification is a services cost, not a software one, and it is often the largest line.

When you should not build

A small operator with a few dozen well sites, one survey contractor and no continuous monitoring does not need this. The contractor portal plus a consultant who knows the rule is proportionate, and you should spend the money on the repairs. Equally, if you have no component register at all, understand that step one is a field data collection project and no amount of software shortens it. Get the register built, even in a spreadsheet, then automate what you can see.

How to choose a developer for emissions compliance systems

Ask how they will handle a detection that cannot be attributed to a component. If the answer forces it onto the nearest tag, walk away, because that design quietly corrupts the register you are paying to build.

Ask how the repair deadline is computed. It should derive from the rule basis attached to the site, held as configuration with effective dates, so that when a rule or a state plan changes you reconfigure rather than redeploy. Hardcoded day counts are a guarantee of rework.

Ask what happens in the field with no signal for six hours. Offline capture with conflict safe sync is a requirement here, not a nice to have, and a developer who has only built connected web apps will discover this the hard way on your budget.

Ask who owns the code, the cloud accounts and the register data, in writing before kickoff. At Digital Heroes the client owns the code from the first commit. A practical next step: export one quarter of survey findings and repair records from your current contractors and ask whoever you are evaluating to reconcile them into a single component level history. Whoever can do that has understood the problem.