Open Decisions Registry

Tracking Pre-Launch Decisions and Their Status

v1.0 · May 13, 2026 · Created as part of v3.7.59

1. Purpose

This document tracks the open decisions identified by the Production Readiness Plan as needing resolution before the platform launches as a public-facing site. Each decision is given a unique identifier, a description of what must be decided, the status of deliberation, the date the decision was last updated, the responsible owner, and a proposed resolution path where one exists.

Status values follow a five-state model: OPEN (no progress beyond identification), RESEARCHING (information being gathered to inform the decision), DELIBERATING (information gathered, decision being weighed), DECIDED (resolution chosen and being implemented), and CLOSED (resolution implemented and operational).

2. Decisions Tracking Table

3. Detailed Analysis Per Decision

3.1 OD-001 — Hosting Provider Confirmation

Context: the platform is currently deployed to Cloudflare Pages. Cloudflare Pages offers unlimited bandwidth, generous build allowances, and DDoS protection at zero cost for the scale the platform currently operates at. However, the long-term commitment has not been formally confirmed.

Decision criteria: bandwidth headroom for projected traffic, build performance, deployment automation capabilities, custom domain support, cost projection over 24 months, vendor lock-in risk, alternative hosting options if Cloudflare changes terms.

Resolution path: by end of Phase 1, document the decision either confirming Cloudflare Pages or laying out a migration plan to GitHub Pages, Netlify, or self-hosted infrastructure.

v3.7.218 status: CLOSED. Cloudflare Pages confirmed as long-term host. The bandwidth and build allowances comfortably exceed projected platform traffic for the foreseeable horizon (current free tier provides unlimited bandwidth and 500 builds per month against actual usage of approximately 3-5 builds per week). Migration plan to GitHub Pages or Netlify documented as fallback if Cloudflare changes its terms or pricing materially. No further action required for this decision.

3.2 OD-002 — Custom Domain Registration

v3.7.218 status: CLOSED. wethepeopleplatform.com is registered to Jason Robertson with autorenewal enabled. The domain is in active use (referenced in [email protected] and in the v3.7.121 external review URL). DNS is configured to point at Cloudflare Pages; HTTPS is provisioned via Cloudflare's automatic certificate management. The previously-implicit confirmation (via working email address and live website) is now explicitly recorded in this registry.

Context: the current URL is a Cloudflare Pages subdomain. While functional, this does not project the seriousness of the platform's policy claims and is harder to remember and share.

Decision criteria: domain name should be memorable, evocative of platform identity, available at a reasonable cost, free of conflicting prior usage, suitable for long-term use without re-branding.

Resolution path: shortlist candidate domains, verify availability through registrar lookup and Wayback Machine archive check, register through a reputable domain registrar with automatic renewal, configure DNS records to point at the hosting provider, set up HTTPS via the hosting provider's certificate management.

v3.7.218 status: DECIDED. Cloudflare Email Routing selected as the inbound email infrastructure provider. The selection rationale is straightforward: the domain is already on Cloudflare (no additional vendor relationship to establish); the free tier covers the platform's low-volume contact-form use case (no expected need for >100 messages per day); Cloudflare automatically provisions the MX, SPF, and other DNS records, minimizing setup complexity; inbound deliverability is reliable based on Cloudflare's published reputation. Setup is pending Jason's execution of the step-by-step procedure: dashboard navigation to Email Routing, addition of destination address with verification, creation of contact@ custom address, optional catch-all configuration, and DMARC record addition. Setup time estimated at 15-20 minutes. Status will transition to CLOSED in a subsequent iteration after Jason completes setup and verifies inbound delivery to [email protected]. DKIM and outbound-mail provisioning are explicitly deferred: the current architecture is inbound-only (contact form forwards to the destination address); outbound mail from @wethepeopleplatform.com is not currently required and would necessitate a separate transactional-mail vendor (Postmark, Resend, or similar) if needed in the future.

