# Platform Insights — Strategy & Design Reference

> This is a living document. Return to it as data grows, as investor questions arise,
> and as the product evolves. The questions at the bottom are designed to stress-test
> our thinking at each stage.

---

## Daily Feed — 3-Tier Module Structure (agreed March 2026)

The feed is a single vertical track. Tier 1 is the default view. Tiers 2 and 3
are served on pull-to-refresh, going deeper on the same ranking logic rather than
introducing new module types. No sub-feeds, no branching — single track throughout.

Four breakers are distributed across all three tiers. Each breaker uses the
Platform Insight full-width card treatment and is stable (editorial, not live data)
except for FM.T2.5 Closest Race which is genuinely dynamic.

```
TIER 1 — Default (18 modules)
──────────────────────────────────────────────────────────────
FM.T1.1   Running Out of Time
FM.T1.2   Top National Vote (Closed)
FM.T1.3   Top State Vote (Open)
FM.T1.4   It's Not Over Yet               ← was "Get the Word Out" — renamed
FM.T1.5   Just Approved (Vote Proposals)
FM.T1.6   Insights: Voting on Deadline    ← BREAKER 1 (wave chart)
FM.T1.7   Top Local (Closed)
FM.T1.8   Top National (Open)
FM.T1.9   Your Community Voted
FM.T1.10  Top by Category (Closed)
FM.T1.11  Add Research Prompt             ← stub
FM.T1.12  Insights: Voting Trends         ← BREAKER 2 (topic bars)
FM.T1.13  Top State (Closed)
FM.T1.14  Top Local (Open)
FM.T1.15  Just Closed
FM.T1.16  Top by Topic (Open)
FM.T1.17  Your Milestones
FM.T1.18  Your Backlog

TIER 2 — First pull-down (8 modules)
──────────────────────────────────────────────────────────────
FM.T2.1   Top National Vote #2 (Closed)
FM.T2.2   Top State Vote #2 (Closed)
FM.T2.3   Push to the Finish              ← urgency variant of T1.4
FM.T2.4   Just Approved #2 (Vote Proposals)
FM.T2.5   Insights: Close Call            ← BREAKER 3 (closest race — live)
FM.T2.6   Top Local #2 (Closed)
FM.T2.7   Top National #2 (Open)
FM.T2.8   Top by Topic #2 (Closed)

TIER 3 — Second pull-down (6 modules)
──────────────────────────────────────────────────────────────
FM.T3.1   Add Research Prompt #2
FM.T3.2   Recently Closed #2
FM.T3.3   Insights: It's (Nearly) Unanimous  ← BREAKER 4 (consensus finding)
FM.T3.4   Top State #2 (Closed)
FM.T3.5   Top Local #2 (Open)
FM.T3.6   Top by Topic #2 (Open)
```

**Total: 32 modules across 3 tiers.** The engaged daily user sees 18. The power user
who pulls down twice sees all 32. No user is forced past their natural stopping point.

**On T1.4 vs T2.3 — resolved March 2026:**

These are opposite ends of the same spectrum, not the same module:

- **FM.T1.4 "It's Not Over Yet"** — user is on the *losing* side and hasn't shared.
  The race is close enough that more voices could genuinely shift the outcome.
  Framing: opportunity. "Your side is behind — but it's not over."
  Filter logic: open vote where user voted NO on a currently YES-leading item (or vice
  versa), split is within ~15 points, vote hasn't closed.

- **FM.T2.3 "Push to the Finish"** — user is on the *winning* side and hasn't shared.
  The lead is real but not insurmountable — don't let it slip.
  Framing: responsibility. "You're ahead — help hold the line."
  Filter logic: open vote where user voted with the current majority, split is within
  ~20 points, vote hasn't closed.

Both modules are only surfaced if the user has voted on the relevant item. If the user
hasn't voted at all on close races, they fall through to Running Out of Time instead.

---

