Last updated: June 2026 | June 2026 | Phoenix Consultants Group | Inventory Accuracy + Operational Visibility The production scheduler checked the system at 8:15 AM. It showed 320 units of a critical component available in Bin C-14. By 8:40 AM, the floor supervisor called to say the bin was empty. Not low. Not partially […]
Last updated: June 2026 | Phoenix Consultants Group | Warehouse Workflow + Labor Efficiency The pick list printed at 7:04 AM. By 7:51 AM, the picker had covered over half a mile of floor. He picked eleven items. No one on the supervisory team flagged it. The labor report showed 47 minutes of active warehouse […]
Last updated: June 2026 | Phoenix Consultants Group | Warehouse Operations + ERP Adoption The system went live eight months ago. Training happened. The go-live party happened. Leadership announced the end of paper-based receiving. Then, on a Tuesday afternoon, a warehouse lead pulled out a yellow legal pad and wrote down three incoming pallets by […]
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.
- 1
- 2