Event operations case study
Grand Bethel Registration Pipeline
A deterministic event-operations pipeline that turns sensitive registration exports into reviewable summaries and site outputs without hiding the correction trail.
Operations pipeline
Traceable event state without publishing private data
The system keeps raw exports, explicit patches, and generated organizer outputs separate so corrections can be reviewed without exposing sensitive registration details.
- Raw data preserved separately from patches
- CSV, JSON, and static site outputs generated from one pipeline
- Corrections remain visible and rerunnable
Problem / Context
Problem
Grand Bethel operations depended on registration exports, preliminary program data, and organizer corrections that changed as the event came into focus. The risky part was not simply that the data was messy. The risky part was that manual cleanup could hide where a decision came from, which made later review and handoff harder.
The project reframed event registration as a deterministic data-processing problem. Raw exports stayed separate from patch files, mappings, and generated outputs so the final state could be reviewed without rewriting the source material.
Constraints
- Registration and operational data is sensitive and cannot be published directly.
- Schedules change before program lock, so the system needed to tolerate revision.
- Organizers needed outputs in formats they could actually use, including spreadsheets and a website.
- Corrections had to be easy to apply without losing source traceability.
Approach / System Design
Architecture
- Raw registration and schedule inputs are treated as source data.
- Configuration files hold mappings, patches, overrides, and schedule rules.
- Python scripts normalize responses, parse program data, enrich schedules, and build organizer-facing summaries.
- Generated outputs include CSV summaries, JSON summaries, and a static site surface for operational review.
The important design choice was explicitness. Corrections belonged in visible override files, not hidden spreadsheet edits. That kept the system rerunnable and made it easier to explain why a final output looked the way it did.
Outcomes / Lessons
Outcomes
The pipeline reduced manual coordination overhead by turning fragmented exports into consistent planning artifacts. It also created a clearer operating model: raw inputs, explicit patches, generated summaries, and a reviewable site.
The strongest evidence is the workflow shape: a repeatable pipeline that makes event state inspectable without turning corrections into hidden spreadsheet edits.
Artifacts
Artifacts
- Architecture summary: raw exports, configuration, normalization, enrichment, generated summaries, and static site output.
- Output model: CSV and JSON summaries designed for organizer review.
- Operational pattern: patch files preserve corrections without mutating the original registration export.