Data foundation
Standards + database
Defined collection rules and acceptable sources, then structured the database used to house localized site reporting.
Case Studies
Systems built under real-world constraints.
A few examples of operational, technical, and reporting systems I’ve helped shape. Each started with a different problem, but the work followed a consistent pattern: understand how the operation actually works, identify where information and reality have diverged, and build a practical way to reconnect them.
Operations
Reporting Systems
Data Workflows
COVID-19 Regional Monitoring & Reporting System
During the COVID-19 pandemic, I helped develop and maintain a global monitoring program that tracked conditions within a 50-mile radius of individual operational sites. Operating through a regional accountability structure, the program combined localized reporting with dashboards I developed to show regional trends over time, giving Physical Security, EHS, and Operations leadership consistent information to support return-to-office planning and other operational decisions.
Scope
Global program with 50-mile localized monitoring around individual operational sites
Cadence
March 2020–December 2022
Nightly collection, daily reporting, later weekly summaries
Focus
Local monitoring, regional trend analysis, and decision support
Explore the full case study
01 · The problem
A local question at global scale
Physical Security, EHS, and Operations leaders needed a consistent way to understand rapidly changing conditions around individual facilities. Local sources and reporting standards varied, but the program still needed reliable data that could roll up into regional accountability and leadership reporting.
02 · My role
Defining how the information was collected, structured, and used
I developed the database used to house localized reporting, established collection rules, and identified data sources that met those standards. I also built dashboards that turned site-level reporting into regional trend views over time.
Alongside that development work, I helped maintain the broader monitoring workflow as reporting moved from the high-frequency shutdown period into longer-term operational and return-to-office planning.
03 · What I built
A connected reporting workflow, not a collection of isolated reports
Monitoring workflow
Local conditions + validation
Supported recurring monitoring within 50 miles of each site and kept reporting consistent as conditions and standards changed.
Decision layer
Regional dashboards
Aggregated localized reporting into trend views used by Physical Security, EHS, and Operations leadership, including RTO planning.
04 · The result
A system that adapted as the operational question changed
The program translated changing local conditions into regional operational intelligence. What began as high-frequency monitoring during shutdowns evolved into a repeatable source of trend information that leadership could use as return-to-office and other operational decisions developed.
~34 months
Program duration
50 miles
Localized monitoring radius
Reporting
Cadence evolved from daily to weekly as conditions stabilized
Inventory Control
SAP
Process Improvement
Merchandise Inventory Reconciliation & Data Validation
I helped turn a large physical inventory preparation effort into a structured reconciliation and operational recovery process. Working with a small inventory team, I compared physical counts against SAP location and plant-level data, built reusable tools to classify exceptions, and used the resulting analysis to move the work beyond counting toward investigation, prioritization, and process diagnosis.
Scope
Large-scale physical-to-system reconciliation across multiple warehouse storage environments
Cadence
Area-by-area counting, reconciliation, investigation, and follow-up ahead of annual inventory
Focus
Inventory accuracy, exception classification, SAP comparison, root-cause investigation, and operational prioritization
Explore the full case study
01 · The problem
When the system record and physical reality disagree
A multi-site inventory system had consistent issues with physical inventory not matching location-level system data. Products could be physically present but absent from location data, quantities could differ from system records, and materials could appear in unexpected locations. The scale and variety of storage environments made manual reconciliation slow and created additional risk ahead of annual third-party inventory. More importantly, repeated discrepancies suggested that some exceptions were symptoms of broader process gaps, control weaknesses, and human error rather than simple, isolated count issues.
02 · My role
Turning counts into structured exceptions and questions
Working with a small inventory team, I counted and reconciled physical storage areas and compared bin-and-SKU combinations against SAP data. I developed an Excel-based reconciliation template that automatically classified additions, removals, count variances, missing materials, and items associated with other locations. I also incorporated broader plant-level inventory data to distinguish true exceptions from inventory that had simply moved elsewhere.
As the project expanded, I used the resulting data to track progress, investigate recurring discrepancy patterns, and help determine which areas or problems should be prioritized next. The work increasingly shifted from answering “what does not match?” to understanding why mismatches were occurring and what operational process might be creating them.
03 · How it worked
A reconciliation loop built to narrow uncertainty
01Physical count
Capture what was actually present in each storage location.
02SAP comparison
Compare physical bin-and-SKU combinations against location-level system data.
03Exception classification
Separate additions, removals, count variances, missing materials, and cross-location inventory.
04Plant-level validation
Use broader inventory data to determine whether apparent exceptions existed elsewhere.
05Investigation
Look for recurring patterns pointing to process gaps, control weaknesses, or human error.
06Prioritization
Turn findings into visible follow-up work and help leadership determine where attention was needed next.
04 · What the data revealed
The exceptions became evidence
The reconciliation surfaced significant quantities of inventory requiring system correction or further investigation. Different analyses exposed materials physically present but not represented in expected system data, count variances, and items represented in SAP without a confirmed physical location.
380
Physically identified items not represented in expected SAP data within one 980-SKU analysis
236
Count variances identified in the same storage-area analysis
205
Potential additions identified after a later plant-level validation
158
SKUs represented in SAP without a confirmed physical location at that project stage
Project-stage findings from specific analyses, not final warehouse-wide accuracy metrics.
05 · The result
From inventory discrepancy to operational diagnosis
The process converted raw physical counts into actionable exception lists and created a repeatable method for reconciling additional storage areas. It also made recurring operational issues more visible. Managers increasingly used the team’s findings to help set priorities, additional overtime labor was approved for a coordinated receiving-remediation effort, and merchandise leadership began reviewing the reconciliation tools used to organize and interpret the work.
The project demonstrated that inventory reconciliation could provide more than a cleaner count. By connecting physical observations with system data and recurring exception patterns, the work created a clearer path from inventory discrepancy to operational diagnosis.
Systems Design
Operations
Relational Data
Pathfinder: An Operations Management System
I designed and implemented Pathfinder, an Airtable-based operations system that connected inventory, purchasing, vendor information, room readiness, facilities workflows, and recurring operational data for a 24,000-square-foot learning environment. What began as a way to reduce dependence on institutional knowledge evolved into an operational framework for making recurring work visible, structured, and easier to hand off.
Scope
Operational systems supporting a 24,000 sq. ft. multi-use learning environment and 30+ service partners
Cadence
Ongoing inventory, purchasing, facilities, room-readiness, vendor, and reporting workflows
Focus
Institutional knowledge, relational data, workflow standardization, operational visibility, and continuity
Explore the full case study
01 · The problem
When operational knowledge lives in people
Much of the day-to-day operational knowledge required to keep the facility running lived in individual people, disconnected records, or recurring habits that were difficult to see as a complete system. Inventory, purchasing, vendors, room readiness, facilities needs, technology, and access all affected one another, but the information needed to manage those responsibilities was fragmented.
The need became especially clear when a coworker announced plans to leave. With operational knowledge concentrated in a small number of people and my own workload already near capacity, continuity could not depend on remembering every recurring need, location, relationship, and follow-up. The problem was not simply documenting tasks. It was creating a system that could preserve context, surface what needed attention, and make the work transferable.
02 · My role
Designing the operating model around the work
I designed and implemented Pathfinder in Airtable as a connected operational system rather than a collection of independent trackers. I mapped recurring work, defined relationships between operational records, standardized how information was captured, and built workflows around the way the facility actually operated.
The system developed around linked data for locations, inventory items, location-level quantities, requests, purchasing signals, events, vendors, and other operational relationships. As Pathfinder expanded, I applied the same approach to broader facilities and operational work: identify the recurring decision or handoff, determine what information needed to survive between people or work cycles, and structure the workflow so the next action was visible.
03 · The system
A connected model instead of disconnected trackers
Pathfinder connected operational records so context could move with the work. The model below is intentionally simplified: Airtable was the platform, but the value came from the relationships, standards, and workflows built around real operations.
Pathfinder
Operational context
Where work and inventory lived
What each location was expected to carry
What needed action or follow-up
Signals tied to operational demand
Service relationships and context
Recurring needs, readiness, and issues
04 · Operational reality
Built from observation, not a theoretical process map
Pathfinder grew from repeated observation of the work itself: supply usage, room setup needs, purchasing cycles, vendor interactions, facility walks, service gaps, and the interruptions that occur in a shared multi-use environment.
The workload analysis reinforced the need to manage by exception and visibility rather than treating every operational check as an equally manual task. The expanded coverage figure was a contemporaneous estimate.
05 · The result
Turning individual knowledge into operational continuity
Pathfinder created a shared operational structure for work that had previously depended heavily on individual memory and fragmented tracking. It connected recurring activities that were operationally related but easy to manage separately, giving the organization a clearer way to see what existed, where it belonged, what required attention, and how different workflows affected one another.
The system also changed how I approached the role itself. Instead of trying to personally remember and react to every operational need, I could externalize recurring knowledge into a system designed to survive skipped cycles, competing priorities, interruptions, and eventual handoff. Pathfinder became less about maintaining an Airtable base and more about building operational continuity into the work.
Compliance Operations
Data Validation
Remote Outreach
Pipeline Emergency Response Outreach & Data Validation
I supported a contracted pilot program for pipeline operators that tested whether emergency-response liaison and preparedness outreach traditionally conducted through in-person field visits could be completed remotely. Using an existing ArcGIS map that overlaid pipeline routes with relevant jurisdictions, the team contacted emergency management and first-responder leadership, documented outreach attempts, and collected structured preparedness information. When unreliable source data began disrupting the workflow, I developed a process for flagging questionable records and delegating OSINT research across the team to locate better information.
Scope
6+ states, 250+ counties, and 800+ emergency responders across assigned U.S. pipeline corridors
Cadence
Structured outreach with at least three contact attempts before an unanswered location could be closed out
Focus
Pipeline compliance support, responder preparedness, contact-data quality, and OSINT validation
Explore the full case study
01 · The problem
A remote compliance workflow is only as reliable as its source data
Pipeline operators have federal obligations to maintain communication and liaison with emergency-response organizations in the jurisdictions their pipelines cross. The contracted program was testing whether outreach traditionally performed through representatives traveling the pipeline route could be completed remotely while still producing structured, documented contact with the appropriate agencies.
The team began with an existing GIS map and supplied contact data, but data-quality problems made it harder to identify or reach the correct organizations. In a remote model, unreliable jurisdiction and contact records were not just an inconvenience; they directly affected whether the outreach workflow could operate reliably at scale.
02 · My role
Outreach, documentation, and a validation layer for bad data
I conducted and documented outreach on behalf of the pipeline operators to emergency management directors and first-line responder leadership, including sheriffs, police chiefs, and fire chiefs, across assigned U.S. jurisdictions along the pipeline routes.
Successful contacts completed a structured survey covering department size, training, equipment, and knowledge or preparation for a pipeline gas leak and/or fire. The program required at least three contact attempts before an unanswered location could be closed out.
As data-quality issues became more visible, I developed a system for flagging questionable source records and delegating research across the team. We used open-source research techniques to locate stronger agency and contact information, adding a validation layer instead of treating the provided data as inherently reliable.
03 · The workflow
A closed loop from geographic context to validated outreach
Use the existing ArcGIS pipeline map to understand the route and relevant jurisdictions.
Determine the appropriate emergency-management or first-responder organization and leadership contact.
Contact the organization on behalf of the operator and request completion of the preparedness survey.
Record each attempt and maintain the program's minimum three-attempt standard for unanswered locations.
Document staffing, training, equipment, and pipeline emergency-preparedness information.
Identify supplied records that appear incomplete, incorrect, or unreliable.
Use delegated OSINT research to locate stronger source information and return corrected records to outreach.
04 · Why it mattered
Testing whether field outreach could become a scalable remote process
The federal compliance obligation belonged to the pipeline operators. Our role was to support that process by carrying out and documenting responder outreach on their behalf.
The pilot tested whether that work could be performed remotely rather than relying on representatives traveling the route in person. That made data quality part of the operating model: remote outreach could only scale if the team could reliably identify the correct organizations and contacts without depending on a field representative to resolve bad information on location.
Conservative scale estimates recalled from project dashboards rather than audited final totals.
05 · The result
Making the remote workflow more resilient when the starting data could not be trusted
The project established a structured remote workflow for responder outreach and survey collection across a large multi-state footprint. My data-quality process added a repeatable method for identifying questionable records, distributing research work, and improving the information used for subsequent outreach.
The pilot's value was not simply reducing the travel and cost associated with in-person outreach. It demonstrated the operational requirements behind remote delivery: geographic context, documented contact standards, consistent preparedness data, and a way to repair unreliable source information when it threatened the workflow.