User Experience Reform

Independent public-interest reporting on how systems affect people.

UXR Development

UXR Features

Browse the features, infrastructure, methodology, publication systems, and development work that make up UXR. Current state is generated from the canonical UXR Feature registry.

Live development registry

Development items and capabilities

Browse the current public development registry. Search by name or description, then filter by status or kind.

Live
7
Pilot
15
Building
1
Planned
0
Other states
2
InfrastructurePilotCurrent Focus priority

Canonical Case Records

Private canonical cases preserve permanent case identity while outcome, reform, verification, monitoring, hierarchy, system attribution, contributor experiences, and comparison states evolve around the same living evidence record.

Current: Canonical cases now use living/nonterminal semantics; separate Case Scope records classify Incident, Mechanism, and System / Practice levels; directional Case Relationships preserve evidence edges; work orders can track canonical and public Outcome / Reform Events; and cases connect to reusable evaluated systems, organizations, routing, evidence, assessments, pathways, contributor experiences, and workarounds without forcing terminal resolution.

Known limitation: The canonical case definition is at Shopify's 40-field limit, so hierarchy and some graph functions live in dedicated related records. Older cases may lack Case Scope, Case-System Links, or new reform-event relationships and require selective migration rather than blanket rewriting.

Planned: Regression-test the living-case graph, selectively align existing cases where new structures add real value, validate public rendering/privacy, and then use the architecture for broader case implementation.

MethodologyPilot

Case Assessment Layer

Versioned analytical assessments separate observed sequence, evidence, uncertainty, system failure, burden, harm, agency effects, responsibility, reform, acceptance tests, capability boundaries, and workaround analysis from case identity.

SoftwarePilotHigh priority

Case Matching and Shared Experiences

Moderated contributor experiences can attach to a living case while preserving perceived system, evaluated systems, candidate benchmark features/implementations, impact, evidence, privacy, consent, and match target level.

Current: The private Case Experience definition now supports list references to evaluated systems, candidate benchmark features, candidate feature implementations, and a moderated target level of Incident, Mechanism, System / Practice, Related but Distinct, or Unresolved.

Known limitation: The schema is live, but no complete public submission form, identity workflow, notification path, abuse controls, or moderator work queue has been launched. A match remains candidate evidence and never becomes a vote.

Planned: Add a moderated public intake that identifies deployment/system scope, preserves differences, supports privacy and consent review, and routes the experience to the correct case level without automatic corroboration.

ProcessPilot

Case Routing and Submission Channels

Case-specific routing records keep candidate and verified recipients, authority questions, submission methods, verification state, and response tracking separate from guessed responsibility.

Case Architecture / InfrastructurePilotCurrent Focus priority

Case Scope and Evidence Graph

Separates Incident, Mechanism, and System / Practice cases and connects them through directional evidence relationships so responsibility can emerge without merging independent histories.

Current: Dedicated Case Scope and Hierarchy records classify living cases as Incident, Mechanism, or System / Practice. Directional Case Relationship records state what each edge supports and does not support. The initial financial graph links delayed-transfer and safe-verification incidents to Business-Day Gating and Asymmetric Consumer Funds Availability without transferring responsibility automatically.

Known limitation: Older cases are not automatically assigned a scope level, and not every case needs a higher-level relationship. Public graph rendering and broader cross-domain regression testing remain incomplete.

Planned: Regression-test support, challenge, contradiction, reform-lineage, and responsibility-reattribution paths; selectively classify older cases where analytically useful; and verify public graph navigation before broad case implementation.

Case Architecture / Internal StewardshipLiveHigh priority

Case Stewardship Notes and Research Families

Internal anti-drift records preserve why a UXR case is bounded as it is and connect independently bounded cases to broader research inquiries without collapsing their evidence.

Current: Two internal non-storefront record types are operational: UXR Case Family / Research Inquiry for broader patterns spanning independently bounded cases, and UXR Case Stewardship Note for case-specific anti-drift guidance. The banking case UXR-2026-0809-0001 is the first implementation, linked internally to the provisional inquiry Asymmetric Control of Consumer Funds Availability.

