HXR Development

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.

View development item →

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.

View development item →

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.

View development item →

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 40-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.

View development item →

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.

View development item →

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.

View development item →

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.

View development item →

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.

View development item →

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.

View development item →

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.

View development item →

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.

View development item →

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.

View development item →

Public Case Registry

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

View development item →

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.

View development item →

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.

View development item →

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.

View development item →

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.

View development item →