Methodology, visible in the product.
Every event traceable to its source. Every severity grade reviewable. Every interpretation auditable. This page describes the disciplines the platform operates under — the demo shows them running against your corridors and your events.
Standardization
Standardization is where the methodology does its real work: turning raw pipeline notices into structured events, pipeline-specific meters into a unified topology, and every interpretation into something that can be replayed from its inputs.
Bronze, silver, gold. Raw ingestion lands in a bronze layer for archival and reprocessing. Structured extraction produces a silver layer with full lineage back to the originating notice. Aggregated gold tables drive the dashboards and the API.
Content-hashed processes. Notice extraction runs against processes whose content hash is the version number — any edit to a process or worked example auto-bumps the version. Every extraction records the process version that produced it, so any historical notice can be replayed against the same inputs and produce the same output.
Topology as data. Pipeline meters, hub tags, flow direction, and capacity assignments are stored as data, not embedded in code. Topology changes are versioned, auditable, and propagate through the silver layer in seconds — without a platform redeploy.
Two-metric quality. Standardization quality is measured separately at two stages: raw extraction accuracy against a calibration set, and production accuracy after the business-logic filters apply. Keeping the two metrics separate shows the team where any quality issue actually originates.
Severity grading — the published rubric
PipeProwler resolves pipeline notices into severity-graded events.
Severity is the buyer-facing summary of the event's market relevance — the single number a trader reads first to decide whether to act, and the dimension a risk team filters on to surface what matters to the desk. The rubric is published below; specific threshold values and per-dimension weights are held back as proprietary calibration.
The five dimensions
Each event is scored independently across five dimensions. The composite Sev-1-through-5 grade is the surfaced summary; the underlying dimension-level scores are available through the API for buyers who want to filter or weight differently.
- Event type. The categorical classification of what physically happened. Categories include force majeure, scheduled maintenance, unplanned outage, capacity restriction, demand-loss event, supply-loss event, restoration, and aggregator notices that bundle multiple distinct events. Event-type assignment is rule-engine-gated for known mis-classification patterns (see Rule-engine gating below).
- Capacity impact in Bcf/d. The estimated volume of pipeline capacity affected by the event. Calculated from notice text and scheduled-quantity flow data where directly stated; estimated from operator capacity disclosures and topology nameplate values where not. The dimension is graded against thresholds calibrated to the historical distribution of capacity impacts the platform has seen across the surveilled corridors.
- Supply/demand effect. Whether the event tightens, loosens, or leaves balanced the physical supply-demand picture at Henry Hub. A supply-loss event on a Mexico-export corridor, for instance, can be offsetting, because the lost export demand counters the supply loss. This dimension classifies the physical effect; the directional price call stays with the buyer's desk and models.
- Recovery profile. How quickly the event is expected to resolve. Profiles range from minutes (compressor restart, brief flow restriction) to hours (operational adjustment) to days (planned maintenance window) to weeks or longer (force majeure with infrastructure damage). The recovery profile is what tells the trader whether the event is a tactical reaction or a structural reposition.
- Corridor scope. Which hubs and corridors are affected. Includes Henry Hub–direct impacts, active Gulf Coast LNG feedgas corridors, basis hubs (TETCO Z5, Eastern Gas South, Transco zones, and others), and Mexico-export routes. Corridor scope determines whether an event is a single-pipeline matter or a system-wide one.
The composite grade
The five dimension scores are resolved into a single Sev-1-through-5 composite through a weighted function. The function and the per-dimension weights are held back as proprietary calibration. The five-grade scale itself is published:
- Sev 5High-impact event with significant capacity at risk on an HH-direct or major LNG-feedgas corridor, with a recovery profile measured in days or longer, or a high-conviction physical supply/demand effect.
- Sev 4Material-impact event affecting capacity or flow on a relevant corridor, typically with a recovery profile measured in hours-to-days.
- Sev 3Meaningful event worth surfacing for desk awareness, typically narrow corridor scope or short recovery profile.
- Sev 2Minor event that meets the platform's surfacing threshold but doesn't warrant immediate action.
- Sev 1Routine event captured for completeness; rarely action-driving.
Calibration anchored to hand-checked reference events. The platform maintains a continuously-curated sanity set of hand-reviewed notices spanning the range of event types and severity grades seen in production. Every severity rule and every threshold value is validated against the calibration set before deployment. The calibration discipline is what makes the rubric defensible: every published threshold has been measured against ground-truth examples a human operator has independently reviewed and graded.
Versioned, reviewable, audit-defensible. Every severity assignment is reproducible from its inputs: the originating notice, the process version that extracted the structured event, and the rule version that fired the severity score. The platform tracks the as-of severity any historical event was assigned, so back-testing against a corrected rubric does not retroactively rewrite history. Severity rule versions are deployable without retroactive replays; replays are explicit decisions, not implicit drift.
Why the rubric is published. Publishing the rubric is a deliberate competitive choice that produces consistent and defensible scores, while giving the institutional buyer enough to evaluate the discipline without scheduling a demo.
Data sources
The platform's data surface is anchored on the institutional public sources every U.S. natural gas market participant already relies on, augmented by established commercial providers across the categories the market doesn't publish on its own.
Quality controls
The platform's quality discipline is built around the assumption that any single layer — ingestion, extraction, resolution, gating — can produce a wrong answer. Quality controls are the multi-layer defense.
Source monitoring. Pipeline notice feeds, market data subscriptions, and weather model deliveries are monitored continuously for staleness, drift, and structural changes. When a source goes stale or its format changes, the platform flags the affected downstream extractions, alerts on the data-quality issue, and routes around the gap where possible.
Validation at ingest. Raw notices entering the bronze layer are validated against per-source structural rules before they progress to extraction. Extracted silver-layer events are validated against business-logic rules — capacity values within plausible bounds, hub tags within the topology, timestamps within source-cycle windows.
Re-ingestion and correction. When an upstream source publishes a correction, the platform re-ingests, re-extracts, and supersedes the prior interpretation, preserving the full superseding chain in the audit log. The corrected silver-layer event carries lineage back to both the original and the corrected source notices.
Confidence scoring on notice extraction. Every extraction carries a confidence score derived from the rule-engine and the extraction layer's own self-assessment. Low-confidence extractions are routed for human review before they propagate to the gold layer; high-confidence extractions proceed directly.
Cross-event consistency enforcement. Events that should be related (a supersede chain, a multi-pipeline coordinated event, a forecast-actual pair) are enforced for cross-event consistency at the silver layer. Inconsistencies are flagged, logged, and resolved against the calibration discipline.
Model validation
Where the platform's outputs involve models — severity scoring, supply/demand-effect classification, synthesis output — the model validation discipline is the protection between research and production.
Walk-forward validation. Models are validated against held-out time-forward windows that the model has never seen during training. Performance is measured in the same regime conditions the model will face in production.
Regime-isolated testing. Performance is broken out by market regime — cooling season versus heating season, low-volatility versus high-volatility periods, structural-event windows versus normal-cadence windows. A model that performs well on average but fails in a specific regime is flagged before it ships.
HAC-corrected significance testing. Heteroskedasticity- and autocorrelation-consistent corrections are applied to all hypothesis tests on model performance. Time-series residuals are not independent, and standard t-tests overstate significance against autocorrelated returns; HAC corrections produce honest p-values.
Diebold-Mariano forecast superiority testing. When a new model is proposed against an existing baseline, Diebold-Mariano tests measure whether the new model's forecasts are statistically superior — not just whether they have higher mean accuracy. A model that's better-on-average but not statistically distinguishable from the baseline is not a deployment candidate.
Bootstrap confidence intervals on performance metrics. Point estimates of forecast accuracy mislead when the confidence interval crosses zero. The platform reports bootstrap confidence intervals on every metric the trading desk would act on; metrics with intervals that include "no edge" are reported as such, not rounded up.
Out-of-sample replication required before deployment. A feature that passes walk-forward, regime-isolated, and significance testing on one historical period is required to replicate the same performance on a second, fully out-of-sample period before it ships to production. Replication is the bar; in-sample fit is not.
Feature retirement protocol. Features that fail out-of-sample replication are retired before they ship. Research and deployment are kept on separate tracks; what reaches the trader has passed the full validation cascade, and the platform's production output is bounded to features that have cleared every gate.
Reproducibility and lineage
Reproducibility is the substrate the rest of the methodology rests on. The platform can replay any historical interpretation against its original inputs and produce the same output.
Process version-pinning. Every silver-layer extraction records the content-hashed process version that produced it. The platform retains every process version that has ever shipped; any historical extraction can be replayed against its as-of process and produce the same output bit-for-bit.
Topology version-pinning. Topology and hub-tag assignments are versioned alongside the processes. A historical extraction interpreted under an earlier topology can be replayed against either the as-of topology (to reproduce the historical view) or the current topology (to see the modern interpretation), with both available through the API.
Time-versioned data surface. Historical queries return the data as it existed at the queried point in time — not as it has since been corrected or revised. A risk team back-testing an event from six months ago sees the event as the trader saw it then, not as it would be scored under today's rules.
Audit trail from raw notice to API event. Every API event carries lineage back to its originating raw notice, through every transformation in the silver and gold layers. The lineage is exposed through the API and visible in the dashboard; a trader, a risk officer, and an auditor can all click through to the same defensible record.
Audit logs available to customers. Institutional deployments receive audit logs covering every interpretation the platform has produced for that customer's data surface, with retention windows configurable to the customer's compliance requirements.
Sub-minute latency, defined. The platform's "sub-minute" claim measures the elapsed time from notice publication on the upstream source (a pipeline's electronic bulletin board) to resolved event availability on the API. This is the boundary that matters for a trader reacting to physical reality: how quickly does what posted upstream become a queryable, scored, lineage-traced event in the buyer's hands.
Common questions
How does ThermSuite's severity grading work?
Every event scores across five dimensions, with rubric thresholds calibrated against a hand-checked reference set. Scoring is deterministic — every event runs against versioned rules and content-hashed processes that reproduce the same output from the same inputs.
What sources does ThermSuite ingest?
Pipeline operator notice text and scheduled-quantity flows ingested directly from FERC e-tariff postings and electronic bulletin board systems. Every published event traces back through standardization to the originating raw notice.
How is source-to-API lineage maintained?
Every observation carries full data lineage from the raw source through to the API. A trader, a risk team, and an audit team are all looking at the same defensible record of what happened, when, and why it mattered. The lineage is exposed through the API and visible in the dashboard.
How are ThermSuite's models validated?
Where models are involved, validation runs against walk-forward, regime-isolated, HAC-corrected significance testing, with retirement protocols for features that fail out-of-sample replication. Research and deployment are kept on separate tracks; what reaches the trader has passed the full validation cascade.
What latency does ThermSuite operate at?
Sub-minute from notice publication on the upstream source to resolved event availability on the API. This is the boundary that matters for a trader reacting to physical reality: how quickly does what posted upstream become a queryable, scored, lineage-traced event in the buyer's hands.
Is ThermSuite's methodology visible to buyers?
Yes. The platform's data sources, standardization layer, severity-grading dimensions, model validation discipline, and reproducibility commitments are visible through the lineage trail every event carries and the audit surfaces every interpretation exposes. What the buyer evaluates in the demo is what the platform actually does.
Talk to the team.
The methodology operates in the product; this page describes what to expect. Reach out for a working walkthrough — severity-grading, lineage, and audit trail shown live across the platform.