Known limitation: The new companion records are not yet directly referenced from the 40-field canonical Case object because that definition is at Shopify's field limit. Discovery currently depends on known case IDs, handles, parent records, development documentation, or future tooling. The architecture has only one live pilot family and stewardship note so far.

Planned: Integrate stewardship lookup into intake and case-review tooling; automatically surface internal notes when a future collaborator opens a case; add related-case family navigation; define review/version rules for stewardship notes; and test the architecture against additional multi-mechanism case clusters.

ProcessPilot

Case Update History

Dated case updates preserve additions, corrections, new evidence, changed uncertainty, harm changes, reform changes, and proposed public revisions without overwriting case history.

InfrastructureLivev1.1

Development Registry and Changelog

Canonical current-state and change-history architecture for meaningful UXR features, now recording the Private Alpha opening and failed intake-integrity baseline.

Current: The public changelog now records the August 13 Private Alpha opening, 8-pass/4-fail manual baseline, frozen v1 specification, transcript-result recovery, source-resolution remediation, authoritative result linkage, idempotent writes, draft successor coverage, and contribution invitation.

Known limitation: The baseline did not exercise an executable broker and automation remains unvalidated. Detailed regression scenarios, acceptance criteria, prohibited constructions, and document-to-test mappings remain internal.

Planned: Record the unchanged v1 rerun, purpose-built successor run, executable-broker test, later blind human re-grade, and grader-agreement results as they occur.

ResearchPilot

Evidence Inventory

Private case-bound evidence inventory with provenance, privacy, authorization, claim support/contradiction, and moderated roles for reattribution, reform, positive performance, and better-practice comparison.

Current: Evidence Items now classify one or more contribution purposes and can reference evaluated systems, benchmark features, and specific feature implementations. These relationships remain claim-specific and do not create scoring weight.

Known limitation: Public artifact-level projection and upload workflow remain incomplete. Public card evidence snapshots therefore expose only approved type/count summaries, never private evidence references.

Operations / Intake InfrastructureLiveCurrent Focus priority

Field Semantics and Intake Agent Alignment

Makes live Metaobject field descriptions, types, validations, reference targets, and cardinality rules part of the operating contract so authorized intake agents use the same evidence and privacy semantics.

Current: Operational UXR Metaobject fields carry INTAKE AI descriptions explaining what belongs in each field, what does not, how to preserve uncertainty, and how nearby concepts differ. The cardinality rule now prefers list references when a supported real-world relationship can legitimately involve multiple entities, while singular references are reserved for genuinely singular parents, bounded objects, or projections.

Known limitation: Descriptions cannot replace higher-level governance or detect every future modeling gap. Agents still need to query the live definition, follow the Workbench and publication gates, and escalate architecture gaps rather than improvising.

Planned: Include field-semantics checks in the case-architecture regression test and review older high-use definitions for remaining ambiguous or terminal legacy wording.

Method / Blue Zone Design PrincipleProposedHigh priority

Goal-Oriented Documentation

Document common human goals as end-to-end paths, using the act of documentation to expose unnecessary friction that feature-centered manuals can hide.

Current: UXR now records Goal-Oriented Documentation as a proposed design and evaluation principle. The proposed cycle is: identify a human goal; document the current reliable path; identify unnecessary burden; reform the system; document the improved path; repeat. Attempting to write the goal path functions as an architectural friction test.

Known limitation: The principle is newly proposed and has not yet been converted into a validated Blue Zone criterion or quantitative scoring method. The term Blue Zone is also provisional and expected to be renamed without changing the underlying principle.

Planned: Develop reusable goal-path documentation criteria; test the method against real systems and cases; compare goal paths before and after reform; identify measures such as actions, handoffs, interruptions, prerequisite knowledge, completion time, workaround dependence, and failure recovery; determine how the method should contribute to future positive-system recognition.

MethodologyPilot

Governed Taxonomy Registry