## Module Header / Evidence / CTA Pattern (design principle, agreed March 2026)

Most feed modules use a neutral section header ("Top State Vote", "Just Closed").
A subset of modules — particularly those involving personal stakes or platform intelligence
— benefit from a more editorial approach: a **catchy header that makes a claim**, supporting
**evidence or data**, and a **single clear CTA**.

This is the pattern: **tension or surprise in the header → data as the proof → one action**.

The module titles in the feed spec (FM.T1.x etc.) are internal identifiers. The user-facing
header can and should be dynamic, written to the moment rather than the category.

### Modules suited to this pattern

| Module | User-facing header example | Evidence | CTA |
|--------|---------------------------|----------|-----|
| FM.T1.1 Running Out of Time | "The Clock Is Running Out" | Days left + vote count | Vote Now |
| FM.T1.4 It's Not Over Yet | "It's Not Over Yet" | Live split, user on losing side | Share your vote |
| FM.T2.3 Push to the Finish | "Push to the Finish" | Live split, user on winning side | Share your vote |
| FM.T1.9 Community Voted | "Your Neighbour Voted — Did You?" | Verified resident's vote + result | Vote on this |
| FM.T2.5 Close Call | "Too Close to Call" | Live 51/49 split bar | Vote Now |
| FM.T3.3 Nearly Unanimous | "Everyone Agrees — Do You?" | Lopsided result bar (85%+) | Add your voice |
| FM.T1.17 Milestones | "You Called It" (post-vote win) | Closed result matching user's vote | — |

### Modules that stay neutral

These modules are informational or browse-style — the editorial hook would feel forced:

- Top National / State / Local (open or closed) — the vote speaks for itself
- Top by Category — directory browse, not a personal stake moment
- Just Closed — results delivery, not a call to action
- Your Backlog — inventory, not urgency
- Add Research Prompt — contribution ask, works better as a quiet prompt than a headline

### Notes for build

- Headers should be computed dynamically where the user's vote state is known.
  A module that shows "It's Not Over Yet" only makes sense if we know the user voted
  on that item and is currently on the losing side. Default to neutral header if
  user vote state is unknown.
- CTA copy should match the action precisely. "Share your vote" is different from
  "Vote Now" — don't conflate them.
- The SectionHeader component will need a `cta` prop eventually (button inline with
  the header row). Currently it only supports "See all". Add when building these modules.

---

## FM.T1.16 — Top by Topic (TopicTopVoteCard)

Surfaces the highest-voted policy issues by category. Appears in the feed under a
**"Top Issues by Topic"** section header. Up to four cards render in a single group:
two from the open voting pool, two from the closed results pool, interleaved so users
see both live and decided issues together.

Defined in: `apps/mobile/app/(tabs)/votd.tsx` — `TopicTopVoteCard` component + `pickTopicCards()`.

---

### How it differs from TopVoteCard

`TopVoteCard` is anchored to **jurisdiction tier** — Country, State, Local. It asks:
*what is the most-voted issue at each level of government?*

`TopicTopVoteCard` is anchored to **policy category** — Labor, Housing, Energy, etc.
It asks: *what is the most-voted issue within each topic area, regardless of jurisdiction?*
A federal LABOR item and a local LABOR item compete on equal footing — only total vote
count determines which surfaces.

---

### Visual anatomy

Each card has five layers stacked within a single rounded container:

| Layer | Description |
|---|---|
| Ghost icon | Topic SVG at 235 × 235 dp, top-right, 18% opacity. Provides texture without competing with text. |
| Fade gradient | Transparent → card background over the bottom 20% of the icon. Prevents a hard cutoff. |
| Rank overlay | Absolutely positioned at y=90 dp. Shows `#1 in Labor` — rank number, "in" connector, topic name — in Roboto 500 at 34 dp. Vote count on the line below in Roboto 500 at 15 dp all-caps. |
| Body | paddingTop 180 dp clears the overlay zone. Status badge (days left or "Final results") + poll question in Roboto 700 at 16 dp. |
| Footer | 48 dp tall — same footprint as TopVoteCard's Vote Now button. Switches between Vote Now and tally bar (see state machine below). |