v3.7.223 status: CLOSED. Cloudflare Email Routing setup executed and verified. The MX, SPF, and DMARC DNS records are provisioned; the destination address has been verified; the [email protected] custom address routes to the destination; inbound delivery has been confirmed. Optional catch-all forwarding is configured per the v3.7.218 setup procedure. DKIM and outbound-mail provisioning remain explicitly deferred (current architecture is inbound-only; outbound from @wethepeopleplatform.com is not currently required and would necessitate a separate transactional-mail vendor). With OD-003 CLOSED, SITE-32 implementation also ships in v3.7.223. All five pre-launch Open Decisions are now CLOSED.

3.3 OD-003 — Email Infrastructure

Context: the Contact page requires a working form. The form needs an email delivery mechanism that handles inbound submissions reliably and supports the engagement SLA's 5-minute automated acknowledgment commitment.

Decision criteria: deliverability rate, configuration complexity, monthly cost at expected volume, API quality, support for transactional email patterns, GDPR and CAN-SPAM compliance support, integration with the chosen hosting provider.

Resolution path: evaluate SendGrid, Postmark, AWS SES, Mailgun, and Cloudflare Email Routing. Select based on cost-deliverability tradeoff. Configure DKIM and SPF records on the custom domain (OD-002 dependency). Implement the contact form backend (Cloudflare Worker, Netlify Function, or similar serverless function). Test end-to-end including the 5-minute acknowledgment flow.

v3.7.218 status: DECIDED. Solo-maintainer model with explicit scope limits documented. Maintainer: Jason Robertson. Scope limits as follows. (1) Vacation pause: SLA acknowledgment remains operational (5-minute automated acknowledgment continues), but the 5-business-day response time extends during continuous absences of 5-or-more business days; the automated acknowledgment text indicates pause status during such periods. (2) Major life events (illness, family emergency, urgent personal commitment): SLA paused with automatic acknowledgment indicating pause status; response time extends to 10 business days during pause periods; pause duration documented in contact.html and sla.html. (3) Architectural changes (substantive content additions to pillar documents, structural changes to platform infrastructure): remain solo-maintainer decisions with all reasoning documented in the Open Issues Registry (typical OIR section pattern). (4) Operational changes (hosting, email, domain configuration): coordinated by maintainer without formal review process given current scale. (5) Succession placeholder: if maintainer becomes unavailable for more than 30 days without prior arrangement, the automated acknowledgment indicates platform-in-maintenance-mode; the engagement framework on recruit.html preserves the External Review Register and Compensation/Attribution policy for future continuation by another maintainer or successor organization. (6) Transition trigger: the solo-maintainer model transitions to multi-maintainer or formal organizational structure under the Phase 2 trigger event documented in OD-005. Until that trigger, solo-maintainer operation is the documented and honest operational model.

3.4 OD-004 — Maintainer Governance

Context: the platform is currently attributed to a single individual. Engagement SLA commitments (5-minute acknowledgment, 5-business-day response, 99.5 percent uptime) presume maintainer availability. Single-maintainer operation has natural limits.

Decision criteria: realistic time commitment available from the primary maintainer, appetite for expanding to a maintainer team or formal organization, governance model for substantive architectural changes, succession plan if the primary maintainer becomes unavailable.

Resolution path: document the operational model honestly. If solo-maintainer, document the specific scope limits this implies (e.g., what happens when the maintainer is on vacation, what triggers SLA pause). If team or organizational structure, document the governance model and decision-making process. Either way, document on the About or SLA page so visitors understand who they are engaging with.