Reusable UXR taxonomy terms carry controlled definitions, authority state, evidence guidance, misuse warnings, public summaries, and case-application rules.

ProcessPilot

Intake, Boundary, and Work Order Workbench

Private intake sessions preserve the contributor interaction; boundary decisions determine case structure; work orders reserve case IDs, authorization limits, record-family state, blockers, next actions, and verified Shopify read-back.

InfrastructureImplemented / Unverifiedv1.1

Intake Integrity Regression and Source Resolution

Versioned internal regression and fail-closed source-resolution infrastructure for preventing unsupported attribution before governed propositions can enter release review.

Current: Frozen v1 suite specification; authoritative run-to-result links; recovered transcript-only rows with limitations; preserved duplicate-write audit history; idempotent attempt/write identity; candidate-proposition and required source-resolution records; adopted no-manufactured-attribution invariant; four internal draft successor coverage items.

Known limitation: The baseline failed at 8 pass and 4 fail, was manual, single-grader, self-graded, and sequential, and did not place an executable broker in the decision path. Remediation has not yet passed a rerun or automated enforcement test.

Planned: Rerun frozen v1 unchanged, execute successor coverage, test the broker in the actual decision path, conduct a later blind human re-grade, and measure manual-versus-automated grader agreement before automation becomes authoritative.

MethodologyPilot

Layered Resolution Model

Immediate remediation, individual remedy, systemic reform, verification, monitoring, and reopening are tracked as distinct resolution layers with independent statuses and acceptance criteria.

Methodology / ProcessPilotCurrent Focus priority

Living Case and Reform Credit Model

UXR cases persist as permanent evidence-bearing records through positive performance, individual outcomes, reform, verification, quiescence, regression, and later superior benchmarks without erasing history.

Current: The living-case model now includes structured Outcome / Reform Events with direct references to supported organizations or units, evaluated systems, benchmark features, concrete feature implementations, evidence, activities, pathways, steps, taxonomy, related cases, and directional relationships. Separate public event projections preserve publication boundaries. Pathways and steps now use list-valued actor/system/feature references when relationships can legitimately be distributed.

Known limitation: The reference graph is implemented, but older saved cases and pathways still need selective alignment where legacy closure or reopening language survives. Public rendering of structured event history and privacy boundaries still needs regression testing. No operational Blue Score weighting exists for improvement credit, current performance, durability, benchmark leadership, or regression.

Planned: Regression-test four core trajectories before broad case implementation: positive from inception; adverse with no reform; adverse to verified reform trophy; and adverse to verified reform, later regression, and stronger second reform. Then reconcile applicable older case records and verify public rendering.

InfrastructurePilotHigh priorityv1.0

Public Case Card Projection

Versioned storefront-safe card summaries expose case level, evaluated system, evidence-graph context, case-bound impact/evidence, comparison relationships, and response/attribution state without duplicating private evidence.

Current: The PUBLIC_READ projection definition and eleven public case-card projections are live as structured data: ten Published v1 projections for the ten published case articles, plus one Draft v2 projection for the unpublished Copilot benchmark article. A validated semantic renderer runs on unpublished review theme 164716085491, displaying case level, approved system/evidence graph context, case-bound impact and evidence, distinct agency effects, independent lifecycle states, and moderated contribution paths.

Known limitation: The renderer is not published. Organization, benchmark-feature, implementation, comparison, and responsibility fields stay empty unless separately publication-approved. Matching and evidence contribution currently route to moderated email intake rather than a public structured form.

Planned: Review the unpublished theme across desktop/mobile and assistive interaction, approve or revise the renderer, then separately decide whether to publish it. Replace email intake with structured moderated forms only after privacy, provenance, anti-abuse, and consent controls are defined.

InfrastructurePilot

Public Case Index

A public-safe discovery layer connects cases to taxonomy, organizations, routing, reform, participation, and the versioned card projection used for semantic case-library presentation.

