# Responsible America — Roadmap

Status: living document, last honestly checked against the actual
repository contents on 2026-07-30. Where this document says "done," it
means the corresponding files exist on disk as of that check, not that
the work is polished or final. Where it says "not started," that is
literal — no files exist for that phase.

## Phase 0 — Audit and preservation

**Status: DONE.**

A full repository audit was performed before any Responsible America
content was added, confirming this repository's prior content (GusPro)
and that no prior Responsible America material existed anywhere in it.
See `docs/project-inventory.md` for the full record, including the
namespace decision that keeps Responsible America's files
(`docs/*.md`, `data/`, `responsible-america/`,
`tests/responsible-america/`) from colliding with GusPro's existing
structure.

Next steps: none — this phase is closed. If the repository's contents
ever change in a way that could affect the namespace decision (e.g.
GusPro adds a root-level `data/` directory), re-run the audit and amend
`docs/project-inventory.md`.

## Phase 1 — Foundation

**Status: mostly done, actively being finished.** Verified on disk on
2026-07-30:

- Taxonomy: `data/policy-sections.json` exists (17 divisions, 20
  lettered sections A–T, levels, `reform_statuses` enum, Issues
  Laboratory topics, the 28-question Responsible America Test).
- Schemas: `data/schemas/` contains `reform.schema.json`,
  `source.schema.json`, `claim.schema.json`, and
  `court-case.schema.json`.
- Governing docs present under `docs/`: `project-inventory.md`,
  `project-charter.md`, `project-constitution.md`, `governance.md`,
  `architecture.md`, `research-methodology.md`, `content-model.md`,
  plus this roadmap, `docs/open-questions.md`,
  `docs/change-log.md`, `docs/developer-handbook.md`, and
  `docs/citizen-action-policy.md`.

Not yet confirmed present as of this check: `docs/fact-checking-policy.md`
and several other governing docs referenced by name in the master
brief (editorial policy, source policy, AI usage policy, legal review
policy, security & privacy, threat model, accessibility, testing
strategy, disaster recovery, internationalization, performance goals).
Some of these may be landing concurrently with this document from other
work in progress — check `docs/` directly for the current file list
before assuming any specific one is missing or present.

Next steps:
1. Confirm all governing docs named in the master brief exist under
   `docs/` and cross-link correctly (this roadmap, `governance.md`,
   and `architecture.md` already reference several that must exist for
   those references to resolve).
2. Add `data/sources/`, `data/claims/`, `data/court-cases/` directories
   once the first records that need them exist (referenced by
   `docs/architecture.md` §4 as planned, not yet created as of this
   check).
3. Write the first validation tests under `tests/responsible-america/`
   (currently empty/nonexistent — see Phase 2 note below) so Phase 1's
   schemas are actually exercised by `node scripts/ci.mjs`, not just
   defined.

## Phase 2 — Public platform

**Status as originally checked below: NOT STARTED as implemented
output.** This has since changed — **Phase 2 is now in progress** as
of 2026-07-30; see the dated status update at the end of this
document for current scope. The snapshot immediately below is left
unmodified as an honest record of what was true when it was last
checked against disk, though architecture and
content-model design for it is done. `ls responsible-america/` returns
empty — no `index.html`, no `css/`, no `js/` exist yet as of this
check. `docs/architecture.md` fully specifies the intended design
(static, dependency-free, client-side `fetch()` of `data/` JSON), so
the design work for this phase is finished; the build work is not
started.

Planned scope (from the master brief), none of it built yet:
- Homepage
- Plan index (list/filter of all reforms)
- Section pages (one per taxonomy section A–T)
- Reform-detail page template
- Methodology page
- Source display (rendering a reform's `sources`/`primary_sources`/
  `secondary_sources` against `data/sources/`)
