In the first article, I argued that a lab result cannot be interpreted without its facility and local rules. The next engineering question is where those rules should live.

The quick implementation would be a chain of conditionals: if the facility is in Michigan, use these thresholds; if it is in Washington, use another set. That might work for a demo with one facility. It breaks down when two facilities in the same state discharge to different municipal treatment systems, or when a treatment authority changes a surcharge schedule without changing state law.

As a data science engineer and BrewClear cofounder, I want the calculation to answer a narrower question: given this reading and the rule record that applies to this facility, what does the record say? Finding, verifying, and maintaining that rule record is a separate data problem.

The correct granularity is local

The U.S. Environmental Protection Agency describes pretreatment local limits as site-specific protections for a publicly owned treatment works (POTW), its workers, sludge, and receiving waters. They may be numeric or narrative. That is why a state code alone is not a sufficient lookup key for an industrial wastewater limit.

For a facility discharging to a municipal sewer, we need to know which treatment authority receives its wastewater. We also need to distinguish that path from a groundwater discharge or a direct surface-water discharge, where a different authority and permit process may apply. BrewClear's permit finder represents those as separate paths; it does not treat them as interchangeable compliance workflows.

This led us to three layers of data:

The facility links to a locality and identifies its state and industry. The calculation then reads the locality record. That relationship is the important part: a threshold belongs to the applicable authority, not to a generic state-wide default.

A rule pack is a data contract

In the current BrewClear proof of concept, each supported state has a JSON file. The file describes the state's paths, agency, resources, questionnaire, capabilities, and locality entries. Industry packs are separate JSON files. A JSON Schema defines the shape a state pack must have: required sections, valid path identifiers, expected data types, and allowed capability fields.

At startup, BrewClear scans the pack directories, parses each file, validates it with the schema, and registers valid packs in memory. Invalid JSON, schema failures, or duplicate IDs are logged and skipped; they do not prevent valid packs from loading. Tests discover every pack file and check structural assumptions, so a newly added pack is included in the conformance suite.

That is a useful contract. It catches a missing localities array or an unexpected capability value before the app tries to use the pack. It also makes the intended extension point visible to another engineer: adding a jurisdiction begins with a data file and a validation run, not a search through every screen for state-specific branches.

But schema validity is a very limited kind of validity. A schema can confirm that a pH limit is numeric. It cannot prove that the number came from the current ordinance, applies to this facility's permit, or uses the right averaging period. For a compliance product, those questions matter more than whether the JSON parses.

Provenance needs a finer label than “verified state”

Our Michigan pack illustrates a subtle distinction. Its state-level metadata marks the regulatory framework as verified, while a locality inside that pack can be partially_sourced. The locality also carries source links and notes that distinguish confirmed facts from working estimates. Other locality entries may be marked estimated.

Those labels should never be collapsed into one green “Michigan verified” badge. State guidance and a treatment authority's numeric values have different evidence. We therefore store locality provenance with the limits themselves, including limits_status, source references, and explanatory notes when seeding the database.

This is the beginning of a review workflow, not the end of one. A published webpage can establish that an industrial pretreatment program exists while leaving a particular surcharge rate or permit-specific condition unconfirmed. Before a locality record is used for real reporting, someone must reconcile each applicable value with the controlling ordinance, permit, or authority. BrewClear's demo data is deliberately labeled where that work remains.

How the data reaches the shared engine

The pack loader registers state and industry content for the application. On a fresh demo database, the seeder copies each pack's locality entries into PostgreSQL so facilities can reference locality records. A reading is evaluated with the limits on its facility's locality row. The checkReading(reading, locality) function does not need a Michigan-specific or Oregon-specific branch for each numeric threshold; it receives the relevant limits as input.

The runtime path: validated packs provide guidance and locality entries; seeded locality rows link to facilities; each reading and its facility's locality record enter the shared checker.

The separation also lets a state pack say which features it is ready to offer. For example, the California demonstration pack sets report_draft to false. That flag is surfaced to the application so an unsupported report workflow can be withheld. In a production design, capability checks also need to be enforced at the API boundary; a UI flag alone is not a security or correctness boundary.

The difficult part is changing rules safely

The current architecture makes adding a candidate state pack straightforward. It does not make regulatory content self-updating. In today's proof of concept, locality rows are seeded when the locality table is empty. Editing a JSON pack does not automatically update locality rows in an existing database. That is a deliberate gap between a demonstrable extension mechanism and a production content-management process.

The next stage needs a controlled way to introduce rule changes: source review, effective dates, approval, a database migration or synchronization step, and a record of which rule version produced each historical decision. It also needs an alert if a pack expected in a deployment fails validation and is skipped. Staying online is useful; quietly losing coverage would not be.

The principle behind BrewClear's rule packs is simple: keep the decision procedure stable, and make the changing regulatory content explicit, attributable data. The harder work is building the evidence and change process around that data. That is where a flexible architecture becomes a trustworthy one.

Next in the series: how manual entries, CSV files, lab EDDs, and document extraction become a common reading without losing units, qualifiers, or source information.