---

### Footer state machine

| State | Condition | Display |
|---|---|---|
| Vote Now | `isOpen === true` AND user has not voted | Orange "Vote Now" button. Tap navigates to vote detail screen. |
| Tally bar | `isOpen === false` OR user has already voted | Proportional YES/NO fill track + percentage pill labels. Winning side gets brand-orange pill; losing side is dimmed. |

Closed and voted-on cards always show results. Open unvoted cards always invite action.

---

### Selection rules — `pickTopicCards()`

**Goal:** return up to 4 cards — 2 open, 2 closed — one per unique topic, highest vote
count wins within each pool.

**Algorithm:**

1. Combine open and closed pools into one list. Group by topic code. Sort each group
   descending by `totalVotes`. This establishes the rank map used for `#1`, `#2` labels.

2. Sort the open pool descending by `totalVotes`. Walk the list and pick the first item
   for each unique topic encountered. Stop at 2. Each entry gets its rank from the rank
   map and is flagged `isOpen: true`.

3. Same process for the closed pool. Stop at 2. `isOpen: false`.

4. Interleave: `[open[0], closed[0], open[1], closed[1]]`. If one pool is shorter,
   the other fills as available.

**Key rules enforced:**
- One card per topic code — no duplicate categories in the output
- Rank is cross-pool — `#1 in Labor` means first across all Labor items (open + closed combined), so the label is always accurate
- No jurisdiction filter — federal, state, and local items compete equally within a topic
- Section header only renders if at least one card is returned

---

### Topic categories

18 canonical topic codes, each with a dedicated SVG icon sourced from
`assets/icons/vote topic icons/`:

| Code | Display name |
|---|---|
| AGRICULTURE | Agriculture |
| BUSINESS_REGULATION | Business & Regulation |
| CRIMINAL_JUSTICE_SAFETY | Criminal Justice & Public Safety |
| DEFENSE | Defense |
| ECONOMY_JOBS | Economy & Jobs |
| EDUCATION | Education |
| ENERGY | Energy |
| ENVIRONMENT | Environment |
| FOREIGN_POLICY | Foreign Policy |
| GOVERNMENT_REFORM | Government Reform |
| HOUSING | Housing |
| INFRASTRUCTURE | Infrastructure |
| LABOR | Labor |
| PARKS_COMMUNITY | Parks & Community |
| PUBLIC_HEALTH | Public Health |
| PUBLIC_SERVICES | Public Services |
| TAXES_SPENDING | Taxes & Spending |
| TRANSPORTATION | Transportation |

**Note:** `INFRASTRUCTURE` was formerly `INFRASTRUCTURE_TRANSPORT`. `TRANSPORTATION`
was formerly `TRANSPORT`. Both were standardised in March 2026 — update any data
references that use the old codes.

---

### Adding a new topic category

Three changes required:

1. Add the code and display name to `TOPIC_DISPLAY` in `votd.tsx`
2. Add the code and inline SVG string to `TOPIC_ICON_SVG` in `votd.tsx` — source path
   data from the corresponding file in `assets/icons/vote topic icons/`
3. Ensure at least one `MockVoteItem` (or live vote) uses the new topic code so
   `pickTopicCards()` can select it

---

### Connecting to live data

`pickTopicCards()` reads from `MOCK_VOTE_ITEMS` and `MOCK_CLOSED_ITEMS`. When
`PREVIEW_MODE = false`, replace those constants with live API results conforming
to the `MockVoteItem` type. No changes to `TopicTopVoteCard` or the feed JSX required.

---

## What Makes VOTD's Data Unique

VOTD collects **verified, geo-tagged, jurisdiction-linked civic votes** from real residents.
That combination — verification + geography + government tier — is what no other platform has.

- Verification means the data isn't gameable. 1 person = 1 vote.
- Geo-tagging means you can compare across jurisdictions, neighbourhoods, and tiers.
- Government linkage means the vote topics map directly to real decision-making bodies.

The insight opportunity is not just "what people think" — it's **where opinion diverges from
representation**, and at what tier of government that gap is widest.

---

## Statistical Significance Model

### Core principle
Significance is **relative to jurisdiction size**, not absolute. 500 verified votes means
something very different for a special district vs. a federal issue.

### Threshold formula (v1 — Sacramento pilot)

| Confidence tier | Min responses | Min % of registered voters | Label shown on feed |
|----------------|--------------|---------------------------|---------------------|
| **Signal**     | < 100        | any                        | Not surfaced publicly |
| **Indicative** | 100+         | ≥ 0.5%                    | "Early indication — X verified residents" |
| **Representative** | 300+    | ≥ 2%                      | "Platform finding" |

> Source for registered voter counts: California Secretary of State county-level data.
> Update these denominators when expanding beyond Sacramento.

### Sacramento pilot jurisdiction population reference

| Jurisdiction | Body | Tier | Registered voters (approx) | 0.5% threshold | 2% threshold |
|---|---|---|---|---|---|
| Sacramento City | City Council | MUNICIPAL | 270,000 | 1,350 | 5,400 |
| Sacramento County | Board of Supervisors | COUNTY | 750,000 | 3,750 | 15,000 |
| SMUD | Board of Directors | SPECIAL_DISTRICT | 630,000 accounts | 3,150 | 12,600 |
| SacRT | Board of Directors | SPECIAL_DISTRICT | ~500,000 service area | 2,500 | 10,000 |
| Sacramento City USD | Board of Education | SCHOOL | ~50,000 households | 250 | 1,000 |
| EGUSD | Board of Education | SCHOOL | ~60,000 households | 300 | 1,200 |
| California (state) | Legislature | STATE | 22,000,000 | 110,000 | 440,000 |
| United States | Congress/Federal | FEDERAL | 240,000,000 | 1,200,000 | 4,800,000 |

> **Note:** State and federal thresholds are aspirational at pilot stage. For those tiers,
> surface only behavioral observations (engagement, deadline spike, topic distribution)
> until VOTD has multi-city scale. Never publish a percentage claim on a federal issue
> based on Sacramento data alone — only "X Sacramento residents voted..."

### Demographic concentration caveat
Percentage thresholds alone are not sufficient. A 2% response rate concentrated in one
zip code is not representative. Track geographic distribution of respondents per vote item.
Flag concentration risk internally. Add a "geographic spread" variable to the sig model
in Phase 2 when user base is large enough to measure it.

---

## What to Publish at Each Stage

### Months 1–3 (pilot, ~60 votes, small user base)

**Valid to publish:**
- Running totals: total verified votes cast, total residents participating, total issues covered
- Top topic by raw engagement: "Housing has generated the most votes this month"
- Behavioral observations: deadline spike curve, day-of-week patterns
- Per-item results once a vote closes (raw counts + %, clearly labelled with N)

**Do not publish as insight:**
- Cross-category comparisons ("local vs state preference")
- Consensus claims without hitting Indicative threshold
- Any federal-level opinion claim

**Sample early insight cards (appropriate for this stage):**
1. "2,847 verified Sacramento residents have cast votes across 23 civic issues since launch" — momentum, no comparison needed
2. "Housing has generated more verified votes than any other category this month" — observation, not ratio
3. "Most votes are cast in the final 72 hours. Three votes close this week." — behavioural + call to action

### Months 4–12 (growing data, 200+ votes)

Unlock cross-topic comparisons within the same jurisdiction once both sides of the
comparison have hit Indicative threshold. Introduce the "Indicative" badge on feed cards.
Begin tracking geographic spread.