- Revision history display (rendering a reform's `change_log`)
- Issues Laboratory index (rendering `issues_laboratory_topics` from
  `data/policy-sections.json`)
- About page

Next steps:
1. Build the minimal site scaffold (`responsible-america/index.html`
   plus `css/`/`js/`) that can render at least one real reform record
   end to end, per `docs/architecture.md` §2's stated goal of proving
   the data model against a real rendering surface.
2. Build the reform-detail template first (highest information
   density, exercises the most schema fields), then the plan index,
   then section pages.
3. Add tests under `tests/responsible-america/` for each page as it's
   built, so `node scripts/ci.mjs` starts actually gating this work.

## Phase 3 — First 20 priority reforms as draft records

**Status: NOT STARTED as implemented output.** `ls data/reforms/`
returns empty as of this check — zero reform record files exist yet,
despite `data/reforms/` existing as a directory. Work on this is
understood to be in progress concurrently (per the project-inventory
audit and this session's other work), but nothing had landed in
`data/reforms/` at the time this roadmap was last checked against
disk.

Next steps:
1. Draft the first 20 reform records per
   `docs/developer-handbook.md` §5, each `status: "draft"`,
   `publication_status: "draft"`, `fact_check_status:
   "pending_review"`, with real (not placeholder) answers to every
   required schema field, and no invented statistics — any numeric
   claim needs either a real source or an explicit `pending_review`/
   `not_applicable` status on the relevant fiscal-estimate field.
2. Populate `citizen_actions` and `contact_targets` on each record per
   `docs/citizen-action-policy.md` §2–3.
3. Validate each record (`docs/developer-handbook.md` §4) before
   considering it complete for this phase.
4. Once Phase 2's site scaffold exists, wire these 20 records into it
   as the first real content the site renders.

## Phase 4 — Citizen Action Center

**Status: NOT STARTED.** No representative-lookup data, no
contact-routing logic, and no UI for this exists anywhere in the
repository as of this check. `docs/citizen-action-policy.md` defines
the design intent and hard prohibitions this phase must honor once
work begins, but that document is policy, not implementation.

Next steps (once Phase 2/3 are far enough along to prioritize this):
1. Decide the data source for representative/jurisdiction lookup (e.g.
   a congressional district API, a maintained public dataset) — not
   yet chosen; this is a candidate for `docs/open-questions.md` if it
   isn't already listed there.
2. Design the `data/` shape for contact-target records (office name,
   jurisdiction, official contact channels, last-verified date) —
   distinct from, but linked to, each reform's `contact_targets` field.
3. Build the lookup interface (find-your-representative flow) as a
   read-only feature first — no write path, no message-sending
   automation, consistent with `docs/architecture.md` §6's statement
   that no auth/write-path work happens until it's actually needed.
4. Only after the read-only lookup is solid, evaluate whether any
   message-composition assistance is safe to build under the hard
   prohibitions in `docs/citizen-action-policy.md` §4 (in particular:
   never build anything whose function is to mass-blast a single
   office).
5. Design and build the structured-reaction public engagement
   mechanism described in `docs/citizen-action-policy.md` §5, including
   its moderation rules — this needs a real write path and therefore
   real authentication/abuse-handling, which is itself a trigger listed
   in `docs/architecture.md` §3 for moving off the current static-site
   architecture.

## Phase 5 — Accountability systems

**Status: NOT STARTED.** No politician scorecards, campaign-finance
data, lobbying data, corporate profiles, court-case database, spending
comparisons, or money-flow tools exist anywhere in the repository.
`data/schemas/court-case.schema.json` exists as a schema, and
`reform.schema.json` has a `politician_positions` array field
anticipating this phase, but no actual entity data has been populated
under `data/court-cases/` or any equivalent politician/corporation
directory (none of which exist yet).

Next steps (not to be started before Phases 2–4 are substantially
complete):
1. Decide entity population strategy (manual research vs. automated
   ingestion vs. hybrid) — see `docs/open-questions.md`, this is
   explicitly unresolved.
2. Design `data/politicians/` and `data/corporations/` record shapes
   and schemas (neither exists yet), following the same file-per-record
   pattern as `data/reforms/` per `docs/architecture.md` §4.
3. Populate `data/court-cases/` records referenced by
   `reform.relevant_court_cases`, which today is just an array of
   free-text case names/citations with no backing records.
4. Build campaign-finance and lobbying-data ingestion only once a
   concrete, reliable public data source is identified and the
   automated-ingestion groundwork from Phase 6 exists to support it
   responsibly (unattended ingestion needs a review queue, not
   auto-publish — see Phase 6).

## Phase 6 — Automated research pipeline

**Status: NOT STARTED.** No ingestion scripts, no review queue, and no
scheduled job infrastructure exist in this repository. `docs/architecture.md`
§3 explicitly lists "ingestion automation" as one of the three concrete
triggers for moving off the current static-file architecture, and notes
this needs "a real job queue and idempotent processing, not a script a
human runs by hand" — none of that exists yet, by design, at this phase.

Next steps (not to be started before there is a real backend per
`docs/architecture.md` §3):
1. Identify candidate automated source feeds (e.g. GAO/CBO/CRS report
   feeds, court opinion databases, official bill-tracking APIs).
2. Design the review queue: automated ingestion lands candidate
   source/claim records in a `pending_review` or equivalent state,
   never auto-published, never auto-attached to a reform's `sources`
   array without human review — this mirrors the "review queue, not
   auto-publish" principle already stated in the master brief and
   should be treated as non-negotiable when this phase is designed in
   detail.
3. Choose the job-queue/scheduling mechanism only once a real backend
   exists (Phase 4/5's write-path needs will likely force that backend
   decision before Phase 6 does).

---

## 2026-07-30 — Phase 2 in progress

**Status: Phase 2 is now in progress**, superseding the "NOT STARTED"
snapshot recorded in the Phase 2 section above (that snapshot is left
in place as an honest record of what was true when it was last
checked against disk; this section reflects the current state as of
today's date). This is a high-level status note, not a
deliverable-by-deliverable log — visibility into everything happening
concurrently in Phase 2 is incomplete, so scope and intent are
described here rather than an exact file-level inventory.

Work understood to be underway or newly landed as of this date:

- **Site architecture, navigation, and accessibility hardening** —
  strengthening the page structure and navigation described in Phase
  2's original scope (homepage, plan index, section pages, reform
  detail template, etc.) against real accessibility requirements
  (`docs/accessibility.md`), not just getting pages to render at all.
- **Source and factual-claim display systems**, being built *ahead of*
  large-scale factual research rather than after it, so that the
  rendering surface for `sources`, `primary_sources`,
  `secondary_sources`, and claim `verification_status` is proven
  correct against real (if still limited) content before it needs to
  carry the weight of dozens of reforms' worth of citations.
- **Issues Laboratory status labeling** — surfacing
  `issues_laboratory_topics` status in the UI, per the taxonomy in
  `data/policy-sections.json`.
- **Citizen Action Center module scaffolding** — structural/UI
  scaffolding only, explicitly marked **Planned, not functional**.
  This is not an implementation of Phase 4 itself; it does not include
  representative lookup, contact routing, or any write path, all of
  which remain out of scope per Phase 4's own next-steps list above.
- **SEO / structured-data foundations** — laying groundwork (meta
  tags, structured data, and the `noindex` handling for draft content
  discussed in the new deployment-readiness analysis) ahead of any
  public deployment, since none has happened yet.
- **Expanded automated tests** under `tests/responsible-america/`,
  building on the Phase 1 next-step to actually exercise pages and
  data as they're built, not just schemas.
- **This deployment-readiness analysis** — see the new "Deployment
  readiness comparison" and "Migration triggers" sections in
  `docs/architecture.md`, the corresponding entry in
  `docs/open-questions.md`, and `docs/owner-decisions-phase2.md` for
  the resulting owner-facing decision list.

**Explicitly NOT started, and intentionally deferred:** mass factual
research across the 20 draft reforms (Phase 3 scope). This is a
deliberate sequencing choice, not an oversight — research effort
should not be spent populating sources and claims at scale until the
source/claim display system built in this phase is verified working
end to end. Doing large-scale research before the display surface is
proven risks having to redo or reformat that research once the display
system's real requirements (e.g. how a claim's `verification_status`
actually needs to be structured to render correctly) are fully known.

Nothing in this update should be read as claiming anything has been
deployed publicly, tested against real user traffic, or approved by
the project owner — none of that has happened as of 2026-07-30.