How the Platform is Structured

Policy Classification

Every position in this catalog has an ID, a type, a pillar, and a legal grounding. None of that is accidental.

The Policy Catalog

This platform maintains a structured policy catalog — a database of every policy position, with its ID, pillar, foundation, classification type, plain-language summary, formal policy statement, and citation record. The catalog is version-controlled, publicly available, and the authoritative source for every position on this platform.

The catalog is organized as a SQLite database with a public schema. Every policy position has a canonical ID in the format DOMAIN-SUBDOMAIN-NNNN (e.g., HLTH-COVR-0001 for a healthcare coverage position). Positions are grouped by domain, subdomain, foundation, and pillar.

The source files, schema documentation, and build scripts are all available in the project repository:

View on GitHub → View Data Directory →

Classification Methodology

Each policy position is classified by its implementation type. This classification determines the legal pathway for adoption, the level of government responsible for enforcement, and how the position is tracked in the policy review process.

Type Description Examples
Amendment Requires a constitutional amendment to enact. These are structural changes to how government works — voting rights, term limits, anti-corruption rules. Congressional term limits, independent redistricting mandate, public financing requirement
Statute Requires federal legislation — an act of Congress. Most policy positions on this platform are statute-level. Universal healthcare, minimum wage, labor rights, drug pricing, antitrust enforcement
Policy Can be implemented through executive action, agency rulemaking, or administrative policy change without new legislation. Agency enforcement priorities, federal contractor requirements, regulatory guidance
State / Local Primarily implemented at the state or local level, or requires federal-state coordination. Tenant protection ordinances, local minimum wage laws, state Medicaid expansion

The Two-Field Requirement

Every policy position in the catalog must have two text representations:

Both fields are required. The plain-language field is not a summary of the policy statement — it is an independent, accessible explanation. This is not an accessibility accommodation. It is a substantive requirement: if a policy position cannot be explained to a person without legal training in two or three sentences, that is a sign the position itself needs more work.

PolicyOS Rule Families

PolicyOS is the cross-platform rules layer being developed in parallel with the policy content. It governs how policy is designed, scoped, enforced, and maintained across the platform. PolicyOS rules have their own ID space (prefixed PLOS- and PAOS-) and are not the same as policy positions.

The current PolicyOS architecture has three layers:

Layer Rule Families Status
Platform Values The moral and political anchor for all rules. floor + duty model — what policy must not violate vs. what it must actively secure. Locked
System Principles Cross-platform design rules. Families: KERN (core principles), GEOG (jurisdiction), FEDR (federalism), REGD (regulatory design), ENFA (enforcement architecture), AIGV (AI governance). Under review
Authoring OS How policy must be written, tested, scoped, enforced, and maintained. Families: NORM (normative framing), AUTH (authoring), TEST (testing), ENFC (enforcement), PLAC (placement), MAINT (maintenance). Under review

PolicyOS rules will not be canonicalized into the main platform until the structural review is complete. For the current status and working files, see the policyos/ directory in the project repository.

ID Format Reference

Policy position IDs follow the v2 format:

DOMAIN-SUBDOMAIN-NNNN

Examples:
  HLTH-COVR-0001   Healthcare / Coverage
  LBOR-WAGE-0001   Labor / Wage
  CLMT-EMSS-0001   Climate / Emissions
  ADMN-CHVS-0001   Administration / Checks and Balances
  TAXN-TAXS-0001   Taxation / Tax Structure

Domain and subdomain codes are defined in the domains and subdomains tables of the policy catalog database. Cross-pillar appearances (where a position is relevant to more than one pillar) are tracked in the position_pillar_appearances table rather than as separate position records.