Flaring Pack & flaring_watch Skill
This page documents the RRC oil & gas vertical — one of the five packs installed on AEGIS. The mechanisms (packs, skills, routers, HITL rules) are domain-neutral.
Continuous flaring compliance is delivered two ways: the flaring_monitor pack (which powers the flaring_monitor compliance domain and its dashboard column) and the read-only flaring_watch skill (the conversational surveillance capability). There is no longer a dedicated “Flaring Monitor” agent — a user reaches flaring_watch in a general-mode conversation through the flaring router, which carries a watch/file pair (monitoring → flaring_watch; exception filing → rrc_rule32, see Rule 32 Pack).
How it is reached
| Mechanism | Value |
|---|---|
| Pack | flaring_monitor (packs/flaring_monitor/manifest.yaml) |
| Watch skill key | flaring_watch |
| Router | flaring → flaring_watch (monitoring) / rrc_rule32 (filing) |
| Compliance domain | flaring_monitor |
| Entity types | Well |
The flaring_watch skill
flaring_watch is a read-only surveillance skill. It answers portfolio-wide flaring questions: which authorizations are expiring, unauthorized-flaring detection, and monthly flared-vs-authorized status. It exposes two code blocks — flaring_volume_status and emissions_screening — which reuse the rrc_rule32 code-block implementations under distinct tool names. It never mutates and carries no HITL rule; when the user needs to actually file, the conversation loads rrc_rule32 (whose pre_filing gate applies).
Historical note: the retired flaring-monitor-agent (agent type flaring_monitor) has no
agent_definitions row — permanently, by design. With flaring_watch seeded, the orchestration
engine’s last agent_type-keyed tool branch (the R35-FENCE) was removed. The agent_type
enum value remains valid only for historical snapshots and replay.
The flaring_monitor pack
The pack declares six skills (orchestration.skills.flaring_monitor.*, plus a declarative emissions_calc descriptor for reporting) and its own checklist template and assessment recipe:
| Skill key | Item | Purpose |
|---|---|---|
flaring_auth_inventory | Active Authorization Inventory | List active R-32 authorizations with expiration dates, authorized volumes, utilization |
flaring_volume_monitoring | Volume Threshold Monitoring | Track daily/weekly volumes against limits; alert at 70/85/95% utilization |
flaring_expiration_calendar | Expiration Calendar | 90-day forward calendar; auto-generate renewal checklists 30 days out |
flaring_regulatory_status | Multi-Regulatory Status | Map each event against RRC Rule 32, TCEQ, EPA OOOOb, GLO, BLM |
flaring_infrastructure_tracking | Infrastructure Progress Tracking | Track pipeline/compressor/facility progress against R-32 commitments |
flaring_emissions_reporting | Emissions Reporting | Running CO2e totals for GHGRP Subpart W; pre-populate ESG disclosures |
Checklist & assessment
The pack’s checklist template defines these six items (indices 0–5) with min_required_items 0, 1, 2. The assessment recipe runs a cumulative_limit check summing flared volume_mcf against the period cap (authorized_volume_mcf, resolved warning fraction 0.80 for SWR_32) — a daily-cap-only authorization has no cumulative budget to consume, so binding to the period cap avoids fabricated utilization. Auth-only rows with no flare target are stamped FlaringAuthorization and named by authorization_number (INT-1 parity).
Regulatory frameworks tracked
| Framework | Authority | Scope |
|---|---|---|
| RRC Statewide Rule 32 (16 TAC 3.32) | Railroad Commission of Texas | State flaring/venting exception authorizations |
| EPA OOOOb | US EPA | Federal methane emission standards — the separate epa_oooob pack |
| GHGRP Subpart W | US EPA | Greenhouse-gas reporting for petroleum and natural gas systems |
| TCEQ Air Quality | Texas Commission on Environmental Quality | State-level air emission permits and thresholds |
The dashboard does the heavy lifting
Persistent flaring surveillance lives on the Flaring Dashboard and the flaring_monitor column of the compliance matrix — both backed by the config-driven assessor recipe above, not by an agent conversation. The flaring-monitor service (port 8007) and the flaring_authorizations system-of-record back the volume/period-cap math.
Surveillance detects and summarizes; it never initiates R-32 filings. When a well or lease needs
a new or renewed authorization, the user starts a general conversation and loads rrc_rule32,
whose pre_filing HITL checkpoint gates submission.
Source Files
| File | Purpose |
|---|---|
services/orchestration-engine/src/orchestration/packs/flaring_monitor/manifest.yaml | Pack manifest (skills, checklist, assessment) |
services/agent-config-service/src/agent_config/seed_watch_skills.py | Seeds the flaring_watch skill |
services/agent-config-service/src/agent_config/routers_seed.py | flaring router (watch/file pair) |
services/flaring-monitor/ | Flaring volumes + emissions service (port 8007) |