Documentation

# PARA docs

PARA documentation should read like documentation, not like a backlog or a pitch deck. Browse the thesis, the product model, trust and safety, app access, or the schema reference in whatever order fits what you want to understand.

What lives here

  • An About page that explains the political thesis: identity, flairs, voting, RAQ, agents, and anonymity
  • A Getting started page with short paths for readers, engineers, contributors, and app explorers
  • A How it works section that documents the actual civic route families
  • A Product page that shows the product visually: UI gallery, posts, maps, and civic surface examples
  • A standalone Trust and safety page that explains identity, moderation, verification, privacy, account, and saved-content behavior
  • A standalone Try app page that centralizes the current shared host, build-link request flow, and local run commands
  • A glossary and explicit maturity guide so the docs vocabulary and status language stay consistent
  • Manual schema reference for selected com.para.* records, queries, and definitions, with backend framing appended there
  • A secondary roadmap page for ongoing docs work, outside the main navigation

Structure

## The product already has a clear civic shape

PARA is not one feed and not one profile. The implemented app already works more like a civic stack: Base and My Base act as orientation surfaces, communities are first-class objects, and the route tree already branches into RAQ, cabildeo, representatives, highlights, messages, maps, and profile-specific participation tabs.

Orientation routes
/base, /my-base
Community routes
/communities, /communities/profile/:communityId
Why it matters
The product is organized around civic spaces and navigation hubs, not around a single global feed.

Participation

## Policies, matters, representatives, and cabildeo define the civic layer

This is where PARA stops looking like a generic social app. The source product already includes a policies-and-matters dashboard, policy detail surfaces, representatives, and a structurally rich cabildeo route family with phases, delegated votes, and amendments.

Primary routes
/policies-dashboard, /policy-details, /representatives, /communities/cabildeos/*
Current strength
The cabildeo flow already expresses the deliberation model more clearly than the earlier site did.
Current caveat
Some policy surfaces are still early, so route maturity and data maturity are not the same thing.

RAQ and discovery

## RAQ, highlights, search, map, and compass shape the reading model

RAQ is already more than a quiz. It includes assessment, results, axis discovery, proposals, and open questions. Around that, the product also has search, highlights, memes-and-documents, map, comparison, and compass routes that frame PARA as a political reading and navigation system instead of a pure posting surface.

RAQ routes
/raq, /raq/assessment, /raq/results
Discovery routes
/search, /highlights, /map, /compass
Product reading
Highlights behave as a separate political reading layer, not just as bookmarks with a new name.

Communication

## Messaging and agents sit inside the product

The app already has a proper inbox and conversation model, while agent chat is still an early surface for community or premium agents. That split matters because it shows PARA as a product where conversation, not just posting, is part of the political workflow.

Conversation routes
/messages, /messages/:conversation
Agent route
/agent-chat/:agentId
Documentation stance
Conversations are the stable part of the product. Agent chat should still be described as early behavior with a clear interaction contract.

Why these docs changed

The first version of the site described a generic PARA backend. The second version leaned too far into feature inventory. This version keeps the structure editorial while grounding every page in the current product:

  • PARA for public product surfaces such as communities, policy flairs, voting, RAQ, moderation, verification, representatives, and civic flows
  • watx for backend terminology, service boundaries, and the com.para.* lexicon namespace
  • About for the thesis, Docs for implemented surfaces, Product for a visual product read, Trust and safety for operational guardrails, and Schema reference for technical detail

Read next