Imagine an environmental consultant opening a lab report for a small brewery. The report has a BOD result and a sample date. Somewhere else is the facility's permit. A sewer-use ordinance contains the receiving treatment authority's rules. The reporting deadline is on a calendar, and last month's corrective-action notes are in an email thread.

The number in the lab report matters. But it cannot answer the question the consultant actually has: What does this result mean for this facility, under the rules that apply to it, and what needs to happen next?

I am a data science engineer and a cofounder of BrewClear. We started building it because this question sits at the intersection of messy source data, local regulatory context, repeatable calculations, and human judgment. That makes it an engineering problem before it becomes a dashboard problem.

The same measurement needs different context

In the United States, an industrial facility that discharges to a municipal sewer may be subject to pretreatment requirements administered through a publicly owned treatment works, or POTW. The U.S. Environmental Protection Agency explains that the national program aims to protect treatment infrastructure and reduce industrial pollutants entering municipal systems. Local limits address the needs of a particular POTW, its workers, sludge, and receiving waters. They can be numeric or narrative.

So a BOD result is not a universal green or red number. Interpreting it requires the correct facility, discharge path, treatment authority, applicable limit, measurement unit, sample date, and sometimes a different threshold for a surcharge than for a violation. A result without that context is only a value in a file.

The engineering consequence is clear: we cannot hard-code one set of thresholds and call it a compliance platform. The rule itself must be data, connected to the facility and accompanied by a source and a verification status. We also need to know when a result was sampled and which version of a rule was used to assess it. BrewClear's proof of concept handles some of this context today; full historical rule versioning is still work ahead.

The inputs do not arrive as one clean dataset

Consultants receive data in forms created for different purposes. A lab may deliver one row per analyte, with sample identifiers, methods, units, qualifiers, and reporting limits. A simple spreadsheet may have one row per sample. A permit may be a PDF. A deadline may be in a calendar, while evidence of a corrective action lives in an email or document.

Those files cannot safely be merged by matching a date and hoping for the best. The pipeline needs to answer questions such as:

• Which facility and sampling point does this record belong to?
• Are two rows different analytes from one sample, or two separate samples?
• Does the lab's name for an analyte match the parameter named in the local rule?
• Are the units compatible, and what does a non-detect qualifier mean?
• Which values were imported, which were extracted from a document, and which were entered by a person?

Our first approach in BrewClear is to normalize several input paths into a common reading record. The current proof of concept accepts manual entries, a simple CSV layout, a canonical lab electronic data deliverable, and document-assisted extraction. The lab parser groups analyte rows into samples and returns warnings for conditions such as unit mismatches or untracked analytes. Extracted document values prefill a form for review; they are not silently treated as confirmed measurements.

That distinction matters. A pipeline is useful only if it preserves the meaning and uncertainty of its inputs. A plausible-looking number with a lost unit or qualifier can be more dangerous than a missing value.

A decision should be traceable through the system

Once a reading is normalized, it still needs to be evaluated against the right local rule. In BrewClear, the core check is a deterministic function: it takes a reading and a locality record, then returns parameter-level results and an overall classification. A separate calculation produces a rough surcharge estimate where rates are configured. The same checking logic feeds reports, client packets, and the data tools used by the copilot.

That shared calculation is an architectural choice. If a dashboard, a report, and an AI assistant each implement their own threshold logic, they can disagree about the same sample. Reusing one calculation makes a discrepancy easier to detect and explain. It also gives us something concrete to test with known inputs and expected outputs.

Here is the flow we are building around:

Lab file / entry / document
          |
          v
Normalized reading + source + warnings
          |
          +-------- Applicable locality rule + provenance
          |                    |
          v                    v
             Deterministic check
                     |
          Classification + explanation
                     |
          Consultant review and action
                     |
             Draft report / packet

The diagram also shows a limit of the software. A classification is not the end of the workflow. Someone still needs to assess the source documents, investigate unexpected results, record corrective action when appropriate, and review what will be submitted. BrewClear does not file reports with an agency.

Why build BrewClear around this workflow?

A spreadsheet can calculate against a known threshold. It is much harder for a collection of spreadsheets, PDFs, and inboxes to maintain a reliable connection between a facility, its changing local rules, the original measurement, the calculation, and the action taken. That connection is the product we want to build.

Our current proof of concept demonstrates the workflow across Michigan, Washington, Oregon, and California with seeded facilities. It uses state and industry rule packs, locality records, reading ingestion, deterministic checks, reports, and a consultant workspace. This demonstrates the architecture; it does not mean every locality value is ready for unsupervised production use. Regulatory content must be checked against authoritative sources, and the person responsible for a report must review it.

The deeper engineering work is still ahead: stronger validation across varied lab formats, rule effective dates and versioning, end-to-end lineage, better storage of source documents, and production data-quality monitoring. Those are not peripheral improvements. They determine whether a future result can be explained and trusted.

That is why I describe wastewater compliance as a data engineering problem. The goal is not to automate judgment away. It is to give the people making decisions a consistent, traceable picture of the evidence and the rules.

Next in the series: how BrewClear represents state guidance and locality-specific limits as rule-pack data, so the same checking engine can work across different jurisdictions.