What was breaking in chemical compliance documentation before this project?
The client was a chemical production and shipping company handling highly toxic and hazardous chemicals. Federal regulations require accurate Material Safety Data Sheets (now also known as Safety Data Sheets under the OSHA HazCom 2012 standard aligned with the Globally Harmonized System) for every chemical the company handled. The data on each chemical had to be exact: composition, hazard classifications, handling requirements, storage conditions. A single error on a manifest or a shipping label is not a paperwork problem. It is a regulatory violation that can halt operations, trigger reportable incidents, and expose the company to liability.
The existing system was built on Visual Basic 6 and needed to be revitalized to handle multiple regulatory updates and the package deployment requirements of several chemical production and shipping clients. The system also needed to produce compliant output across a full range of formats: SDS documents for regulatory files, manifests for transportation, labels sized to specification for containers, and signage for storage locations. Managing all of that from a single database without manual reconciliation between systems was the core requirement, and the existing architecture was no longer sufficient to the regulatory pace the operation faced.
For a chemical production and shipping operation, the consequences of weak SDS infrastructure are operational and direct. A label that does not match the manifest can stop a shipment at a checkpoint. A batch record that cannot be traced to a delivery creates audit exposure. A manifest with a hazard classification error can result in a regulatory citation and a reportable incident. The compliance documentation is not separate from the business. It is the business, when the business is moving hazardous chemicals across regulated supply chains.
What did PCG actually build for the chemical compliance environment?
PCG designed an extensive Visual Basic program and database system that gave the company direct, fast access to every chemical record in their inventory. The architecture was built around a single source of truth for chemical data, with output formats produced from that source rather than maintained in parallel. Each component was built so that the regulatory documentation the operation produced every day reflected the actual chemical and batch data, not a manually entered summary that might drift from the physical record.
Every chemical the operation handled was recorded in a central database with full composition, hazard classification, handling requirements, and storage conditions. The search engine allowed operators to locate any compound quickly by exact chemical data. Adding, editing, updating, and searching chemicals happened from one interface rather than across separate documents.
Each batch of chemicals was tracked through to its associated shipments, maintaining a complete chain of custody from production through delivery. That linkage is what makes the system defensible in a regulatory review. When an inspector or auditor asks for the documentation associated with a specific shipment, the answer comes from the linked batch record rather than from a manual reconstruction across separate files.
The system produced MSDS and SDS documents directly from the underlying chemical records. Composition, hazard classifications, handling requirements, and storage conditions appeared on the generated documents exactly as they appeared in the database. The risk of drift between the source record and the regulatory output was eliminated by making the output a query rather than a separately maintained document.
The same chemical record that produced the SDS document also produced the transportation manifests for shipments, the container labels sized to specification, and the signage for storage locations. Every regulatory output that referenced a chemical drew from the same source, which kept the manifest, the label, the SDS, and the storage signage internally consistent without manual cross-checking.
The system was designed to support several chemical production and shipping clients with their own package deployment requirements. Each client could operate its own configured deployment of the system without forcing the architecture to fragment. Updates to handle new regulatory requirements deployed across all client installations through the same maintenance workflow.
Chemical compliance fails in a specific way. The data exists. The chemical records are filed. The SDS documents have been written. The manifests have been produced. What does not exist, until someone audits the operation, is the guarantee that the SDS, the manifest, the container label, and the storage signage all reference the same chemical record with the same data. Drift between those documents is invisible until a regulator finds it during inspection. A system that produces every output format from the same source eliminates the drift category at the architectural layer rather than asking compliance staff to catch it manually.
The decision to support multi-client package deployment from one system was deliberate. The client served several chemical production and shipping operations, each with its own deployment requirements. Building separate systems per client would have multiplied the maintenance burden without delivering value to any of them. A single architecture configurable per client kept regulatory updates manageable across the full operation while letting each deployment match its specific operational context.
What changed after the system went into production?
The most immediate change was that every regulatory output format the operation produced drew from one chemical record. Manifests, container labels, SDS documents, and storage signage all reflected the same source data by construction. The cross-checking work that had previously absorbed compliance staff time disappeared because the documents reconciled by architecture rather than by manual review.
| Outcome | Result | How it was achieved |
|---|---|---|
| Cross-format documentation consistency | Single source of truth | SDS, manifests, labels, and signage produced from the same chemical record |
| Chain of custody documentation | Production through delivery | Batch-level tracking linked to shipment records across the operation |
| Chemical lookup and search | Exact-match across full inventory | Direct search engine for chemical composition, hazard classification, and handling data |
| Regulatory output formats supported | SDS, manifests, labels, signage | Single chemical record drives every regulatory output the operation requires |
| Multi-client deployment | Configurable per client | Package deployment architecture supported several chemical production and shipping clients from one codebase |
| Regulatory update absorption | Deployed across all clients | Maintenance workflow propagated regulatory changes through every client installation |
The strategic value of the system extended beyond the immediate compliance posture. Once chemical inventory, batch tracking, and regulatory output operated as one platform across multiple client deployments, the operation gained the kind of reusable infrastructure that smaller chemical compliance shops cannot build from scratch. Each new client deployment started from a working foundation rather than a custom build, which changed the economics of expanding the chemical compliance service line.
What capabilities does this kind of system provide for chemical compliance operations?
The infrastructure built for this chemical production and shipping operation addresses a problem class that appears across every operation handling regulated chemicals under federal HazCom, OSHA, DOT, EPA, or international GHS frameworks. The capabilities below apply to chemical manufacturers, chemical distributors, hazmat shippers, industrial hygiene firms, environmental services companies, and any operation where Safety Data Sheets, transportation manifests, container labels, and storage signage have to remain internally consistent under regulatory review.
One database structure containing complete chemical composition, hazard classification, handling requirements, and storage conditions. Cross-format outputs draw from the same source rather than being separately maintained, which eliminates the document drift that produces audit exposure.
Batch-level tracking linked to shipment records across the operation. Inspectors and auditors who request documentation associated with a specific shipment receive a query result from linked records rather than a manual reconstruction.
MSDS and SDS documents, transportation manifests, container labels sized to specification, and storage location signage produced from the same chemical records. Every regulatory output that references a chemical reflects the same source data by construction.
One configured architecture supporting multiple chemical production and shipping clients with their own deployment requirements. Regulatory updates propagate across all client installations through the same maintenance workflow, keeping the operation aligned without parallel rebuilds.
Technology stack
| Component | Technology |
|---|---|
| Application layer | Visual Basic 6 with Microsoft Access database back-end |
| Programming | Visual Basic for Applications (VBA) for application logic and reporting |
| Chemical inventory | Centralized database with exact-match search across composition, hazard, and handling data |
| Chain of custody | Batch-level tracking linked to shipment records from production through delivery |
| Document generation | MSDS, SDS, manifests, container labels, and storage signage produced from chemical records |
| Regulatory framework | OSHA HazCom 2012 / GHS, DOT transportation, EPA, and federal hazmat alignment |
| Deployment | Multi-client package deployment supporting several chemical production and shipping operations |
Does this apply if your chemical operation is smaller than a multi-client production and shipping company?
The architecture scales down as well as up. A single-site chemical manufacturer, a regional hazmat shipper, an industrial hygiene firm, or a small chemical distributor faces the same core problems as a multi-client chemical production and shipping operation: regulatory documentation that has to remain consistent across multiple output formats, chain of custody gaps that surface during inspection, and a regulatory pace that legacy systems cannot absorb cleanly. The engineering decisions on this project transfer directly to chemical operations of any size.
What makes this project transferable is not the multi-client dimension. It is the problem class. Any operation handling regulated chemicals is carrying the same documentation drift risk this client was carrying before the system went live. The drift accumulates invisibly until an inspector finds it during an audit, a manifest mismatch stops a shipment at a checkpoint, or an OSHA enforcement action surfaces inconsistencies between the SDS, the label, and the storage record. A system that produces every output from the same chemical record eliminates the category of error that drives those incidents.
PCG has built chemical, hazmat, and environmental compliance infrastructure for industrial operators, chemical companies, and regulatory service firms since 1995. The work documented here is one of more than 500 production applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years.
Frequently asked questions about MSDS and SDS chemical compliance management systems
Allison has been building custom software since the early 1980s, including work as a data analyst for the U.S. Air Force before founding PCG in 1995. The MSDS and SDS chemical compliance work documented here is one of more than 500 custom applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years. Her direct involvement in every project is not a policy. It is how PCG operates. When you call, she answers.
Project details documented with client permission. Specific identifying details about the chemical production and shipping company have been generalized at client request. System capabilities and architecture reflect the actual production deployment.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding.
What was breaking in the state's pesticide licensing program before this project?
The client was a state government regulatory program responsible for the licensing of every entity that handled pesticides in the state, across three categories: manufacturers, distributors, and applicators. Over years of program growth, the technical infrastructure supporting that work had developed into four separate Microsoft Access databases, each handling a different slice of the licensing function. Training records lived in one. Licensing fees and recertifications in another. Class scheduling, rosters, grading, and printed certifications in a third. Manufacturer and chemical storage records in a fourth.
The four databases held overlapping data with no enforced consistency between them. The same individual could appear in multiple databases with different addresses, different statuses, and different licensing histories. Staff time that should have gone to regulatory work went to reconciling records between systems. New regulatory requirements that affected multiple license types required parallel updates across all four databases, which created integrity risks every time the rules changed. The system had become unmanageable in the strict operational sense of that word.
For a state pesticide control program, the consequences of weak licensing infrastructure are direct and public. License renewals that fall through cracks affect compliant operators. Failed certifications that are not properly recorded create exposure during the next renewal cycle. Manufacturer and storage facility records that cannot be quickly produced affect the state's ability to respond when an incident occurs at a regulated site. The program needed one source of truth across the full pesticide oversight function, not four databases trying to act like one.
What did PCG actually build for the state pesticide licensing environment?
PCG had worked with the client for many years before this consolidation project, which meant the engineering team already understood the operational reality of pesticide licensing work in this state. That long-running domain knowledge was the difference between a generic database consolidation and a system that mapped the actual regulatory process the program ran. Each component was built so that the work staff did every day, from issuing a license to running a certification class to tracking a manufacturer, lived in one place rather than across four databases that did not agree with each other.
The four existing Access databases were merged into one consolidated platform. Duplicate records across the four sources were identified, reconciled, and deduplicated. The historical record that the program had built up over years of operation was preserved completely. No record was lost. No license history was orphaned. The merge happened with the kind of validation discipline that government audit review later requires.
The consolidated database was migrated from Access to Microsoft SQL Server. The Access front-end interfaces that staff already knew remained as the working environment, but the data layer moved to a server-class platform that could handle the program's growth, the security requirements of state government IT, and the multi-user concurrent access that a state-level program requires.
State government IT policy required user-level security at both the server level and the database level. The system was built so that access permissions reflected the regulatory roles inside the program: licensing examiners, training coordinators, fee processors, and supervisory staff each saw the data and operations relevant to their role. The security model held up to the audit requirements that state government IT operates under.
State-issued pesticide licenses and certifications require physical printed documents on specific paper stock with specific drivers and software. The system integrated with the specialty printers and print drivers the program already operated. Issuing a printed license at the end of a successful certification cycle became a one-click operation rather than a multi-step manual process.
Payment processing, renewal fee accounting, and notifications to management of problem areas were added to the consolidated platform. The financial side of the licensing function, which had previously been disconnected from the records side, now lived in the same system as the licensing data. Management received automated notifications when records flagged issues that required supervisor attention rather than waiting for staff to identify and escalate them manually.
State government licensing programs fail their data infrastructure in a specific way. The work grew over years. The Access databases were the right tool when the program was smaller. As the program added regulatory categories, license types, and operational complexity, what had started as one database became two, then three, then four. Each one made sense at the time it was added. The failure was not architectural malpractice. It was the cumulative weight of incremental decisions, each one rational, that produced an unmanageable whole. The consolidation did not require throwing out the work that had been done. It required mapping the whole and rebuilding the foundation underneath it.
The decision to keep the Access front-end while migrating the data layer to SQL Server was deliberate. State government staff using the system every day already knew the Access interface. Replacing the front-end would have introduced a training burden the program could not absorb without operational disruption. Migrating the back-end to SQL Server delivered the security, scale, and concurrent access the state required while preserving the working environment staff depended on. The architectural choice respected the operational reality of a working state program.
What changed after the consolidated system went into production?
The most immediate change was that the program stopped operating across four databases that did not agree with each other. One licensee record meant one record, not four versions of one record with different statuses depending on which database staff happened to check. Reconciliation work that had absorbed staff time disappeared because the records reconciled by construction. The licensing program could focus on the regulatory work it existed to do rather than maintaining the infrastructure that supported it.
| Outcome | Result | How it was achieved |
|---|---|---|
| Data integrity across the program | Single source of record | Four Access databases consolidated to one SQL Server platform with zero data loss |
| Duplicate records across systems | Eliminated | Cross-database deduplication during migration; enforced uniqueness in consolidated schema |
| State government security compliance | Met at server and database level | User-level securities aligned with regulatory roles and state IT policy requirements |
| License and certification printing | One-click issuance | Specialty printer and driver integration tied directly to certification record |
| Payment and renewal fee accounting | Integrated with licensing data | Financial side of the program merged with the records side in the consolidated platform |
| Management visibility into problem areas | Automated notifications | System flagged issues to management as they occurred rather than waiting for manual escalation |
The strategic value of the consolidation extended beyond the immediate operational improvements. Once the program operated on one platform with one source of truth, regulatory updates became one update rather than four. New license categories could be added to the schema without rebuilding the underlying architecture. The infrastructure was prepared for the next decade of program evolution rather than carrying the technical debt of four databases that had grown apart over time.
What capabilities does this kind of system provide for state regulatory programs?
The infrastructure built for this state pesticide licensing program addresses a problem class that appears across every state-level regulatory operation that has accumulated multiple legacy databases over years of program growth. The capabilities below apply to state pesticide control, professional licensing boards, environmental permitting agencies, occupational health programs, and any state regulatory function where multi-database consolidation, security compliance, and operational continuity all have to happen at the same time.
Years of operational records merged into one platform with full deduplication, reconciliation, and validation. The historical record the program has built up is preserved completely rather than degraded or partially abandoned during the migration.
Staff continue working in the interface they already know while the data layer moves to a server-class platform that meets state IT security and scale requirements. Operational disruption during the transition is minimized rather than absorbed by the program.
Access permissions reflect the actual roles inside the program: examiners, processors, schedulers, supervisors. The security model meets state IT audit requirements and the operational reality of how the program runs.
Payment processing, renewal fee accounting, license issuance, and management notifications operate as one system. The disconnects that produce missed renewals, lost fees, and escalation delays disappear when the financial and records sides share infrastructure.
Technology stack
| Component | Technology |
|---|---|
| Database back-end | Microsoft SQL Server with state government security configuration |
| Application front-end | Microsoft Access connected to SQL Server back-end |
| Migration | Multi-database merge with cross-database deduplication and validation |
| Security | User-level security at both server and database tiers; role-based access |
| Printing integration | Specialty printer drivers and print software for licenses and certifications |
| Financial layer | Payment processing and renewal fee accounting integrated with licensing records |
| Notifications | Automated alerts to management on flagged records and exception conditions |
Does this apply if your program is smaller than a state pesticide licensing operation?
The architecture scales down as well as up. A county-level regulatory program, a smaller state professional licensing board, a private trade association managing certifications, or any program that has accumulated multiple databases over years faces the same core problems as this state pesticide licensing operation: duplicate records across systems, regulatory updates that require parallel maintenance, security requirements that legacy architectures struggle to meet, and operational disruption risk that prevents the program from modernizing on its own. The engineering decisions on this project, particularly the front-end continuity approach and the multi-database merge methodology, are directly applicable to programs of any regulatory scale.
What makes this project transferable is not the size of the program. It is the problem class. Any regulatory licensing operation running on multiple legacy databases is carrying the same technical debt this state pesticide program was carrying before the consolidation. The debt accumulates invisibly until staff turnover removes the institutional knowledge of which database has the right answer, until a security audit surfaces gaps that the legacy architecture cannot close, or until a regulatory update requires changes the existing system cannot absorb cleanly.
PCG has built licensing, credentialing, and regulatory compliance infrastructure for state government programs and private regulatory bodies since 1995. The work documented here is one of more than 500 production applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years.
Frequently asked questions about pesticide licensing and state regulatory compliance systems
Allison has been building custom software since the early 1980s, including work as a data analyst for the U.S. Air Force before founding PCG in 1995. The pesticide licensing compliance work documented here is one of more than 500 custom applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years. Her direct involvement in every project is not a policy. It is how PCG operates. When you call, she answers.
Project details documented with client permission. Specific identifying details about the state pesticide licensing program have been generalized. System capabilities and architecture reflect the actual production deployment.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding.
What was breaking in the refinery's Title V permit application before this project?
An EPA Title V Clean Air Act permit for an oil refinery emissions upgrade is not a form submission. It is a documented proof of compliance built on tens of thousands of calculations covering emissions rates, standard deviations, and modeled scenarios that demonstrate the facility can meet the regulatory requirements it is applying to operate under. Every number in that proof has to be defensible, traceable to its source data, and reproducible on demand if a regulator questions it during application review.
The client was a Fortune 100 oil refinery preparing a Title V application for an emissions upgrade. The calculations required for the permit lived across spreadsheets, engineering documents, and disconnected files. Worst-case and best-case scenario modeling required for the case proofs depended on manual rebuilds of formulas every time inputs changed. The audit trail that EPA reviewers expect to see was not centralized. For a permit application of this scale and consequence, that infrastructure was not adequate to the regulatory burden.
For a Fortune 100 oil refinery, the consequences of a delayed or denied Title V application extend across the operation. Capital projects waiting on the permit cannot proceed. Production planning depends on the operational envelope the permit defines. Insurance, contracts, and downstream commitments all reference the regulatory standing of the facility. A Title V application built on infrastructure that cannot defend its own outputs is a risk multiplier across every business function the refinery touches.
What did PCG actually build for the Title V air quality environment?
PCG worked directly with refinery engineers, plant managers, compliance officers, and regulatory officials to map exactly what the permit application required and what the post-approval reporting cycle would demand. That direct engagement with the people who understood the regulatory framework was the only way to build a system where calculation outputs would hold up to EPA review and the audit trail would survive regulator inspection. Each component was built so that the integrity expected of a Fortune 100 permit submission was preserved at every layer.
The system integrated Microsoft Excel Solver as the real-time calculation engine for emissions rates, standard deviations, and scenario modeling. Solver handled the optimization-heavy computations the permit required while the surrounding application managed inputs, outputs, and version control. Calculations that had previously been built and rebuilt in standalone spreadsheets ran inside a controlled environment with traceable logic.
Every piece of source data that entered the system was stored in Microsoft Access with a complete chain of custody: when the data was entered, who entered it, where it came from, and how it had been used in subsequent calculations. The audit trail required for Title V review was captured automatically rather than reconstructed during the permit submission process.
EPA Title V applications require demonstrated case proofs across operational scenarios. The system included a scenario building tool that allowed compliance officers to construct, document, and store the worst-case and best-case emissions scenarios the application demanded. Each scenario was tied to its underlying calculations, so reviewers could trace any number in the application back to the inputs and logic that produced it.
The system included calculation integrity verification to confirm that the same input produced the same output across the application's lifecycle. For a regulatory document where reproducibility is a core review criterion, the verification layer was non-negotiable. EPA reviewers asking "show me how this number was produced" got a deterministic answer rather than an explanation that depended on remembering which spreadsheet version had been used.
The system was built to produce both the documentation formats required for the Title V application and the ongoing compliance reports DEP and EPA would require after the permit was issued. When the permit was approved, the same system that supported the application became the compliance tracking platform for the facility's continuing obligations. The application work and the operational compliance work shared one infrastructure.
A Title V permit application is not a documentation problem in the conventional sense. It is a calculation integrity problem. EPA reviewers do not primarily ask whether the operator has the right narrative around its emissions. They ask whether the numbers in the application are produced by a process that can be reproduced, audited, and defended. A spreadsheet-based application can technically contain the right numbers and still fail review because the path from source data to reported output is not traceable. The system PCG built closed that gap by making every number in the submission a query result rather than an artifact.
The decision to integrate Excel Solver as the calculation engine, rather than rebuilding the calculation logic from scratch in another platform, was deliberate. Solver had decades of validated use in emissions optimization work. Refinery engineers and compliance officers already understood it. Replacing it would have introduced a new validation burden for no compliance benefit. Wrapping Solver in a controlled application environment with proper data storage and audit trail produced a system that combined familiar calculation logic with the regulatory infrastructure the permit required.
What changed after the Title V system went into production?
The most consequential outcome was the permit approval itself. The Title V application produced by the system passed EPA review and the refinery received the Clean Air Act permit for its emissions upgrade. Beyond that single result, the system became the operating compliance platform for the facility's ongoing Title V obligations rather than being decommissioned at the end of the application cycle.
| Outcome | Result | How it was achieved |
|---|---|---|
| Title V Clean Air Act permit application | Approved | Application built on calculation integrity, scenario modeling, and audit trail at the standard EPA review requires |
| Calculation integrity across the application | Reproducible and auditable | Excel Solver integrated as controlled calculation engine with verification layer |
| Source data audit trail | Complete chain of custody | Microsoft Access database captured every input with user, timestamp, source, and downstream usage |
| Scenario modeling for case proofs | Documented and traceable | Scenario building tool stored worst-case and best-case scenarios linked to underlying calculations |
| Ongoing DEP and EPA reporting | Built into the same system | Post-approval compliance reporting produced as queries against the live application data |
| Time from input change to updated output | Real-time | Solver-driven recalculation eliminated manual formula rebuilds for scenario updates |
The strategic value of the system extended beyond the immediate permit approval. Once the calculation engine, audit trail, and reporting layer existed inside one controlled platform, the refinery's compliance posture against future regulatory changes improved structurally. Subsequent Title V renewals, modifications, and amendments could be supported by the same system rather than initiating new spreadsheet-based application cycles each time.
What capabilities does this kind of system provide for Clean Air Act compliance?
The infrastructure built for this Fortune 100 oil refinery addresses a problem class that appears across every regulated industrial operation under EPA Title V or comparable air quality permitting. The capabilities below apply to oil and gas refining, chemical manufacturing, power generation, cement and aggregate production, primary metals, and any operation where emissions calculations, scenario modeling, and audit-defensible reporting are part of the regulatory framework the operation runs under.
Tens of thousands of emissions calculations executed inside a controlled environment with traceable logic and reproducible outputs. Solver-based optimization wrapped in an application layer that preserves the audit trail EPA review requires.
Scenario building tool for the case proofs Title V applications require, with each scenario linked to underlying calculations. Reviewers asking how a specific projection was produced get a traceable answer rather than a reconstructed explanation.
Every input captured with user, timestamp, source, and downstream usage. The audit trail EPA expects during permit review and during post-approval inspections is preserved automatically rather than assembled retroactively from disconnected files.
The same system that supports the Title V application becomes the operational compliance tracking platform after permit approval. DEP and EPA reporting cycles run on the live data the application was built from rather than requiring separate reporting infrastructure.
Technology stack
| Component | Technology |
|---|---|
| Calculation engine | Microsoft Excel with Solver integration for emissions optimization |
| Database layer | Microsoft Access with Visual Basic for Applications (VBA) |
| Email and notifications | Exchange Server / Outlook integration |
| Audit trail | User, timestamp, source, and downstream usage captured per input |
| Scenario modeling | Worst-case and best-case scenario builder linked to underlying calculations |
| Calculation integrity | Verification layer for reproducibility across the application lifecycle |
| Regulatory framework | EPA Title V Clean Air Act with DEP reporting alignment |
Does this apply if your operation is smaller than a Fortune 100 oil refinery?
The architecture scales down as well as up. A regional industrial operator preparing a Title V application or operating under an existing Title V permit faces the same core problems as a Fortune 100 refinery: emissions calculations spread across spreadsheets, scenario modeling that requires manual rebuilds, audit trails that have to be reconstructed at the time of regulator inquiry, and reporting cycles that consume compliance staff time better spent on the actual operational work. The engineering decisions on this project, particularly the Excel Solver integration and the Access-based audit trail, transfer directly to operations of any industrial scale.
What makes this project transferable is not the size of the operation. It is the problem class. Any operation under EPA Title V, comparable state air quality permitting, or related Clean Air Act obligations is carrying the same calculation integrity risk this refinery was carrying before the system went live. The risk surfaces during permit applications, during renewals, during compliance audits, and during enforcement actions. A system that captures source data, runs calculations through a controlled engine, and preserves the audit trail automatically changes the operator's relationship with the regulator from defensive reconstruction to proactive readiness.
PCG has built EPA, DEP, and air quality compliance infrastructure for Fortune 100 and mid-market operators since 1995. The work documented here is one of more than 500 production applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years.
Frequently asked questions about EPA Title V air quality management systems
Allison has been building custom software since the early 1980s, including work as a data analyst for the U.S. Air Force before founding PCG in 1995. The Title V air quality management work documented here is one of more than 500 custom applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years. Her direct involvement in every project is not a policy. It is how PCG operates. When you call, she answers.
Project details documented with client permission. Specific identifying details about the Fortune 100 oil refinery have been generalized at client request. System capabilities and outcomes reflect the actual production deployment.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding.
What was breaking in vineyard pest monitoring before this project?
The client was a commercial grape farm operating an active invasive species management program across a working vineyard. Insect traps were deployed across the property to monitor for regulated pests that threaten commercial viticulture. The trap network captured data continuously, but the records lived in field notebooks, spreadsheets, and disconnected files. When a pattern emerged that suggested invasive pest pressure at a particular section of the vineyard, the response depended on someone manually piecing together which traps had caught which species at which locations across multiple weeks of records.
That is not a record-keeping inconvenience. Commercial vineyards operate under regulatory frameworks administered by USDA APHIS and state departments of agriculture. Growers must monitor for and report findings of regulated invasive pests including the Spotted Lanternfly, Glassy-Winged Sharpshooter, European Grapevine Moth, and other quarantine-listed species. Trap data underlies grower compliance with quarantine zones, pesticide application justifications, and inter-state shipping certifications for agricultural products. A vineyard that cannot quickly produce a defensible trap monitoring record is carrying compliance risk that affects its ability to ship product across state lines.
For a commercial vineyard under invasive species pressure, the consequences of weak trap monitoring infrastructure compound across every season. A Spotted Lanternfly population can establish in a single growing season if not detected and responded to early. Quarantine zone violations affect the entire operation, not just the field where a regulated pest was found. The cost of a delayed response measured in compliance terms is large enough that monitoring infrastructure pays for itself in the first season it prevents an undetected establishment.
What did PCG actually build for the vineyard pest monitoring environment?
PCG developed a database application designed around the operational reality of insect trap monitoring in a working vineyard. The architecture handled trap lots, physical locations across the property, the species captured at each location, and the historical record of captures over time. Each component was built so that the data field staff captured during routine trap servicing became immediately useful for both operational pest response and regulatory reporting.
Every trap deployed across the vineyard was logged with its lot number, physical location, deployment date, and trap type. The system handled the relationship between trap lots and the specific sites where each trap was placed, which is the foundational record for any subsequent species capture data.
Field servicing of each trap produced a record of which insect species were captured. The system structured this data by trap, by site, and by date, so the question of which species had been caught at which location during which time window became a query rather than a reconstruction.
The system supported targeted searches and reports designed to surface infestation patterns: rising capture counts at specific locations, spread across adjacent sites, and species shifts that suggested new pest pressure entering the property. Patterns that previously required manual review across weeks of records emerged as system output.
The data structure was designed around the entities USDA APHIS and state departments of agriculture ask about during pest surveillance reporting: regulated species detected, locations of detection, dates, response actions taken, and historical context. Reporting became data extracts from the live system rather than manual assembly from field notebooks.
When a pattern indicated the need for a pest response, whether targeted pesticide application or expanded trap deployment, the system provided the historical context the response required: prior capture data at the affected sites, response actions previously taken, and the species-specific patterns that had emerged. The pesticide application justification record that regulators expect was assembled from live data rather than reconstructed.
Vineyard pest monitoring fails in a specific way. Traps are deployed. Field staff service them on schedule. Species are recorded. The data exists. What does not exist, until someone takes the time to assemble it manually, is the cross-site, cross-species, cross-time pattern view that turns trap records into actionable pest intelligence. A system that performs that assembly automatically transforms the operator's relationship with invasive species pressure. The vineyard moves from reactive, where infestations surface after they have established, to proactive, where rising pressure at specific sites is visible while there is still time to respond.
The decision to structure the data around the entities regulators actually ask about, rather than the entities convenient for field staff data entry, was deliberate. USDA APHIS reporting, quarantine zone compliance, and inter-state shipping certifications all reference specific species, specific dates, specific locations, and specific response actions. A database that captures field data in those terms produces compliance reports as queries rather than translations. The same field servicing that supports operational pest management also produces the regulatory record the operation needs to ship product.
What changed after the system went into production?
The most immediate change was that infestation patterns became visible to the vineyard operations team continuously, not at retrospective review. Rising capture counts at specific locations, spread of regulated species across adjacent sites, and shifts in pest pressure surfaced as system output rather than emerging from manual review of accumulated records. Field staff continued the routine trap servicing they had always done. The data those routines produced became immediately useful for decisions that previously waited for someone to assemble the picture.
| Outcome | Result | How it was achieved |
|---|---|---|
| Trap and species data integrity | Single source of record | Database architecture with enforced relationships between traps, locations, and species captures |
| Infestation pattern recognition | Surfaced automatically | Targeted searches and reports designed around invasive species pressure indicators |
| Regulatory reporting timeline | Data extracts, not assembly | USDA APHIS-aligned data structure produced reports as queries against live data |
| Pest response decision support | Historical context on demand | Prior capture data, previous response actions, and species patterns available immediately |
| Inter-state shipping certifications | Defensible trap monitoring record | Structured pest surveillance data ready for state agriculture department review |
| Pesticide application justification | Trap data linked to action | Application records tied to the trap data that justified the response |
The strategic value of the system extended beyond the immediate pest response cycle. Once trap data was structured and queryable across the full vineyard, season-over-season comparisons became possible: the same sites that showed pressure last year, the species shifts that had occurred over multiple growing seasons, and the response patterns that had been most effective. The vineyard gained the kind of historical pest intelligence that informs not just this season's response but the multi-year management strategy.
What capabilities does this kind of system provide for agricultural pest monitoring?
The infrastructure built for this commercial vineyard addresses a problem class that appears across every agricultural operation under invasive species pressure or USDA APHIS reporting obligations. The capabilities below apply to vineyards, orchards, specialty crop farms, nursery and ornamental operations, agricultural cooperatives, university extension monitoring programs, and any operation where insect trap data must be tracked for both operational pest response and regulatory compliance.
One database structure containing the complete record of trap lots, physical locations, species captures, and dates. Cross-trap and cross-site queries answer pest intelligence questions that previously required manual reconstruction across notebooks and spreadsheets.
Data structure designed around the entities regulators ask about: regulated species, detection locations, dates, and response actions. Pest surveillance reports become data extracts from the live system rather than manual assembly from field records.
Targeted searches that surface rising capture counts at specific locations, species spread across adjacent sites, and pressure shifts that signal new pest activity. Patterns that had been invisible in week-by-week records appear as system output.
The trap data that justifies pesticide applications and supports inter-state shipping certifications is captured at the moment of field servicing and structured for the format regulators require. Compliance documentation produces itself rather than being assembled retroactively.
Technology stack
| Component | Technology |
|---|---|
| Database layer | Structured relational storage for trap, location, and species data |
| Data structure | Trap lots, physical locations, species captures, dates, and response actions |
| Pattern detection | Targeted searches for infestation pressure indicators across sites and species |
| Field data capture | Trap servicing records with species, count, and location |
| Regulatory framework | USDA APHIS and state department of agriculture reporting alignment |
| Compliance support | Quarantine zone, pesticide application, and shipping certification record support |
| Historical analysis | Season-over-season comparison and multi-year pest pressure tracking |
Does this apply if your operation is smaller than a commercial vineyard?
The architecture scales down as well as up. A small specialty crop farm with a handful of monitoring sites faces the same core problems as a commercial vineyard: trap records spread across notebooks, infestation patterns invisible in static data, regulatory reporting that consumes time better spent on the actual pest management work, and certifications that require records the operation cannot quickly produce. The engineering decisions on this project, particularly the trap-location-species data structure and the USDA APHIS-aligned reporting layer, transfer directly to operations of any agricultural scale.
What makes this project transferable is not the size of the operation. It is the problem class. Any agricultural operation under invasive species pressure or USDA APHIS reporting obligations is carrying the same data interpretation risk this vineyard was carrying before the system went live. The risk accumulates invisibly until a regulated species establishes a population that requires expanded response, a quarantine zone violation surfaces from data that should have shown the pattern earlier, or an inter-state shipping certification is delayed because the supporting trap monitoring record cannot be produced in the format the receiving state requires.
PCG has built agricultural and environmental compliance infrastructure for operators, agricultural service companies, and regulated sites since 1995. The work documented here is one of more than 500 production applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years.
Frequently asked questions about agricultural pest monitoring and trap management systems
Allison has been building custom software since the early 1980s, including work as a data analyst for the U.S. Air Force before founding PCG in 1995. The agricultural pest monitoring work documented here is one of more than 500 custom applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years. Her direct involvement in every project is not a policy. It is how PCG operates. When you call, she answers.
Project details documented with client permission. Specific identifying details about the commercial grape farm have been generalized. System capabilities and architecture reflect the actual production deployment.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding.
What was breaking in ground water monitoring before this project?
The client was an environmental compliance company managing ongoing ground water monitoring obligations at a regulated site. Ground water monitoring is not a one-time activity. It is a continuous data capture exercise across multiple monitoring stations, with sampling cycles that produce thousands of readings over the life of a site. The compliance question is not whether a single reading is in or out of range. It is whether the trend across readings shows movement that requires regulatory notification, additional investigation, or corrective action.
Spreadsheets and disconnected lab reports do not answer that question. They contain the data, but the trend is invisible until someone manually plots the readings and looks at the chart. By the time a problematic trend is visible to a human reading static reports, the regulator may already be entitled to a notification the client did not know to send. For an environmental compliance company whose entire value to its clients depends on staying ahead of contamination patterns, that delay is not an inconvenience. It is a credibility problem with the regulator and the client at the same time.
For an environmental compliance company, the consequences of weak ground water monitoring infrastructure compound across every site under management. Regulators expect notification of exceedances within defined windows. Corrective action timelines depend on how quickly a trend was identified. Liability for missed reporting falls on the compliance company, not just the site owner. A system that cannot surface trends until someone looks for them is a continuous risk multiplier across the company's full portfolio of sites.
What did PCG actually build for the ground water monitoring environment?
PCG developed a ground water monitoring application built around two capabilities the client did not have before: time-series charting of well readings, and targeted data searches that surfaced anomalies across monitoring stations. The architecture was designed so that the data captured during routine sampling cycles became immediately useful for trend analysis rather than sitting in static reports until someone investigated. Each component was built so that the visibility regulators expect was available continuously rather than reconstructed at reporting time.
Every reading from every monitoring station was captured into a structured database with the analyte tested, the result, the date, the sampling method, and the lab. The same data structure handled readings from across all stations on the site, which was the prerequisite for any cross-station trend analysis.
The application produced plotted charts of well readings over time, station by station and analyte by analyte. Trends that had been invisible in tabular reports became immediately visible as line charts. Movement in contamination levels, seasonal patterns, and slow drifts toward action levels were apparent at a glance rather than requiring manual analysis.
The system supported targeted searches designed to surface anomalies across monitoring stations: readings outside expected ranges, sudden shifts in trend slope, and patterns that crossed multiple stations in ways that suggested plume movement or a new contamination source. The searches were configured around the analytes and thresholds the client tracked under its regulatory obligations.
Patterns that crossed multiple monitoring stations were surfaced in the same interface as single-station trends. A contamination plume moving across the site, or a treatment system losing effectiveness affecting multiple wells, became visible as a coordinated pattern rather than a series of isolated readings that each looked acceptable in isolation.
When a trend or anomaly required regulatory notification, additional sampling, or corrective action, the system produced the historical context the response required: prior readings, previous similar patterns, dates of related actions taken at the site. The data trail for any notification or response was assembled from live system data rather than reconstructed from spreadsheets and email archives.
Ground water monitoring fails in a specific way. The data is captured. The lab reports are filed. The spreadsheets are updated. What does not happen, until someone takes the time to do it manually, is the conversion of that data into the visual form that makes trends and anomalies obvious. A system that performs that conversion automatically, on every reading, transforms the operator's relationship with the data. The compliance company is no longer reactive to what the regulator surfaces during inspection. It is proactive about what it sees in its own monitoring before the regulator sees it.
The targeted search capability was the part that created the most strategic value beyond the routine charting. Anomalies in ground water data are often not in the most recent reading. They are in the pattern that emerges when readings are compared across stations, across analytes, or across time windows. A search interface configured around the regulatory thresholds the operator tracks surfaces those patterns as queryable findings rather than pattern-recognition exercises that depend on the analyst remembering to look.
What changed after the system went into production?
The most immediate change was that contamination trends became visible to the compliance team continuously, not at reporting cycles. Patterns that had previously emerged only when someone built a chart for an investigation surfaced as standard outputs of the monitoring workflow. The team's effort moved from chart-building during investigations to acting on the information the live system was already showing them.
| Outcome | Result | How it was achieved |
|---|---|---|
| Trend visibility across well data | Continuous, not periodic | Time-series charting produced automatically from every captured reading |
| Anomaly detection across stations | Targeted searches | Configured search interface surfaced cross-station outliers and pattern shifts |
| Response time to potential exceedances | Hours, not reporting cycles | Patterns visible immediately rather than emerging from manual chart-building during investigations |
| Regulatory notification readiness | Pre-emptive | Data trail assembled from live system rather than reconstructed from disconnected sources |
| Cross-station pattern recognition | Surfaced automatically | Coordinated patterns across multiple wells visible as system output rather than analyst pattern-matching |
| Investigation lead time | Reduced by visibility, not by faster searching | Trends apparent before investigation began, replacing reactive analysis with proactive review |
The strategic value of the system extended beyond the immediate site. Once the compliance team had a working framework for time-series visualization and anomaly detection on ground water data, the same architecture was applicable to other monitored sites in the company's portfolio. The investment in this site became the template for the company's monitoring infrastructure across its broader client base.
What capabilities does this kind of system provide for environmental compliance operations?
The infrastructure built for this environmental compliance company addresses a problem class that appears across every operation responsible for ongoing environmental monitoring under regulatory oversight. The capabilities below apply to ground water monitoring under RCRA corrective action, CERCLA Superfund sites, NPDES discharge permits, brownfield post-cleanup monitoring, mining operations, landfills, and any regulated environment where time-series data must be analyzed for trends and anomalies on a continuous basis.
Well data, discharge data, or any monitoring readings plotted automatically as they are captured. Trends are visible continuously rather than emerging only when an analyst builds a chart for an investigation. Patterns that develop slowly over months become apparent before they reach action levels.
Configurable searches that surface readings outside expected ranges, sudden shifts in trend slope, and coordinated patterns across multiple monitoring stations. The same search framework supports investigations into specific suspected issues and routine periodic reviews of the full data set.
Patterns that move across multiple monitoring stations surfaced as coordinated findings rather than isolated readings. Plume movement, treatment system failures, and contamination source shifts visible as system output rather than analyst inference from disconnected reports.
The historical context required for regulatory notification, additional sampling, or corrective action assembled from live system data rather than reconstructed at the moment a response is required. Notification windows that depend on quick situational awareness are met because the awareness is continuous.
Technology stack
| Component | Technology |
|---|---|
| Database layer | Structured relational storage for time-series well reading data |
| Charting engine | Time-series visualization for well readings by station and analyte |
| Anomaly detection | Targeted data search across stations with configurable thresholds |
| Data structure | Reading-level capture with analyte, result, date, station, sampling method, and lab |
| Cross-station analysis | Pattern recognition across multiple monitoring wells on the same site |
| Regulatory framework | RCRA, CERCLA, NPDES alignment configurable per site obligations |
| Reporting layer | Historical context extracts for regulatory notifications and investigations |
Does this apply if your operation manages fewer than the multi-site portfolio of an environmental compliance firm?
The architecture scales down as well as up. A single-site industrial operator with ground water monitoring obligations under a state permit faces the same core problems as an environmental compliance company managing a portfolio of regulated sites: trends invisible in static data, anomalies detected only when someone looks for them, and exceedances that surface too late for proactive response. The engineering decisions on this project, particularly the time-series charting and targeted anomaly search, transfer directly to operations with as few as one monitoring site.
What makes this project transferable is not the size of the portfolio. It is the problem class. Any operation responsible for continuous environmental monitoring under regulatory oversight is carrying the same data interpretation risk this client was carrying before the system went live. The risk accumulates invisibly until a regulator asks a question the data could have answered earlier, an enforcement action surfaces a trend the operator should have caught, or an investigation timeline reveals that the warning signs were in the data months before anyone noticed.
PCG has built environmental monitoring and compliance infrastructure for industrial operators, environmental consulting firms, and regulated sites since 1995. The work documented here is one of more than 500 production applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years.
Frequently asked questions about ground water monitoring and charting systems
Allison has been building custom software since the early 1980s, including work as a data analyst for the U.S. Air Force before founding PCG in 1995. The ground water monitoring system documented here is one of more than 500 custom applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years. Her direct involvement in every project is not a policy. It is how PCG operates. When you call, she answers.
Project details documented with client permission. Specific identifying details about the environmental compliance company and the monitored site have been generalized. System capabilities and architecture reflect the actual production deployment.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding.
What was breaking in the facility's OSHA training compliance before this project?
The client was operating a Fortune 500 oil and gas chemical processing facility with an outdated OSHA training management system. The legacy system could record attendance at training sessions but could not reliably flag certification gaps, manage instructor qualifications, or produce the documentation that government agencies and internal supervisory staff required during audits and incident reviews. In a volatile oil and gas chemical processing environment, an employee who has not completed required OSHA training is a liability, not just a compliance gap.
The complexity went beyond OSHA itself. The facility had to handle internal corporate training policies on top of federal OSHA requirements, including specialized training curricula, secured testing, grading, certification hard copies, continuing education credits for instructors, and classroom scheduling across multiple facility locations. The most consequential requirement was the badge management integration. An employee whose certifications had lapsed needed to be physically prevented from entering restricted areas, which meant the training database had to connect directly to the facility's access control system rather than living as a separate compliance record.
For a Fortune 500 oil and gas operator, the consequences of an OSHA finding extend beyond the citation itself. Regulatory violations affect contract eligibility with government and corporate customers, raise insurance premiums, and create reportable incidents that follow the operation through subsequent audits. A training management system that could not flag gaps before they surfaced as violations was a continuous risk multiplier for the facility.
What did PCG actually build for the OSHA training and certification environment?
PCG built a unified training management platform in Microsoft Access with VBA, sectioned into the major functional areas that trainers and administrators needed to operate independently. The interface was designed for non-technical staff, which mattered in an environment where the people using the system every day were safety professionals and training coordinators, not database administrators. Each component was built so that the OSHA documentation required by auditors was captured at the moment training happened rather than reconstructed afterward.
Every employee's certification status was tracked across the full set of OSHA-required training categories applicable to oil and gas chemical processing. Records included the date of training, the instructor, the test results, the certification expiration date, and the audit trail of recertifications. When a certification lapsed or a mandatory training session was missed, the system flagged it automatically and notified the relevant supervisors.
Instructor qualifications were tracked as a separate module, covering qualifications to teach specific courses, continuing education credits, and curriculum certifications. An instructor whose credentials had lapsed could not be scheduled for a course they were no longer qualified to teach. For OSHA compliance purposes, the qualifications of the instructor delivering the training are part of the audit record, not just the attendance of the employees receiving it.
Class schedules, classroom locations, and facility utilization were managed within the same system. Sessions were scheduled against instructor availability, classroom capacity, and the certification deadlines of the employees who needed each training. Equipment inventory required for hands-on training modules was tracked alongside the schedule.
The training database was connected directly to the facility's badge management system. Employees whose certifications were not current were automatically blocked from accessing restricted areas of the facility. The training record and the physical access control became the same operational system. An employee with lapsed training could not simply walk past a turnstile because the badge system already knew about the lapse.
The system generated automated alerts for compliance gaps, expired certifications, failed tests requiring remediation, and upcoming recertification deadlines. Mass email handled scheduling announcements and sign-off sheet distribution for attendance records. OSHA audit documentation was produced as structured queries against the live system rather than manually assembled from filing cabinets at the moment of inspection.
OSHA compliance in a Fortune 500 oil and gas environment is not primarily a documentation problem. It is an enforcement problem. The question is not whether the operator can produce a training record on demand, but whether the operator can prevent an uncertified employee from physically being in a place where regulations say they should not be. Training records that live separately from physical access control depend on human enforcement at every entry point, which means they fail eventually. Training records connected to badge access enforce themselves automatically and continuously.
The decision to build in Microsoft Access with VBA, rather than a heavier platform, was deliberate for this client. The facility had existing IT infrastructure, internal staff capable of supporting Access systems, and a requirement that the interface be operable by safety professionals without database training. A purpose-built application in Access with VBA delivered the integration and automation the facility needed at a fraction of the cost and time of a packaged enterprise EHS platform, and it integrated directly with the badge system the facility already operated.
What changed after the system went into production?
The most immediate operational change was that compliance gaps stopped requiring human discovery. The system surfaced expired certifications, missed training, and instructor credential lapses automatically, before they became OSHA violations. The facility moved from a reactive posture, where gaps were found during audits or incidents, to a continuous enforcement posture where gaps could not be ignored because the badge system would not let the employee into the restricted area until the gap was closed.
| Outcome | Result | How it was achieved |
|---|---|---|
| Training efficiency rating | 100% | Automated gap detection, scheduling against deadlines, and instructor credential validation |
| Paper filing position | Eliminated (1 FTE) | Automated documentation capture replaced manual filing of certifications and attendance records |
| OSHA audit response | Structured queries, not file searches | Live system data replaced filing cabinet retrieval during inspections and reviews |
| Restricted area access enforcement | Automatic and continuous | Badge system integration physically prevented entry by employees with lapsed certifications |
| Compliance gap detection | Real-time | Automated alerts to supervisors as gaps occurred, not after they became violations |
| Instructor credential validation | Enforced at scheduling | Lapsed instructor credentials prevented scheduling for courses no longer qualified to teach |
The strategic value of the system extended beyond the OSHA compliance posture itself. The facility's ability to demonstrate continuous training enforcement and audit-ready documentation became a credential in its own right with corporate customers, government contractors, and insurance underwriters. Operations that had previously absorbed the cost of dedicated paper-filing staff and manual gap reviews redirected that capacity toward the actual safety work the facility existed to do.
What capabilities does this kind of system provide for industrial safety operations?
The infrastructure built for this Fortune 500 oil and gas facility addresses a problem class that appears across every regulated industrial operation with OSHA training obligations. The capabilities below apply to oil and gas, chemical processing, manufacturing, mining, construction, environmental services, and any operation where worker certification is a continuous regulatory requirement and where uncertified workers in the wrong place create real liability.
Training records connected directly to badge management or facility access control. Employees whose certifications lapse are automatically prevented from entering restricted areas, removing the dependency on human enforcement at every entry point.
Expired certifications, missed mandatory training, failed tests, and upcoming recertification deadlines flagged automatically as they occur. Supervisors receive alerts in real time rather than discovering gaps during audits or after incidents.
Instructor qualifications, continuing education credits, and curriculum certifications tracked as part of the same system. Instructors with lapsed credentials cannot be scheduled for courses they are no longer qualified to teach, which protects the audit value of the training itself.
OSHA inspection responses, internal audit submissions, and corporate compliance reviews answered through structured queries against the live system. The filing cabinet retrieval that consumes staff time during every audit cycle is replaced with on-demand reporting.
Technology stack
| Component | Technology |
|---|---|
| Database and application layer | Microsoft Access with Visual Basic for Applications (VBA) |
| Access control integration | Direct integration with facility badge management system |
| Training records | Employee certification, attendance, testing, and recertification tracking |
| Instructor management | Credential, qualification, continuing education, and curriculum tracking |
| Scheduling | Class schedules, classroom utilization, equipment inventory, and instructor availability |
| Alerts and notifications | Automated gap detection with email notification to supervisors |
| Mass email | Bulk notification for scheduling and sign-off sheet distribution |
| Compliance framework | OSHA training requirements with corporate policy overlay |
Does this apply if your operation is smaller than a Fortune 500 facility?
The architecture scales down as well as up. A regional industrial operator with a single facility faces the same core problems as a Fortune 500 multi-site operation: certification gaps that go undetected, training records that live separately from access control, instructor credential validation that depends on manual review, and audit response that becomes a paper-search project. The engineering decisions on this project, particularly the badge integration and the automated gap detection layer, are directly applicable to operations of any industrial scale.
What makes this project transferable is not the size of the client. It is the problem class. Any industrial operation under OSHA jurisdiction is carrying the same enforcement risk this Fortune 500 facility was carrying before the system went live. The risk accumulates invisibly until an inspector arrives, an incident occurs, or an internal audit surfaces a pattern of gaps that have been going undetected for months. A training management system that detects and prevents those gaps continuously changes the operator's relationship with OSHA from reactive to enforced.
PCG has built industrial safety and OSHA compliance infrastructure for Fortune 500 and mid-market operators since 1995. The work documented here is one of more than 500 production applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years.
Frequently asked questions about OSHA training and certification systems
Allison has been building custom software since the early 1980s, including work as a data analyst for the U.S. Air Force before founding PCG in 1995. The OSHA training and certification system documented here is one of more than 500 custom applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years. Her direct involvement in every project is not a policy. It is how PCG operates. When you call, she answers.
Project details documented with client permission. Specific identifying details about the Fortune 500 oil and gas chemical processing facility have been generalized at client request. System capabilities and outcomes reflect the actual production deployment.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding.
What was breaking in multi-office pest control reporting before this project?
The client was a multi-office pest control operation with field locations running their own data systems. Each office captured its own licensed application records, treatment histories, and regulated chemical use. When corporate needed a consolidated picture of activity across all locations, the answer was a manual roll-up process that took days and produced numbers that did not always reconcile between sources.
That is not a reporting inconvenience. Licensed pest control operations carry regulatory obligations under FIFRA and state-level pesticide control authorities. Treatment records, chemical use, and applicator licensing must be tracked at the office level and reportable at the corporate level. A multi-office operation that cannot produce a defensible consolidated report on demand is carrying compliance risk every day the regulator does not ask for the report. When the regulator does ask, the gap becomes visible immediately.
For a multi-office pest control operation, the consequences of weak data consolidation extend beyond the immediate reporting cycle. State regulators audit licensed operators on application records, chemical use, and applicator certifications. Corporate insurance underwriters review the same data. Customer contract renewals often require performance reporting that pulls from the field record. A reporting infrastructure that cannot produce these on demand creates friction at every layer of the business.
What did PCG actually build for the multi-office data consolidation?
PCG developed a data-pulling engine that connected to each field office system and consolidated activity into a centralized SQL Server repository at corporate. The architecture was designed to handle the reality that field offices ran on different systems with different data formats, and that nightly automation was preferable to disrupting daily operations at any office. Each layer was built so that the consolidation continued automatically without manual intervention from field staff or corporate IT.
The engine connected to each field office data source on a defined schedule and extracted the previous day's licensed application activity, treatment records, and chemical use data. Each office's data format was handled by a configured adapter, so adding a new office to the consolidation did not require rewriting the core engine.
All field office data flowed into a single SQL Server database structured around the entities that mattered for regulatory reporting and operational oversight: licensed applicators, treatment records, regulated chemical use, customer accounts, and office activity. The repository became the single source of truth for any question about activity across the operation.
Data pulls and consolidation ran nightly on an automated schedule. Field offices continued their daily operations on their existing systems. Corporate received fresh data every morning without anyone at any office having to remember to send a report. The automation eliminated the human step that had been the most common point of failure in the previous reporting cycle.
The system generated automated reports for corporate leadership on the consolidated data. Licensed application activity by office, regulated chemical use by category, treatment record summaries, and exception reports for unusual patterns were produced on schedule and delivered to the leadership team without manual report-building work.
The repository structure aligned with the data formats that state pesticide control authorities and FIFRA-related federal reporting required. When a regulator requested records, the response was a structured query against the consolidated database rather than a multi-office data assembly project. The same data that ran corporate reporting also drove regulatory submissions.
Multi-office pest control operations fail their reporting obligations in a specific way. The data exists. It exists at every office. What does not exist is the infrastructure to pull it together on a schedule that matches the cycle the regulator and corporate leadership expect. The data-pulling engine was the part that solved the actual problem, more than any single dashboard or report. Once the data flowed automatically, the reports built themselves.
The decision to leave field offices on their existing systems was deliberate. Forcing every office to migrate to a single corporate platform would have triggered resistance, training cost, and operational disruption that the client could not absorb. Building a consolidation layer above the existing systems delivered the corporate reporting capability without disrupting the field. That architectural call made the difference between a project that shipped and a project that would have stalled at office adoption.
What changed after the system went into production?
The most immediate change was the elimination of manual roll-up reporting. Corporate leadership stopped waiting for field offices to send numbers and started reading dashboards that updated overnight. The reconciliation gaps that had existed between office spreadsheets disappeared because the data was now flowing from a single repository.
| Outcome | Result | How it was achieved |
|---|---|---|
| Corporate reporting cycle | Nightly, automated | Scheduled data-pulling engine replaced manual roll-ups from field offices |
| Single source of truth for activity | Centralized SQL Server | All field office data consolidated into one structured repository |
| Regulatory reporting response time | Hours, not days | Structured queries against the live repository replaced multi-office data assembly |
| Field office disruption from corporate reporting | Eliminated | Offices continued on existing systems; consolidation layer ran independently |
| Reconciliation gaps between offices | Resolved at the data layer | One repository structure made cross-office numbers consistent by construction |
| Licensed application activity visibility | Real-time across all offices | Treatment records, chemical use, and applicator activity queryable from one source |
The strategic value of the system extended beyond the reporting cycle itself. Once licensed application activity was queryable across all offices in one place, patterns that had been invisible in office-by-office data became identifiable. Underperforming offices, unusual chemical use patterns, and outlier customer accounts surfaced in the data without requiring corporate analysts to build the queries that would have found them.
What capabilities does this kind of system provide for licensed multi-office operations?
The infrastructure built for this pest control operation addresses a problem class that appears across every multi-office service business under regulatory oversight. The capabilities below apply to pest control, lawn and turf services, agricultural services, environmental services, industrial cleaning, and any licensed multi-office operation where field activity must be consolidated for corporate oversight and regulatory reporting.
Field offices continue on their existing systems without disruption. A consolidation layer above those systems pulls activity into a centralized repository on a defined schedule. The corporate reporting capability arrives without forcing field office migration.
One structured repository contains the consolidated record of licensed application activity, treatment records, regulated chemical use, and customer accounts across all offices. Cross-office numbers reconcile by construction rather than by manual reconciliation.
The repository structure is designed for the format state pesticide control authorities and federal FIFRA-related reporting require. Regulator requests are answered with structured queries against live data rather than multi-office assembly projects.
Once activity is consolidated, cross-office patterns become visible: outlier chemical use, underperforming offices, customer accounts with unusual treatment histories. Patterns that were invisible in office-by-office data surface as queryable records.
Technology stack
| Component | Technology |
|---|---|
| Central repository | Microsoft SQL Server with structured schema for regulatory reporting |
| Data-pulling engine | Custom data extraction with per-office configured adapters |
| Automation | Nightly scheduled data transfers and consolidation |
| Reporting layer | Automated report generation for corporate leadership |
| Field office integration | Adapter-based connection to existing office data sources |
| Regulatory framework | FIFRA-aligned data structure for state and federal reporting |
| Audit trail | Transaction-level logging of consolidation activity and report generation |
Does this apply if your operation is smaller than a multi-state pest control company?
The architecture scales down as well as up. A regional pest control operator with 3 offices faces the same core problems as one with 30: disconnected field systems, manual roll-up reporting, reconciliation gaps between offices, and regulatory reporting that becomes a multi-office data assembly project. The engineering decisions on this project, particularly the data-pulling engine and the centralized SQL Server repository, are directly applicable to operations of any multi-office scale.
What makes this project transferable is not the size. It is the problem class. Any licensed multi-office operation under regulatory oversight is carrying the same data consolidation risk this client was carrying before the system went live. The risk accumulates invisibly until a state regulator audits the operation, an insurance underwriter reviews the file, or corporate leadership requires data that the field cannot produce on the timeline they need it.
PCG has built data consolidation and regulatory reporting infrastructure for licensed service operations since 1995. The work documented here is one of more than 500 production applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years.
Frequently asked questions about multi-office pest control reporting systems
Allison has been building custom software since the early 1980s, including work as a data analyst for the U.S. Air Force before founding PCG in 1995. The pest control reporting infrastructure documented here is one of more than 500 custom applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years. Her direct involvement in every project is not a policy. It is how PCG operates. When you call, she answers.
Project details documented with client permission. Specific identifying details about the pest control operation have been generalized. System capabilities and architecture reflect the actual production deployment.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding.
What was breaking in soil remediation tracking before this project?
The client was managing an active Superfund cleanup under EPA oversight. Federally supervised environmental remediation comes with reporting obligations that the project sponsor cannot defer or simplify. Volumes of contaminated soil removed must be documented at the cubic yard level. Source locations and destination disposal sites must be traceable for every load. Contamination testing results must link back to the specific soil they describe. And the projection of how much soil remains to be treated, which determines the timeline and cost trajectory of the entire cleanup, must be defensible to the regulator.
Spreadsheets do not survive that scrutiny. They lose data integrity as multiple people edit them. They cannot enforce relationships between source location, destination, and testing record. They produce projections that no one can audit because the formulas drift over time. For a Superfund site under active EPA supervision, that is not an inconvenience. It is a regulatory exposure that grows with every reporting cycle.
For a Superfund cleanup, the consequences of weak tracking infrastructure compound over time. EPA does not forget reporting gaps. Timeline projections that turn out to be inaccurate get challenged in subsequent reviews. Funding decisions for the remaining cleanup phases depend on the credibility of the data presented. A tracking system that cannot defend its own outputs creates problems that outlive the cleanup itself.
What did PCG actually build for the EPA Superfund tracking environment?
PCG developed a database-backed tracking system designed specifically for federally supervised soil remediation. The architecture handled the complete data chain from contaminated source through testing through disposal destination, with a forward projection engine that produced defensible estimates of remaining work. Each component was built so that the data trail required by EPA auditors was captured at the moment work happened, not reconstructed afterward.
Every cubic yard of contaminated soil removed from the site was logged against its source location within the cleanup area. The system tracked extraction sequences, soil type, and the date and time of each removal. Source data became the anchor that every subsequent record linked back to.
Each load of removed soil was tracked from source to destination. Disposal site records included the receiving facility, transport documentation, and chain-of-custody. EPA reporting requires this trail. The system captured it as a structured record rather than a paper manifest reconstructed at the end of each reporting period.
Testing results from soil samples were linked directly to the specific soil they characterized. Test method, lab, results by analyte, and date were captured against each source location. When a question arose about the contamination profile of soil sent to a specific disposal facility, the answer was a query rather than a manual file search.
The system included a calculation engine that projected forward to estimate remaining soil quantities still requiring treatment. Inputs included treated volumes, contamination boundaries, treatment effectiveness, and remediation rates. The engine produced timeline and cost projections that were defensible to EPA because the calculations were transparent and the underlying data was queryable.
The system gave the client real-time visibility into project timeline, cost trajectory, and regulatory progress against the EPA-approved cleanup plan. Quantities removed, quantities remaining, projected completion, and costs to date were available without manual rollup from spreadsheets. EPA reporting cycles became data extracts from the live system.
Superfund sites fail their tracking obligations in a specific way. The site team usually has the data. They just cannot produce it in the form EPA requires within the timeline EPA expects. A tracking system that captures data at the moment of work and structures it for the format regulators ask for changes the equation. The data was always there. The infrastructure to surface it was not.
The forward projection engine was the part that created the most strategic value, beyond the regulatory reporting. A project sponsor who can produce a defensible estimate of remaining cleanup work has a different conversation with EPA, with funders, and with internal stakeholders than a project sponsor who is producing best-guess timelines from spreadsheets. The number itself is less important than the auditability of how the number was produced.
What changed after the system went into production?
The most immediate change was that EPA reporting cycles stopped being reconstruction projects. The data trail from source soil through testing through disposal destination was already captured and structured. Reports became data extracts. The team's effort moved from assembling reports to running the cleanup.
| Outcome | Result | How it was achieved |
|---|---|---|
| EPA reporting timeline | Data extracts, not reconstructions | Source-to-destination chain captured at the moment of work, structured for regulator format |
| Forward projection of remaining work | Defensible to regulator | Custom calculation engine with transparent inputs and queryable underlying data |
| Source-to-disposal chain of custody | Continuous and complete | Every load tracked from source location through destination disposal facility |
| Contamination testing traceability | Linked at the source-record level | Testing results attached directly to the soil they characterized, by source and date |
| Project timeline visibility | Real-time | Treated volumes, remaining volumes, and projected completion available on demand |
| Cost trajectory tracking | Tied to actual cleanup data | Costs attributed to source locations and treatment phases as work progressed |
The strategic value of the system extended beyond EPA reporting itself. Real-time projection of remaining cleanup work changed the client's ability to manage the project against budget and schedule. Decisions that had previously waited for the next reporting cycle could be made on current data. Funding conversations that had been based on best-guess timelines became conversations grounded in defensible projections.
What capabilities does this kind of system provide for federally supervised environmental cleanup?
The infrastructure built for this Superfund site addresses a problem class that appears across every environmental remediation project under federal or state regulatory oversight. The capabilities below apply to CERCLA Superfund work, RCRA corrective action, state-led brownfield cleanups, voluntary cleanup programs, and any operation where soil, groundwater, or other contamination is being tracked from contaminated source through treatment or disposal.
Every cubic yard of contaminated material tracked from source location through transport through destination disposal facility. The chain that EPA and state regulators require is captured automatically at each handoff rather than reconstructed at the end of reporting cycles.
A calculation engine that estimates remaining cleanup work based on transparent inputs and queryable underlying data. Project sponsors can produce timeline and cost projections that hold up to regulator review and stakeholder scrutiny.
Contamination testing results connected directly to the specific source location, sample, and material they describe. When a question arises about the contamination profile of material sent to a specific facility, the answer is a query against linked records, not a manual file search.
Treated volumes, remaining volumes, projected completion dates, and cost trajectory available on demand against the EPA-approved cleanup plan. Project decisions stop waiting for the next reporting cycle to be made on current data.
Technology stack
| Component | Technology |
|---|---|
| Database layer | Relational database with enforced source-destination-testing relationships |
| Calculation engine | Custom forward projection logic with transparent input parameters |
| Data capture | Spreadsheet and database integration for field data entry |
| Chain of custody | Source location, transport, and destination logged as linked records |
| Testing integration | Lab results linked at the source-record level by sample, method, and date |
| Reporting layer | EPA-format data extracts produced from live system queries |
| Compliance framework | CERCLA / Superfund supervision with EPA reporting alignment |
Does this apply if your cleanup is smaller than a full Superfund site?
The architecture scales down as well as up. State-led brownfield cleanups, voluntary cleanup programs, RCRA corrective action sites, and private remediation under regulatory oversight all face the same core problems as a Superfund site: source-to-destination chain of custody, testing data linked to physical material, defensible forward projections, and reporting that aligns with regulator format. The engineering decisions on this project transfer directly to cleanups an order of magnitude smaller.
What makes this project transferable is not the regulatory framework. It is the problem class. Any environmental cleanup where contaminated material moves from source through testing through disposal, under any oversight regime, is carrying the same data integrity risk this Superfund site was carrying before the system went live. The risk accumulates invisibly until a regulator asks a question the data cannot answer in the form required.
PCG has built environmental compliance and remediation infrastructure since 1995. The work documented here is one of more than 500 production applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years.
Frequently asked questions about Superfund and environmental remediation tracking systems
Allison has been building custom software since the early 1980s, including work as a data analyst for the U.S. Air Force before founding PCG in 1995. The Superfund remediation tracking documented here is one of more than 500 custom applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years. Her direct involvement in every project is not a policy. It is how PCG operates. When you call, she answers.
Project details documented with client permission. Specific identifying details about the Superfund site have been generalized. System capabilities and architecture reflect the actual production deployment.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding.
What was breaking in the oil manufacturer's compliance documentation before this project?
The client was operating across 25 physically separate sites, each generating its own compliance records, revision histories, and audit documentation. The document control infrastructure that ISO 9000 certification requires had been assembled site by site over years, in different formats, on different systems, with no single source of record. When an audit arrived, demonstrating compliance meant pulling documents from 25 different locations, reconciling revision numbers, and proving that the version controlled at one site was the same version controlled at another.
That is not a documentation problem. That is a certification risk. ISO 9000 audits do not penalize organizations that have the right document. They penalize organizations that cannot prove which version of a document was in force on a given day at a given site. A multi-site oil manufacturer with no centralized control over revisions was carrying that risk continuously.
For an oil manufacturer, the consequences of an ISO 9000 finding extend beyond the certification itself. Customers, regulators, and downstream partners often require ISO 9000 as a prerequisite for doing business. A lapse exposes the operation to contract risk, not just audit risk.
What did PCG actually build for the multi-site compliance environment?
PCG designed and built a suite of multi-user regulatory compliance databases tied together by a centralized ISO 9000 document management and control system. The architecture was specifically engineered to handle the multi-site reality of the operation rather than forcing all 25 sites to access a single physical database that would have created network and performance bottlenecks. Each layer was built so that local site operations continued normally even when central connectivity was interrupted.
Every controlled document existed in one master location with full revision history. When a procedure was updated, the new version was tagged, dated, and linked to the previous version. Sites pulled the current approved version from the central repository rather than maintaining local copies that could drift out of sync.
The compliance databases were designed for multiple simultaneous users across distributed locations. Record locking, change tracking, and conflict resolution were built into the data layer so that concurrent edits at different sites did not produce corrupted records or lost updates.
Every record creation, modification, and deletion was logged with user, timestamp, and the values before and after the change. ISO 9000 audits require this trail. The system produced it automatically rather than requiring staff to maintain it manually.
Document revisions moved through a defined approval path before becoming the active version. Drafts, reviews, and approvals were tracked in the system. Sites could not accidentally use a draft revision because only approved versions were marked active in the document repository.
The architecture combined local database performance with central document authority. Sites operated against local data layers for daily transactions while document control and revision management remained centralized. This eliminated the network latency problems that a fully centralized system would have created across 25 remote locations.
ISO 9000 certification is often treated as a documentation problem. It is actually a control problem. The question an auditor asks is not "do you have this procedure" but "which version of this procedure was in force at site 14 on March 3rd, and can you prove it." A document repository without revision control and audit trail does not answer that question. A document repository built around revision control and audit trail answers it in seconds.
The multi-site dimension changes the architecture significantly. A single-site ISO 9000 system can run on a centralized database without performance issues. A 25-site system cannot. The decision to combine local database performance with centralized document authority was the architectural call that made the deployment workable. Without it, daily transactions at remote sites would have run on network round trips that would have made the system unusable in practice.
What changed after the system went into production?
The most immediate change was the elimination of cross-site reconciliation work that had previously preceded every audit cycle. Documents controlled at one site matched documents controlled at every other site by construction, not by manual verification. Audit response timelines that had measured in days of file assembly became hours of structured query against the central system.
| Outcome | Result | How it was achieved |
|---|---|---|
| ISO 9000 audit readiness | Continuous | Centralized document control with revision history and full transaction audit trail |
| Cross-site document consistency | Single source of record | Master repository with approved-version logic; local copies replaced with controlled pulls |
| Records and transactions managed | 50,000+ | Multi-user database architecture engineered for the data volume from the design phase |
| Sites under unified control | 25 remote locations | Distributed databases with central document authority; local performance preserved |
| Audit response time | Hours, not days | Structured queries against the live system replaced manual reconstruction across sites |
| Revision control compliance | Enforced at the data layer | Approval workflows prevented draft revisions from being used as active documents |
The strategic value of the system extended beyond ISO 9000 itself. Once compliance records, transactions, and revisions were structured and queryable across all 25 sites, the operation gained visibility into patterns that had been invisible when each site managed its own documents. Cross-site procedural variations that should have been standardized became identifiable for the first time.
What capabilities does this kind of system provide for a regulated multi-site operation?
The infrastructure built for this oil manufacturer addresses a problem class that appears across every multi-site industrial operation under regulatory or certification obligations. The capabilities below are not specific to oil manufacturing. They apply to chemical processing, pharmaceutical manufacturing, food and beverage production, environmental services, and any operation where ISO 9000, ISO 14001, ISO 45001, or sector-specific certifications are part of contractual or regulatory requirements.
One master repository for controlled documents, with revision history, approval workflows, and version-active enforcement. Sites pull current approved versions rather than maintaining local copies that drift over time.
The audit trail required by ISO 9000 and similar standards is captured automatically at the transaction level. Audit response is a structured query, not a file reconstruction project that consumes weeks of staff time.
Record locking, change tracking, and conflict resolution built into the data layer protect against the silent data corruption that accumulates when distributed teams edit shared records without proper concurrency controls.
Local database operations preserve daily transaction speed at remote sites. Central authority over document revisions and approval workflows preserves the certification integrity that requires single-source control.
Technology stack
| Component | Technology |
|---|---|
| Database layer | Multi-user relational database with record locking and change tracking |
| Document control | Centralized repository with revision history and approval workflows |
| Architecture | Distributed databases tied to central document authority |
| Concurrency | Multi-user access with conflict resolution at the data layer |
| Audit trail | Transaction-level logging with user, timestamp, and before/after values |
| Access control | Role-based permissions per site, per document, per record class |
| Scale | Engineered for 50,000+ records and transactions across 25 distributed sites |
Does this apply if your operation is smaller than 25 sites?
The architecture scales down as well as up. A regulated operation running 5 sites faces the same core problems as one running 25: document control gaps between locations, version drift, audit response that becomes a manual reconstruction project, and silent data corruption when distributed teams edit shared records. The engineering decisions on this project, particularly the combination of local database performance with central document authority, are directly applicable to operations of any multi-site scale.
What makes this project transferable is not the size. It is the problem class. Any operation where compliance, certification, or regulatory documentation must be controlled across multiple physical locations is carrying the same risk that this oil manufacturer was carrying. The risk accumulates invisibly until an audit, a customer review, or a contract renewal forces the question of whether the documentation can actually be produced in the form regulators or auditors require.
PCG has built compliance infrastructure for multi-site industrial operations since 1995. The work documented here is one of more than 500 production applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years.
Frequently asked questions about ISO 9000 compliance database systems
Allison has been building custom software since the early 1980s, including work as a data analyst for the U.S. Air Force before founding PCG in 1995. The ISO 9000 compliance work documented here is one of more than 500 custom applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years. Her direct involvement in every project is not a policy. It is how PCG operates. When you call, she answers.
Project details documented with client permission. Specific identifying details about the oil manufacturer have been generalized. Records, sites, and certification status reflect the actual production deployment.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding.