Flare Attribution Ledger: Flare Event Attribution for Gas Plants

VERTICAL-DRIVEN ARCHITECTURES · OIL AND GAS

Flare Attribution Ledger

A system design for process engineering and flare management leads, environmental compliance officers, and the engineers who would build it. It shows how a gas plant can attribute every flaring event to its cause before the shift ends, separate planned depressurization from unplanned upset, and write one evidence record that serves every regulator at once.

THE CASE IN BRIEF

• Flaring is reported in totals, but it is managed event by event.
• When a flare stack begins to smoke, the evidence of its cause is split across historian tags, flare cameras, permits to work and shift logs.
• Attribution is assembled by hand, often days after the shift, and planned maintenance looks the same as unplanned upset in the totals.
• The same work is then rebuilt separately for each regulatory regime the plant reports to.
• The Flare Attribution Ledger joins every source into one model the operator owns and names the cause of each event before the shift ends.
• Detection runs on the plant edge, raw operational data never leaves the perimeter, and the control room accepts or corrects every attribution.

WHY THIS MATTERS

A detection is not a cause. Cameras show flame and smoke, and the historian shows flow and pressure, but neither names the relief valve or compressor behind the event.

Timing decides accuracy. An account produced the next morning no longer matches what the operator remembers, what the permit authorized or what the shift log recorded in the minutes after the event.

Planned and unplanned flaring need to be told apart. When a scheduled depressurization is indistinguishable from an upset, the flaring minimization plan is fed the wrong signal.

And compliance is duplicated. Three regimes ask the same question in three formats, so evidence that was never assembled once is reconstructed three times.

This creates a structural exposure.

• Historian tags record what moved but not which equipment caused it.
• Flare camera detections are never joined to the equipment, permit or operator action behind them.
• Permit to work records are not linked to the events they may explain.
• Flare investigators correlate tags, video and documents by hand.
• Each regulator's report is assembled separately from the same scattered evidence.
• Sending raw operational data off site to analyze it conflicts with residency and security obligations.

Every flaring event should carry its cause before the shift ends.

One evidence record per event, written once and read by every regime the plant answers to.

WHAT YOU'LL LEARN

Inside the architecture, you'll find:

• Why flaring is measured in totals but decided in events
• How each plant system holds one fragment of the cause, and what joining them requires
• The four goals that fix the design: attribution before shift end, one record per event, residency and extensibility
• Three scoping decisions and what each costs, from existing instruments to grounding the model in the asset framework
• What the design chose against, and why it complements rather than replaces an existing flaring prediction model
• The layered stack from nine sources through two adapter families to five surfaces
• The sixteen-object model, with the flaring event shown as Praxis records it
• Why a document search cannot assert that a permit covers a stack for a given window, and how typed links can
• How a de-identified event backbone keeps raw operational data inside the plant perimeter
• Why detection runs on the plant edge and coordination in-country, and how degradation is designed in advance
• The central reasoning model, the edge detector and the named fallback, with the license reading that decides between them
• How the rollout measures scan quality, camera reuse and the alert budget before the classifier is trusted
• The six named failure modes, four lessons the design encodes and the questions still open
• How plant staff extend the event library themselves as citizen developers
• How Praxis contextualized the requirement, read it through its lenses and reasoned every choice in the design

DOWNLOAD THE ARCHITECTURE

Read the complete architecture, from the fragments of cause each plant system holds, through the object model, ingestion, inference placement and model register, to the two-phase rollout and the reasoning Praxis recorded for every choice. Plants that can explain each flaring event while the shift still remembers it can tell planned work from upset, feed their minimization plans the right signal and answer every regulator from one record.