Seven Rulebooks, One Engine

The problem

Each state publishes its own material categories, so the same physical packaging component needs a different classification depending on which state's report is being generated. Client spreadsheets arrive using whatever coding standard the supplier happened to use.

What we did

A canonical material coding system sits underneath every state's list, with an alias table that resolves industry standards such as ISO 21067, SPI resin codes, and state recycling codes onto the canonical code during import.

The outcome

A packaging component is classified once and reads correctly in every state's report, and messy source files map themselves on the way in.

The problem

De minimis exemption logic alone has four distinct evaluation modes across the seven supported states, each with its own threshold and its own definition of which revenue counts. Hard-coding states would have meant a rewrite with every new program.

What we did

A config-driven rules engine evaluates each jurisdiction's logic mode, thresholds, and fee schedule against the same underlying product and packaging data, so a state is added as configuration rather than as code.

The outcome

Seven state filing regimes run from one engine and one data model, and the eighth is a configuration exercise.

The problem

Client data arrives as spreadsheets with thousands of rows, and the hosting platform caps how long any single request may run. A naive importer that looks up material codes, jurisdictions, and existing SKUs row by row will not survive a real client file.

What we did

Every lookup table is pre-fetched into memory before the row loop begins, so each row resolves without touching the database again. The pattern was written into the project conventions so all future import code follows it.

The outcome

Bulk imports of products, packaging, and supply data complete inside the execution window instead of failing partway through a customer's file.

The problem

A compliance filing is a financial document. In a per-SKU fee breakdown, rounding at the wrong point in the aggregation makes the displayed total disagree with the rows beneath it, and that is the first thing a reviewer notices.

What we did

Fee attribution runs on raw values end to end, with rounding applied exactly once, at the final displayed figure, and the same rule applied to every aggregation in the product.

The outcome

Every total in the interface and in a generated report adds up against its own line items.