Current: The index and public case records remain available for filtering and article linkage. A separate storefront-safe Public Case Card Projection now carries approved case level, systems, graph context, impact facts, evidence counts, comparison context, and response/attribution summaries.

Known limitation: Older article/index linkages remain uneven. Card projections currently use deterministic case-ID handles because the public case definition is at Shopify's 40-field limit; a direct public-case reference back to the card cannot be added.

PublicationLive

Public Case Registry

Publication-approved case projections and case articles expose evidence-bounded UXR cases without publishing the private canonical record.

SoftwareLiveHigh priority

Public Development Hub and Feature Browser

A first-class public Development area turns UXR's canonical Feature and Development Event records into browsable features, detailed feature pages, changelog views, roadmap access, and current-status access.

Current: Live on the primary storefront: a first-class UXR Development hub, searchable and filterable Feature registry, per-feature detail pages, registry-driven changelog views, roadmap and current-status access, and prominent Support UXR navigation.

Known limitation: Public completeness depends on the depth and currency of the underlying Feature and Development Event records. Older records do not yet contain equivalent detail, and continued registry enrichment is required.

Planned: Continue enriching Feature records and Development Events, improve cross-linking and discoverability, and expand registry-driven public views without duplicating current-state claims in static prose.

Documentation InfrastructureLiveCurrent Focus priority

Reviewer Packet Auto-Assembly

Dynamically assembles the Complete UXR Reviewer Packet from the current published UXR Documentation articles so new documents and synchronized edits do not require a second manually maintained packet.

Current: The published Reviewer Packet page uses the uxr-reviewer-packet template to assemble the full text of published UXR Documentation articles. Publishing a new documentation article or synchronizing an edit changes the packet automatically without copying that article into the packet page body.

Known limitation: Auto-assembly cannot repair an unsynchronized structured document and linked article. A documentation change remains incomplete until both layers are reconciled, and packet output should be spot-checked after material changes.

Planned: Add a routine post-change completeness check that verifies synchronized documents appear in the rendered packet and flags any structured/article mismatch before documentation work is declared complete.

SoftwareBuilding

Structured Case Workarounds

Workarounds can be stored separately from canonical findings with steps, limitations, outcome equivalence, verification state, platform/version context, and public eligibility.

Known limitation: The data model exists, but public submission, testing, comparison, and display workflows remain under development.

PublicationPilot

Structured Public Case Composition

Public cases are assembled from independently reviewable, reorderable case sections and composition records rather than one undifferentiated body of prose.

SoftwareLive

Support UXR

A project-level support page explains why financial support helps sustain UXR and provides a direct Venmo path without tying money to case findings, priority, weight, or outcomes.

Current: A public Support UXR page is live and available through site navigation. It currently provides Venmo support.

Planned: Additional payment methods and dynamic development evidence can be added without changing the independence boundary.

InfrastructurePilotCurrent Focus priority

System Feature Benchmark Registry

Reusable UXR architecture for evaluating systems against implementation-neutral benchmark features while preserving how each system implements, evidences, limits, and earns credit for each capability.

Current: Live definitions exist for UXR Evaluated Systems, UXR Benchmark Features, UXR Feature Implementations, and private UXR Case System Links. The registry contains 21 reusable benchmark features and seeded GOGov/Covina implementations. Public Feature Implementation records preserve non-sensitive source Case IDs, approved public cases, and publication-safe reform-event projections. Private Case-System Links retain canonical case-to-system-to-implementation relationships and can connect canonical reform events internally.

Known limitation: Feature presence is not an operational Blue Score input. Independent task testing, feature-quality criteria, weighting, domain normalization, durability tests, and a finished public comparison UI remain under development. Public comparison objects deliberately do not expose private canonical case or private case-system-link references.

Planned: Connect additional case evidence to implementations, regression-test reform and benchmark propagation, add implementations from more systems and domains, and expose feature-to-system and system-to-feature public comparisons after evidence and rendering safeguards pass.

Canonical Development Items & Capabilities live in Notion. This storefront contains the publication-safe projection; Development Event records preserve public change history.