BCER / SWRS, filed from data you can defend.

File to the BC Energy Regulator from data you can defend: SensorUp composes Observations, Calculations, and an immutable audit trail into the SWRS submission.

A drilling rig lit up at night on a snow-covered well site under a moonlit winter sky.

The problem

The SWRS number is due, and the data that defends it lives somewhere else

A submission to the BC Energy Regulator is a provincial filing built from operational data that was never organized for it. The regime is jurisdiction-specific; the failure mode is not.

[ 01 ] Disagreeing sources

The sources behind the filing don't agree with each other

Historian, survey, and spreadsheet each say a different number.

The historian says one thing, the survey records say another, and the spreadsheet that reconciles them says a third. The SWRS submission asks for a single number anyway, and whoever signs it inherits the disagreement.

[ 02 ] Manual rekeying

Reporting season means retyping operational data into a filing

Every manual step is a place the number can drift from its source.

The data exists. It lives in systems that were built to run the field, not to file to the BC Energy Regulator, so every reporting cycle, someone exports, transcribes, and reshapes it by hand, and every manual step is a place the number can drift from its source.

[ 03 ] Audit-trail gaps

When the regulator asks how you got the number, the trail is a reconstruction

Copy-paste paths mean the audit trail is rebuilt after the fact.

The question that matters isn't the value, it's the provenance. If the path from source reading to submitted figure runs through copy-paste and personal spreadsheets, the audit trail is rebuilt after the fact, by the person who remembers the most.

It reads the systems you already run; the BC framework is a composition target, not a new product

[ 01 ] Consume

Your operational sources, read where they live

Reads SCADA, monitors, OGI, and satellite; nothing punched into OT.

The Warehouse reads your SCADA historians (PI, CygNet) over OPC-UA and Modbus, plus continuous monitors, OGI, and satellite. Ingress is pull-shaped, so nothing new is punched into the OT segment.

consume: PI, CygNet ← OPC-UA / Modbus
[ 02 ] Normalize

The messy export is the expected input

Raw records stay addressable even after they are normalized.

Raw records are kept as ingested, then projected into one canonical model, so the original export stays addressable. Transform does the work the spreadsheet used to: normalization, unit conversions, emission-factor lookups, and data-quality scoring, in a pipeline you can inspect.

raw record → canonical observation
[ 03 ] Frameworks

The BC Energy Regulator framework lives in the Library

Rule sets and factors are Library content, not custom code.

Regulatory rule sets, calculation methodologies, and emission factors are Library content, not custom code. BCER / SWRS is a pre-built solution composed in Studio against that framework, the same foundation that serves EPA Subpart W serves the provincial regime without a new procurement cycle.

compose: Library framework → SWRS entry

Observations, Calculations, and an audit trail, composed into the SWRS submission

[ 01 ] Catch

Every reading, linked to the asset it observes

Readings land tied to facilities, wells, and equipment, normalized once.

Source readings land as Observations tied to the facilities, wells, and equipment they describe, normalized once, in one model, instead of exported per reporting cycle. The disagreement between sources becomes visible and reconcilable, with the provenance to settle the argument.

[ 02 ] Prioritize

The reported figure derives from its sources, visibly

The submitted number is a derivation you can walk backward.

Calculations run continuously against Observations, using the emission factors and methodologies the Library holds for the framework. The number you submit is not a spreadsheet artifact, it is a derivation you can walk backward, step by step, to the readings underneath it.

[ 03 ] Resolve

One submission, with its audit trail attached

The figure carries its lineage into sign-off, not a reconstruction.

The reconciled figure moves into your team's sign-off and document assembly carrying its full lineage: every input, every transformation, every approver. An immutable audit trail records each change, so the submission inherits a trail an auditor can walk, not a reconstruction built after the request arrives.

The submission is composed from the same blocks

The SWRS submission is assembled in Studio from shared blocks, run by Autopilot on the Warehouse record beneath it. The same blocks serve the federal EPA Subpart W entry and every solution 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
BCER / SWRS draws Calculations from Studio, the dispatch Workflows from Autopilot, and Datasets, Integrations, Reference Library, and Ledgers from the Warehouse. The blocks are shared across every solution; only the composition changes.

See SWRS-ready numbers reconcile before they are submitted

Meter, SCADA, and survey data reconcile into one figure per stream, filtered to what the B.C. report needs, with custody intact.

app.sensorup.com/swrs
SensorUp product screen: a reconciliation chart of reportable emission streams
A frame from the product interface.
$schedule --with engineer --bring your-swrs-workbook

Talk to an engineer

Bring the workbook you file from today. We'll map your SWRS submission fields to your actual sources, walk the audit trail end to end.

SecurityTrust ↗