LDAR doesn't fail at detection. It fails at proof.

LDAR programs fail in the gap between a detection and a documented repair. SensorUp turns OGI, continuous monitor, and satellite findings into owned work.

Two field technicians running an optical gas imaging camera survey at a gas facility, inspecting components for leaks.

The problem

The leak you found is not the repair you can prove

Your detection layer mostly works: cameras survey, monitors alarm, satellites flag. What breaks is everything after the finding, and that is the part an OOOOa/b/c auditor reads.

[ 01 ] Failure mode 01

Detections die in inboxes

A finding becomes an email, then a row, owned by no one.

A camera operator's finding becomes an email, the email becomes a spreadsheet row, and ownership never lands on anyone. The leak may even get fixed, but months later, nobody can show who was assigned, when they acted, or against which finding.

[ 02 ] Failure mode 02

Your detection sources disagree

Three findings, possibly one leak, chased as if new.

The OGI survey says one thing, the continuous monitor says another, and a satellite flags the same pad days later. Three findings, possibly one leak, and without a reconciled record, your team chases each signal as if it were new.

[ 03 ] Failure mode 03

Closure you can't defend

An undocumented repair reads as a violation either way.

The repair happened; the documentation is a text message and a technician's memory. Under regulatory scrutiny, an undocumented repair is indistinguishable from an unrepaired leak, the gap reads as a violation either way.

It reads the detection sources you already run

[ 01 ] Detection sources

OGI, continuous, and satellite land as records, not attachments

Every survey, alarm, and pass becomes an observation linked to its asset.

OGI cameras (FLIR, Opgal), continuous monitors (Project Canary, Qube, LongPath), and satellite (GHGSat, MethaneSAT, Planet) all ingest as observations linked to the asset they observed. A continuous alarm, a quarterly survey, and a satellite pass become comparable records, not parallel portals and PDFs nobody can action.

consume: OGI, monitors, satellite → Observations
[ 02 ] SCADA context

Operational state separates the leak from the vent

A detection is cross-referenced against state before a work order.

The Warehouse reads your SCADA historians (PI, CygNet) over OPC-UA and Modbus, so a detection is cross-referenced against pressure, flow, and valve state before it becomes a work order. A scheduled vent should never dispatch a truck. Ingress is pull-shaped, so nothing new lands on the OT segment.

consume: PI, CygNet ← OPC-UA / Modbus
[ 03 ] Frameworks

The LDAR frameworks live in the Library

OOOOa/b/c and the Appendix K protocol, with emission factors, as Library content.

The methodologies your program answers to, OOOOa/b/c and the Appendix K imaging protocol, and the emission factors behind them, are Reference Library content: versioned, inspectable, and applied the same way every survey cycle.

A finding becomes owned work with documented closure

[ 01 ] Catch

Find the real leak in the noise

Every source lands in one record, so the real leak stands out from the duplicates.

Every reading, OGI, continuous, satellite, SCADA, lands as an observation linked to the asset it observed. When sources disagree about the same pad, the disagreement is visible in one record with provenance, not scattered across inboxes.

[ 02 ] Prioritize

See what actually affects your operations

A confirmed finding becomes a tracked event, ranked against your operating plan.

A confirmed finding opens an emission event, related to its asset and carrying its detection history, ranked against your operating plan so the leaks that actually affect operations rise first. It is tracked from open through verification to closure, the thing the auditor follows, and it cannot quietly disappear into a thread.

[ 03 ] Resolve

Send it to the right team, and close it out

Dispatched as owned work with escalation, closed with documentation an auditor accepts.

LDAR survey sequences, repair orders, inspection checklists, and escalation paths, composed as workflows and dispatched as owned tasks: an AVO check, an OGI re-survey, or a vent, flare, or blowdown report. The workflows map to OOOOa/b/c and the Appendix K imaging protocol. If a repair stalls, the escalation path fires; if it completes, the closure documentation is attached where the event lives.

Every LDAR is composed from the same blocks

LDAR is not written from scratch. It is assembled in Studio from blocks that already exist, watched by Autopilot and standing on the Warehouse beneath it. Change the composition, and you change the solution. The same blocks compose the EPA Subpart W filing your LDAR records feed, and every other entry in the catalog.

[ 01 ] Studio COMPOSE
  • Events
  • Work
  • Calculations
  • Compliance
  • Scenarios
  • Metrics
  • Reports
[ 02 ] Autopilot AUTOMATE
  • Agents
  • Cora
  • Solution Builder
  • Workflows
[ 03 ] Warehouse FOUNDATION
  • Assets
  • Integrations
  • Datasets
  • Relationships
  • Reference Library
  • Ledgers
  • Approvals
LDAR draws Events, Work, and Calculations from Studio, the Agents and Cora that watch it from Autopilot, and Assets, Integrations, and Datasets from the Warehouse. The blocks are shared across every solution; only the composition changes.

See a survey finding become a closed, audit-ready repair

An OGI or continuous detection lands on the equipment under it, gets prioritized against the operating plan, and resolves to a work order whose closure an auditor can trace.

app.sensorup.com/ldar
SensorUp product screen: a filtered list of LDAR detections across sites
A frame from the product interface.
$sensorup ldar --from detection --to documented-closure

Talk to an engineer

Bring your survey schedule and your detection stack. We'll walk sources, work dispatch, and the audit trail against what you actually run.

SecurityTrust ↗