Admin-managed survey years
Non-technical administrators can add, retire, reorder, or deliberately map questions without changing application code.
2025 responses → 2026 survey
Carry answers forward.
Keep the history honest.
A small working prototype for the hardest part of a recurring reporting portal: deciding what can be safely prefilled when questions change between years.
01 / version handoff
Create a new reporting-year snapshot
12025 submittedimmutable baseline
2mapping reviewadmin decision
32026 draftcompany can edit
source year
submitted
2025 submitted response
new survey year
not created
2026 response snapshot
Create the snapshot to see which answers are copied, held for review, or left blank.
semantic change detected
The supplier-data question now covers Tier 1 and Tier 2. A matching ID should not silently copy an answer whose meaning changed.
No new-year response exists yet.
02 / provenance
Every copied answer keeps its source.
The production model would store a response snapshot for each company and year. Reopening a submitted survey changes that year's record through an auditable state transition; it does not rewrite another year's baseline.
survey_versions
question_versions
response_snapshots
mapping_decisions
audit_events
snapshot audit trail
waiting
- Create a snapshot to generate the trace.
03 / production shape
Simple for administrators, explicit underneath.
Supabase as the system of record
Postgres keeps companies, versions, responses, mapping decisions, and exports relational. Row-level security isolates each company's data.
Migration before automation
Three historical exports are reconciled into a staging layer first. Unmatched companies or questions become an explicit review queue.