From Spreadsheet Overload to 60-Second Decision Briefs: Signelle's AI Data Platform

Pure AI-generated briefs are unreliable — they hallucinate metrics, skip signals, and have unpredictable latency. But pure rule-based output reads like a spreadsheet dump. The system needed to be trustworthy first, good-sounding second.

The pipeline is purely deterministic through five stages — column inspection, tier detection, metric computation, governance, and narrative building — producing a complete, valid brief with no AI dependency. Claude API is only called at stage 6 to improve the narrative tone for medium and large datasets. If the API fails or times out, the user still gets a complete brief. AI is an enhancement, not a requirement.

Real-world Excel files often have multiple sheets representing different time periods, regions, or business units. Treating the whole file as a single run loses the per-sheet signal; ignoring the relationships loses the cross-sheet context.

The ingest layer uses parseXlsxAllSheets() to generate one analysis run per sheet plus a combined run where all sheets are merged with a _sheet column tag. A single upload produces N+1 briefs — one for each sheet and one for the combined dataset — giving users both granular and aggregate views automatically.

Sending a brief every time a file is uploaded creates noise and trains users to ignore alerts. But never sending one when nothing changed isn't obviously better than a dashboard. Users needed a reason to trust that silence means safety.

governOutcome() applies cooldown logic against recent runs and checks data freshness before assigning briefType. If the data hasn't changed materially since the last run, the brief is typed as Monitor-Only or All-Quiet — explicitly telling the user nothing needs action. If the data appears stale (old timestamps, no variation), it surfaces as Data-Stale. Users learn to treat the inbox as a signal, not a firehose.

The platform needed to support teams — multiple seats per workspace, per-workspace data isolation, and role-based permissions — without locking into a BaaS that would constrain the data model.

Firebase Auth handles identity and session tokens via the frontend SDK; the Express middleware (requireAuth) verifies the Firebase JWT server-side on every API request and maps it to an internal account in PostgreSQL. Workspaces, memberships, data sources, runs, and signals all live in Postgres with Drizzle ORM providing type-safe queries. Firebase does auth; Postgres owns the data.