v3.7.218 status: DECIDED. Phased funding model adopted. Phase 1 (current state): personal project funded from individual savings. Direct costs minimal: domain registration approximately fifteen to twenty dollars per year via existing registrar with autorenewal; hosting at zero cost via Cloudflare Pages free tier; email at zero cost via Cloudflare Email Routing free tier; no required paid tooling. Indirect cost (maintainer time) absorbed without compensation. Phase 1 documented honestly on about.html and recruit.html. Phase 2 trigger: the first paid Kind A-C credentialed external review engagement exceeding 1,000 dollars individual or 5,000 dollars cumulative-annual triggers convening to evaluate nonprofit structure. Rationale for the trigger threshold: at sustained annual reviewer-compensation expense exceeding approximately 5,000 dollars, the arms-length-credibility and tax-handling advantages of a 501(c)(3) structure begin to outweigh the setup overhead (40-80 hours of legal and administrative preparation plus ongoing 10-20 hours per year of governance overhead including board meetings, Form 990 filings, conflict-of-interest policy maintenance). Phase 3 (steady-state): structure determined at Phase 2 trigger; the default expectation is a 501(c)(3) nonprofit corporation with a five-to-seven-member board including subject-matter experts adjacent to the platform's twelve pillar content domains, supported by a hybrid funding mix (small individual-donor contributions, grant funding from policy foundations including Hewlett and MacArthur and others, plus occasional grant support tied to specific reviewer-engagement scopes). Alternative considered and rejected: immediate 501(c)(3) setup before Phase 2 trigger. Rejected because current platform activity does not require the formalization and the setup overhead would displace 40-80 hours of substantive platform-content work that is more valuable at the current stage. Alternative considered and rejected: sponsored project from single donor. Rejected because the concentration risk and appearance-of-influence questions are inconsistent with the platform's stated policy independence. Alternative considered and rejected: episodic grant funding only. Rejected because grant funding from policy foundations is best obtained by established organizations with operating history, not by pre-launch single-maintainer projects.

Relevance note (v3.7.457): This decision is DORMANT, not awaiting action. Phase 1 (personal-savings funding; ~$15-20/yr domain, $0 hosting and email on Cloudflare free tiers, uncompensated maintainer time) remains in effect and is documented on about.html and recruit.html. No funding decision is required until the Phase 2 trigger fires: the first paid credentialed external review exceeding $1,000 individual or $5,000 cumulative-annual, which convenes a 501(c)(3) evaluation. That trigger is coupled to SITE-35 (engaging a credentialed outside reviewer), which is currently ON HOLD, so the funding decision is effectively dormant until outside-review spend begins. Phase 3 default is a 501(c)(3) with a 5-7 member board of pillar-domain experts, funded by small individual donors plus policy-foundation grants (Hewlett, MacArthur) and scoped reviewer-engagement grants. Immediate 501(c)(3) setup was considered and rejected as premature. When reviewing the open items list, treat this as: no action until SITE-35 / Phase 2 spend.

3.5 OD-005 — Funding for Sustained Operation

Context: Phase 3 steady-state operation requires ongoing maintainer time and recurring service costs (domain registration, email service, optional analytics, optional uptime monitoring). Without a sustainable funding model, the platform will eventually face operational degradation.

Decision criteria: alignment with platform values (the platform proposes redistributive policy, which constrains some funding models), maintainer comfort with the funding source, scalability to multi-maintainer operation if OD-004 leads there, time horizon over which funding can be sustained.

Resolution path: enumerate funding options (personal project from individual savings; sponsored project from a single donor; nonprofit structure with multi-donor support; grant funding from policy foundations; user-supported model through individual contributions; some hybrid). Evaluate each against the criteria. Document the selected model on the About page so the funding source is transparent. Track ongoing financial operations against the selected model.

3.6 OD-006 — Cloudflare Queues for Changelog Broadcast

Context: The SITE-32 changelog broadcast endpoint sends subscriber emails inline, iterating the KV store with pagination. This is reliable at personal scale. For a large subscriber list (from a few hundred to roughly one thousand or more), inline sending risks Worker execution limits and lacks automatic retry.

Decision (CLOSED v3.7.700, deferred): The queue-based path is already implemented and ready in worker.js and wrangler.toml (the queue configuration is present but commented). Activation is a one-time step: run wrangler queues create for the queue and its dead-letter queue, uncomment the configuration blocks, and deploy. The worker uses the queue automatically once the CHANGELOG_QUEUE binding is present, and otherwise sends inline. The path is deliberately left inactive because the current subscriber list does not warrant it.

Re-open trigger: Reopen and activate if the confirmed-subscriber count approaches several hundred, or if any broadcast reports failed sends.

3.7 OD-007 — Token-Gated Broadcast Admin Page

Context: Broadcasts are sent with send_changelog.py, a one-command helper that previews the message, asks for confirmation, and posts to the admin-token-gated endpoint. A browser-based admin page (paste token, compose, send) would be more convenient if broadcasts became frequent.

Decision (CLOSED v3.7.700, deferred): Not built. The command-line helper is sufficient for infrequent sends, and a page that stored the admin token would be a security risk. If built later, it must never persist the token.

