Overview

EAIS is a Supabase-backed event attendance and feedback platform designed around a simple constraint:

The system needed to work reliably during real event operations, not just in ideal demo conditions.

The platform combines:

• attendee check-in workflows
• attendance-code generation
• session restoration
• survey consent handling
• telemetry collection
• admin management tools
• AI-assisted report generation

The frontend is built with React and Vite, while the backend is structured around Supabase Postgres and a set of Edge Functions that coordinate workflow transitions and operational logic.

What made the project interesting was not the number of screens or dashboards.

The real engineering challenge was maintaining trust in system state across:

• public attendee flows
• protected admin operations
• telemetry pipelines
• post-event reporting systems

without losing reliability as users refreshed, retried, disconnected, or resumed sessions mid-flow.

Problem

Event operations tend to fail at system boundaries.

Common issues include:

• attendee sessions being lost after refresh
• duplicate check-ins
• incomplete survey flows
• missing telemetry
• operational data without sufficient audit context
• admin dashboards that show metrics but not behavioral traces

Most event platforms optimize for:

• form collection
• analytics dashboards
• administrative CRUD interfaces

but not for operational continuity under real usage conditions.

EAIS was designed to address those reliability gaps directly.

The system needed to support:

• live event intake
• resumable public sessions
• telemetry durability
• structured operational state
• post-event evidence inspection
• bounded reporting pipelines

System Philosophy

Reliability Over Demo Simplicity

The system prioritizes operational continuity over minimal architecture.

Public workflows are expected to survive:

• reloads
• intermittent failures
• user interruptions
• duplicate attempts
• partial completion states

This required the system to treat state restoration and telemetry persistence as first-class concerns rather than secondary enhancements.

Separate Public & Administrative Boundaries

The platform intentionally separates:

Public flows

• attendee check-in
• attendance-code issuance
• survey progression
• telemetry capture

from:

Administrative flows

• event management
• question configuration
• attendance inspection
• reporting
• operational analytics

This reduces accidental coupling between user-facing workflows and administrative mutation paths.

Structured Operational Visibility

The system is designed around observable workflows.

Instead of storing everything inside a generic event stream, the platform separates:

• attendance behavior
• survey progression
• telemetry events
• duplicate detection
• reporting jobs
• administrative actions

This improves:

• debugging
• auditability
• operational reporting
• post-event analysis

High-Level Architecture

The project is divided into four major operational domains:

Layer

Responsibility

Public User Flows

Check-in, attendance issuance, surveys

Admin Platform

Event management and operational tooling

Edge Function Layer

Workflow orchestration and business logic

Data & Reporting Layer

Persistence, telemetry, analytics, reporting

Public Workflow System

The public-facing system handles attendee progression through the event flow.

Primary routes include:

• /check-in
• /entry
• /survey

The flow begins by bootstrapping an attendance session tied to an event slug.

The system then:

creates or restores session state

issues attendance identifiers

captures consent

processes survey completion

records telemetry during progression

The design goal was to ensure users could recover from interruptions without corrupting operational state.

Administrative Platform

The administrative layer acts as the operational control system.

Protected routes include:

• /admin/events
• /admin/categories
• /admin/questions
• /admin/attendance
• /admin/manual-survey-imports
• /admin/reports
• /admin/settings

Administrative tooling supports:

• event lifecycle management
• survey structure configuration
• attendance inspection
• telemetry review
• report generation
• operational monitoring

Authentication and protected mutations are routed through dedicated admin APIs with session validation and CSRF protection.

Backend Architecture

The backend is built around Supabase Edge Functions and PostgreSQL.

Core functions include:

• survey-bootstrap
• checkin-bootstrap
• check-in-user
• survey-consent
• survey-complete
• step-logger
• admin-auth
• admin-data
• admin-reports

Supporting utilities handle:

• authentication verification
• Redis cache management
• session restoration
• operational cleanup workflows

The architecture treats Edge Functions as workflow coordinators rather than simple CRUD endpoints.

Reporting Pipeline

The reporting engine is one of the newer architectural layers in the system.

Its purpose is to transform operational event data into structured post-event reports.

The pipeline works through several stages:

DOCX template ingestion

prompt extraction

event dossier assembly

AI-assisted report drafting

DOCX script generation

validation and storage

Rather than generating reports through a single opaque AI request, the pipeline separates:

• template parsing
• job orchestration
• data aggregation
• model interaction
• output validation

This makes the reporting system easier to debug and safer to extend.

Data Model Design

One of the most important architectural decisions was maintaining explicit operational entities instead of collapsing everything into generalized logs.

The schema separates:

• attendees
• attendance logs
• survey responses
• check-in sessions
• survey sessions
• telemetry traces
• duplicate reports
• report jobs

This improved:

• operational visibility
• debugging clarity
• reporting consistency
• post-event analytics

Key Engineering Decisions

Session Restoration Was Treated as Infrastructure

Session recovery was designed as part of the system contract rather than a UI convenience.

Public flows needed to survive:

• accidental refreshes
• browser interruptions
• temporary connectivity issues

without invalidating operational state.

Telemetry Was Designed for Durability

Telemetry events were treated as operational evidence rather than optional analytics.

The system needed to preserve:

• progression traces
• interruption points
• behavioral transitions
• duplicate check-in patterns

even during transient failures.

Reporting Pipelines Needed Boundaries

AI-assisted reporting introduced risks around:

• oversized datasets
• uncontrolled context growth
• runtime exhaustion
• opaque failures

To control this, the reporting layer uses:

• bounded aggregation
• dataset snapshots
• lease-based jobs
• staged orchestration
• validation checkpoints

Challenges & Tradeoffs

Managing Stateful Public Flows

Public workflows become significantly more complex once interruption recovery is required.

The system needed reliable handling for:

• resumed sessions
• duplicate attempts
• partially completed surveys
• telemetry continuity

Edge Runtime Constraints

Supabase Edge Functions introduced practical limitations around:

• execution time
• memory boundaries
• dataset sizing
• orchestration complexity

This forced the reporting pipeline to remain intentionally bounded.

Operational Traceability

A major challenge was preserving enough context to explain:

• what happened
• when it happened
• why a state transition occurred

without overwhelming the data model with excessive coupling.

Current Status

EAIS is currently under active development.

Implemented systems include:

• public attendance workflows
• survey progression
• telemetry collection
• protected admin tooling
• operational event management
• duplicate detection infrastructure
• reporting pipeline foundations

Ongoing work includes:

• reporting engine refinement
• telemetry analytics expansion
• operational observability improvements
• workflow optimization
• bounded AI reporting enhancements

What This Project Is

EAIS is best understood as:

A structured event operations and intelligence platform.

Not:

• a simple attendance tracker
• a generic survey tool
• a dashboard-only analytics system

Its core focus is operational continuity, workflow reliability, telemetry visibility, and post-event intelligence generation.

What I Learned

This project reinforced that reliability problems usually emerge at boundaries.

The difficult parts were not:

• forms
• dashboards
• CRUD operations

The difficult parts were:

• session continuity
• telemetry durability
• operational visibility
• bounded orchestration
• recoverable workflows

The project also clarified an important architectural lesson:

Systems become substantially easier to reason about once operational domains are separated clearly.

Separating:

• public intake
• administrative control
• telemetry pipelines
• reporting workflows

made the overall platform significantly more maintainable as complexity increased.