Every decision is a database record, supersedable, react-able

Our differentiator is that we made decisions for users (the constitution, the refusals, the lens presets) — and we tell them why and let them push back. That story isn't credible if the only record of "why we chose X" is in a markdown file in the repo. It needs to be a first-class user-visible artifact, queryable, votable, comment-able, supersedable.

This decision is the meta-primitive: it is itself a row in the table it defines.

Schema

decisions — portfolio-wide (no product prefix). Columns: slug, title, scope, product_slug, summary_md, reasoning_md, status (proposed|shipped|superseded|reverted), supersedes_decision_id (FK self-ref), decided_by_user_id, decided_at, shipped_at, superseded_at, ai_authored, ai_provider, source_commit_sha.

Routes

• /decisions — list, filterable by scope and status.
• /decisions/<slug> — detail page with reasoning, supersession chain, reactions.

Reactions on decisions

Three kinds (vs atoms' one):

• appreciate — "this resonates / I support this"
• disagree — "I'd push back" (couples with a comment)
• unsure — "I want to learn more before forming an opinion"

Decision aggregates are visible to the operator who decided AND to any user in ADMIN_EMAILS. Other readers see only their own button states. No public counts.

Decision lifecycle

proposed → shipped → (later) superseded → (recordable revert) — never deleted, even reverted.

Why this is constitutional, not bureaucratic

• Refusal #15 (no stealth data) requires us to be honest about what we know about the user. The same standard applies to what we decided for the user — every refusal, every lens, every default is a thing we chose on their behalf, and they're owed visibility into why.
• Refusal #5 (every field exportable) extends naturally: every decision exportable, every reaction exportable.
• The substrate doctrine says the platform fits itself to the user. Decisions-as-record says the platform's self is also inspectable, not opaque.

What this is not

• Not Hall (Hall is bottom-up community proposals; decisions are top-down operator choices).
• Not ADRs (ADRs are heavy engineering records; decisions are user-facing UX/policy choices in lighter prose).