Re-open trigger: Reopen and build a token-gated admin page (that never stores the token) if broadcast frequency increases to the point where the command-line helper becomes a friction.

3.8 OD-008 — Factual Anchor for CBO Report Vintage

Context: The factual-coverage guard registers load-bearing dated facts (like the Social Security insolvency year) so a data refresh flags any document still carrying a superseded value. A CBO report-vintage anchor was considered.

Decision (CLOSED v3.7.702, not added): The Congressional Budget Office is cited across documents in several different phrasings (long-term budget outlook, budget outlook, a specific month and year, and so on), so a single anchor with tight context and exclude terms would either miss some references or risk false positives. CBO refreshes are also infrequent. The Social Security anchor already covers the single most refresh-prone dated fact.

Re-open trigger: Reopen and add one or more narrow CBO anchors if CBO vintage refreshes become a recurring manual burden.

3.9 OD-009 — Derivations for ltc-net-new and mature-deficit

Context: The derivation-trace layer records how a derived figure is computed from other registry figures and recomputes it in the audit. Two further figures were candidates: long-term-care net-new and the mature-horizon deficit.

Decision (CLOSED v3.7.702, not added): Both require introducing imprecise intermediate figures. Long-term-care net-new is a range derived from a range, so the subtraction is range-arithmetic. The mature deficit equals the current baseline minus an improvement that is not a clean registry value but an interpolation to the 4.28 percent baseline (the registry stores only the 2, 4, and 6 percent scenarios). Adding these would imply a precision the inputs do not have. The five clean, fully registry-backed derivations already demonstrate the pattern.

Re-open trigger: Reopen if a clean intermediate figure becomes available (for example, an explicit baseline-scenario deficit-impact value), or if full derivation coverage is later wanted despite the imprecision.

3.10 OD-010 — Promote Comparative Citations to Structured Provenance

Context: The structured provenance layer (data_recency.json) records every externally sourced number that drives the model, with reciprocal figure linkage. Several comparative citations remain as prose attributions: international long-term-care and childcare models, NTIA (National Telecommunications and Information Administration) and NG911 emergency-services cost figures, and KFF health-outcome comparisons.

Decision (CLOSED v3.7.702, left as prose): These are comparative context, not load-bearing quantitative anchors that the model computes from. Every number that actually drives a pillar cost or the fund model is already in structured provenance. Formalizing the comparative citations would add records to maintain for little analytical gain, and they are properly attributed in prose as they stand.

Re-open trigger: Reopen and promote a specific citation to structured provenance if it becomes load-bearing (for example, if a pillar cost is rebased onto an international benchmark).

4. Update Process

This document is versioned as a regular platform deliverable. Each iteration that changes the status of a tracked decision updates the corresponding row in the tracking table, updates the Last Updated date, and adds a paragraph to the corresponding detailed analysis section describing what changed and why.

Status transitions follow the five-state model: a decision moves from OPEN to RESEARCHING when information gathering begins, from RESEARCHING to DELIBERATING when sufficient information has been gathered, from DELIBERATING to DECIDED when a resolution is chosen, and from DECIDED to CLOSED when the resolution has been implemented and is operational. Decisions can return to earlier states if circumstances change.

When a decision reaches CLOSED, the OIR Section 47 also adds a closing entry summarizing the final resolution. This creates a permanent record in the platform's open-issue history.

Robertson, J. (2026). Open Decisions Registry. We The People Platform (Version 3.8.46). https://wethepeopleplatform.com/_web_html/09_Meta_Tracking/09_Open_Decisions_Registry.html

Robertson, Jason. 2026. "Open Decisions Registry." We The People Platform v3.8.46. https://wethepeopleplatform.com/_web_html/09_Meta_Tracking/09_Open_Decisions_Registry.html.

@misc{wtpp_2026_115_open_decisions_registry,
  author    = {Robertson, Jason},
  title     = {Open Decisions Registry},
  year      = {2026},
  publisher = {We The People Platform},
  version   = {3.8.46},
  url       = {https://wethepeopleplatform.com/_web_html/09_Meta_Tracking/09_Open_Decisions_Registry.html},
  note      = {Document 115 of 142}
}