### Year 2+ (multi-city, scale)

Cross-jurisdiction comparisons become the core differentiator. Introduce "Representative"
findings. Begin producing downloadable civic data reports for researchers and journalists.
Consider a public API for verified aggregate data.

---

## The Three Insight Types (permanent framework)

**1. Volume / engagement insights**
What is the community paying attention to? Which topics, tiers, jurisdictions are generating
the most participation? These are valid from day one — they require counting, not comparison.

**2. Opinion insights**
What does the community think? Requires hitting Indicative threshold. Always show N alongside
percentage. Never strip the denominator. Language: "X of Y verified residents said YES."

**3. Divergence insights**
Where does local opinion differ from state or federal direction? Where do verified residents
disagree with their elected representatives' positions? This is the long-term differentiator.
Requires scale and multi-tier data. Do not rush to this — when it arrives it will be powerful
and needs to be bulletproof.

---

## The Three Launch Insights (agreed March 2026)

These are the three Platform Insight cards for the pilot. Chosen because they are valid
from day one — no cross-comparison, no stat sig risk — and each tells a different story.

---

### Insight 1 — When People Vote (wave chart)

**What it shows:** A bar or wave chart of votes cast by hour of day or day of week.
Reveals when the community is most civically active.

**Why it works early:** Pure behavioral observation. Valid with even 50 votes.
Gets richer and more interesting as volume grows.

**Data required:** `created_at` timestamp per vote cast. No thresholds.

**Display:** Small bar chart (7 bars for days of week, or 24 for hour of day).
Stat: peak day/time. Caption: "Sacramento votes most on [day] evenings."
Label: "Voting patterns · [N] verified votes analysed"

**Pull-down tier 2:** Same chart zoomed to current week vs. last week.

---

### Insight 2 — Most Popular Vote Themes

**What it shows:** Topic categories ranked by total verified votes cast.
Reveals what the community is most engaged with.

**Why it works early:** Counting, not comparing ratios. Valid from first week.
Housing and infrastructure likely dominate early — that's a real signal worth surfacing.

**Data required:** `topic` field per vote item + total vote counts. No thresholds.

**Display:** Horizontal bar chart, top 5 topics. Longest bar = most votes.
Stat: top topic name. Caption: "Housing is Sacramento's most-voted issue this month."
Label: "Topic engagement · [N] votes across [X] topics"

**Pull-down tier 2:** Same chart filtered to closed votes only (settled record).

---

### Insight 3 — Closest Race

**What it shows:** The open vote currently with the tightest yes/no split.
Creates genuine urgency — this one isn't decided yet, and your vote counts more here.

**Why it works early:** Live tally, no representativeness claim needed. Works with 10 votes.
Doubles as a call to action — most compelling reason to vote *right now*.

**Data required:** `yesCount`, `noCount` per open vote item. No thresholds.

**Display:** Single item — question title, jurisdiction, live tally bar, margin stat.
Stat: margin percentage ("3 points separate YES and NO").
Caption: "The most contested vote on the platform right now."
Label: "Live · [N] votes in · closes in [X] days"
Tapping the card navigates directly to that vote item.

**Pull-down tier 2:** Second-closest race.

---

---

## Insights Breaker — Content & Series Spec (agreed March 2026)

### Content stack

Five elements, each doing distinct work. No element repeats another.

| Element | Job |
|---|---|
| **Headline** | The takeaway — one step beyond what the graphic shows. Not data, the conclusion. Self-explanatory without context. |
| **Badge** | Series identity — the named lens this insight belongs to. Sets frame, not description. |
| **Caption** | The so-what — context, implication, reason it's interesting. Never restates headline, never describes graphic. |
| **Graphic** | Evidence — W6 area line or T3 rank bars. Supports headline, doesn't carry it. |
| **Foot** | Provenance — `n votes · geography · time period`. Load-bearing, not editorial. |

