HXR Features

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.

Recorded state: 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.

Recorded next steps: 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.

Permanent link →

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.

Permanent link →

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.

Recorded state: 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.

Recorded next steps: 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.

Permanent link →

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.

Permanent link →

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.

Recorded state: 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.

Recorded next steps: 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.

Permanent link →

Case Stewardship Notes and Research Families

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

Recorded state: Two internal non-storefront record types are operational: HXR Case Family / Research Inquiry for broader patterns spanning independently bounded cases, and HXR 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.

Recorded next steps: 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.

Permanent link →

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.

Permanent link →

Development Registry and Changelog

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

Recorded state: 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.

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

Permanent link →

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.

Recorded state: 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.

Permanent link →

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.

Recorded state: Operational HXR 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.

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

Permanent link →

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.

Recorded state: HXR 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.

Recorded next steps: 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.

Permanent link →

Governed Taxonomy Registry

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

Permanent link →

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.

Permanent link →

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.

Recorded state: 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.

Recorded next steps: 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.

Permanent link →

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.

Permanent link →

Living Case and Reform Credit Model

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

Recorded state: 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.

Recorded next steps: 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.

Permanent link →

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.

Recorded state: 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.

Recorded next steps: 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.

Permanent link →

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.

Recorded state: 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.

Permanent link →

Public Case Registry

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

Permanent link →

Public Development Hub and Feature Browser

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

Recorded state: Live on the primary storefront: a first-class HXR Development hub, searchable and filterable Feature registry, per-feature detail pages, registry-driven changelog views, roadmap and current-status access, and prominent Support HXR 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.

Recorded next steps: 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.

Permanent link →

Reviewer Packet Auto-Assembly

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

Recorded state: The published Reviewer Packet page uses the uxr-reviewer-packet template to assemble the full text of published HXR 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.

Recorded next steps: 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.

Permanent link →

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.

Permanent link →

Structured Public Case Composition

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

Permanent link →

Support HXR

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

Recorded state: A public Support HXR page is live and available through site navigation. It currently provides Venmo support.

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

Permanent link →

System Feature Benchmark Registry

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

Recorded state: Live definitions exist for HXR Evaluated Systems, HXR Benchmark Features, HXR Feature Implementations, and private HXR 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.

Recorded next steps: 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.

Permanent link →