**Headline rule:** Must be a claim or conclusion, not an observation. "3× more active on Tuesdays" passes. "Tuesday evenings" fails. A bare percentage ("Up 18%") fails without context establishing what normal looks like.

---

### Series taxonomy

Nine named series. Badge stays constant across platform and personal — headline and caption carry the angle.

| Badge | Mode | Chart | Description |
|---|---|---|---|
| What Moves Us | P · B | T3, W6 | Topic trends, geo trends, volume |
| Fresh Tracks | B | T3, W6 | Disparities, contrarian patterns. Always curiosity/discovery framing — never outlier-shaming |
| Timing is Everything | P · B | W6 | Everything about when — day, time, deadline spikes |
| Hot Streaks | B | T3, W6 | Momentum, consecutive activity — topic, geo, or personal |
| Close Calls | P | T3 | Tight races, margin as the story |
| (Nearly) Unanimous | P | T3 | Landslides, strong consensus |
| Not Obvious | P · B | T3, W6 | Anomalies, surprises. Only runs when signal is clear |
| On the Record | U | T3, W6 | Personal history, quarterly rollups, milestones. Never platform |
| Personal Insights | U · v2+ | T3, W6 | Demographic context, cohort identity. Requires data pipeline + earned trust |

P = platform · U = personal · B = both

---

### Platform vs personal copy mode

**Platform insights** — aggregate data, same for every user. Headline can be a sharp editorial claim because you're writing once for everyone. Named series identity works. Editorial voice achievable.

**Personal insights** — data generated at runtime, different per user. Badge must be a stable container rather than editorial claim: `Your civic snapshot · Q4 Sacramento`. Functional label (Option A) by necessity. Caption carries the intimacy; headline carries the number.

---

### V1 series for pilot

| Series | Chart | Data required |
|---|---|---|
| Timing is Everything | W6 | `created_at` timestamp per vote. No threshold. |
| What Moves Us | T3 | `topic` field + vote counts. No threshold. |
| Close Calls | T3 | `yesCount` / `noCount` per open item. No threshold. |
| On the Record | T3, W6 | Per-user vote history. Personal only. |

All v1 series are valid from day one — no statistical significance threshold required. Each maps to one of the three pilot insight cards (FM.T1.6, FM.T1.12, FM.T2.5).

---

## Platform Insight Module — Feed Design Notes

M9 in the Daily Feed. Three cards appear in sequence — one per insight type.
Gets **distinct full-width card treatment** — different from all other modules because
it surfaces aggregate intelligence, not a single vote item.

### Freshness model — decided March 2026

**Two of the three cards are breakers, not live data feeds.**

- **When People Vote** (wave chart) and **Most Popular Themes** (topic bars) are
  editorially stable. They will not meaningfully change day-to-day in the first
  6 months. Rather than pretending they are fresh news, they are designed as
  *feed breakers* — visually distinctive cards that shift the rhythm of the feed
  and provide orientation, not daily updates. No timestamp shown. No "updated today"
  language. They sit in the feed the way a chapter break sits in a book.

- **Closest Race** is genuinely dynamic — the split, vote count, and closing date
  change daily. It retains a live feel with a "Live ·" badge and real-time numbers.

**Why this approach:** With ~60 votes in the first 3 months, the underlying data
for wave chart and topic theme will be largely stable. Designing them as dynamic
cards would require either faking freshness or showing stale-looking numbers —
both worse than the breaker framing. At 6 months post-launch, revisit whether
volume justifies a more live treatment.

**Review trigger:** When total verified votes cast exceeds 500 AND weekly new
vote items exceeds 5, the wave chart and topic bars will have enough movement
to consider promoting them to live data cards. Set a calendar reminder.

### Visual direction

- Full-width card (same horizontal margins as other modules, but taller)
- **Breaker cards (9a, 9b):** White background, no timestamp, editorial tone.
  Stat in brand orange, interpretive caption in body grey. Feels authoritative,
  not provisional.
- **Live card (9c — Closest Race):** Near-black background, "Live ·" badge,
  green/red split bar. Feels urgent and distinct from the two breakers above it.
- Small footer line on each: "Voting patterns · N votes analysed" etc. — honest
  about what the data is without over-claiming.

**Coming later:** Pull-down tier 2 for Platform Insight serves a second insight
of a different type. Closest Race tier 2 = second-closest race.

---

## Open Questions — Return to These

These are the questions we will be asked by investors, press, and civic partners.
Revisit this list at each funding milestone and before any public launch.

1. **What is your claim about representativeness?**
   Draft answer: We do not claim to be a scientific poll. We claim to be a verified
   civic participation record. Every result is labelled with N and % of registered voters.
   The value is trend and engagement data, not margin-of-error survey science.

2. **How do you prevent coordinated voting / manipulation?**
   Address verification is the primary defence. What additional signals do we monitor?
   (velocity, device fingerprint, geographic clustering) — needs a formal fraud model doc.

3. **What happens when a VOTD result contradicts an elected official's position?**
   This is the moment of maximum visibility and maximum risk. We need a comms framework
   for this before it happens, not after. Do we reach out to the official? Do we publish
   the gap? What's our editorial stance?

4. **Who owns the data? Can it be subpoenaed?**
   Legal question. The aggregate data is ours. Individual votes — even verified ones —
   need a privacy framework. Needs legal review before public launch.

5. **How do you handle low-turnout jurisdictions where a small group could dominate?**
   The sig model thresholds are the primary answer. But also: do we suppress results
   below threshold from public view entirely, or show them with a clear caveat?

6. **What is the path from "interesting civic data" to "consequential civic data"?**
   The divergence insight type (local opinion vs. representative action) is the answer.
   But it requires scale. What's the milestone at which we can credibly make that claim?

7. **How do you weight votes from different demographic groups?**
   We don't, initially — one verified resident, one vote. But we track demographic spread
   and will need to address weighting if the user base is systematically skewed. When does
   that become a responsibility rather than a Phase 2 problem?

8. **What does "verified" actually mean — and what doesn't it mean?**
   It means address-verified Sacramento resident. It does not mean: registered voter,
   eligible voter, or demographically representative. Be precise about this claim every time.

9. **Should the wave chart and topic bars be promoted to live data cards?**
   Currently designed as feed breakers (stable, editorial, no timestamp) because early
   data volume doesn't justify a live treatment. Review when: total verified votes > 500
   AND weekly new vote items > 5. If both thresholds met, the underlying data will have
   enough daily movement to warrant a "Updated today" badge and live framing.
   *Set for review: ~6 months post-launch.*

---

## Prompts for Future Sessions

Use these to re-engage on this topic efficiently:

```
"Open docs/platform-insights.md and let's revisit the stat sig model —
we now have [X] votes and [Y] users. Which thresholds can we unlock?"

"We're about to talk to [investor / journalist / civic partner].
Read docs/platform-insights.md open questions and help me prep answers."

"It's been 3 months since launch. Read platform-insights.md and tell me
which insight types we can now surface on the feed that we couldn't before."

"We need to design the Platform Insight card (M9). Read platform-insights.md
feed design notes section and let's build it."

"Someone is pushing back on our data claims. Read platform-insights.md
and help me stress-test our representativeness argument."

"We're ready to build [module name]. Read the Header/Evidence/CTA section
of platform-insights.md and design the component — header, data display,
and CTA — to the spec."

"We're building FM.T1.4 or FM.T2.3. Read platform-insights.md for the
filter logic definition and build the module."
```

---

*Last updated: March 2026 — Sacramento pilot, pre-launch. Insights Breaker series + content spec added.*
*Next review: at 100 verified users, or before any press / investor conversation*