UXR Canonical Data and Public Projection Architecture

Architecture status

Adopted and operational for new UXR development. Notion is the canonical development environment for UXR's evolving schema, documentation, field contracts, project-development records, and publication-control metadata. Shopify remains the public website, storefront, SEO surface, and derived publication layer.

Canonical source

Canonical UXR meaning is authored and maintained in Notion. Database properties preserve structured facts and governance state; the Notion page body is the authoritative current body of a documentation record.

Shopify Metaobject IDs, Article IDs, and theme resources are implementation mappings. They do not replace stable UXR identifiers.

Public projection

Shopify should receive only the publication-safe fields necessary to render the public UXR experience. Public projection objects are derived records and must not become the editing source for canonical UXR meaning.

During the current Architectural Build Publication Mode, UXR does not divide public cases into separate testing and real-case classes. A public case uses the ordinary derived storefront path from the canonical Notion record.

When Sean explicitly instructs publication, the projection should use the ordinary public-safe fields, anonymization/redaction rules, transformation logic, relationships, content/section generation, Case Library behavior, counts, filters, renderer, and normal search indexing. The fact that UXR itself is under development is communicated by project-wide documentation rather than by assigning each development-period case a special testing identity.

Stricter release-control architecture may become active in a later stage, but it does not currently create a second public representation of the same case.

For documentation, the intended public projection includes stable document identity, approved title and summary, approved body, public document type, public version/revision, publication dates, change summary, discussion question when appropriate, navigation relationships, and synchronization metadata.

Private material does not inherit public eligibility

Private evidence, unredacted screenshots, contributor-identifying material, internal notes, full revision history, migration notes, reviewer-only analysis, field-contract instructions, intake workbench records, private dashboards, and other restricted content remain in the canonical layer unless separately reviewed and approved for a specific public projection.

A relation to a public record never creates publication consent for a private record.

Documentation history

Current document text and historical revision are separate concerns. UXR Documentation stores the current canonical document and its governance/publication metadata. UXR Documentation Revisions & Change Log stores append-only substantive revisions, corrections, authority changes, migrations, milestones, and publication impact.

UXR Development Items & Capabilities separately records what UXR itself is building, why it exists, what demonstrably works now, known limitations, planned functionality, and future direction.

Field semantics

Short property descriptions provide immediate local instructions. UXR Schema Dictionary & Field Contracts provides the longer authoritative semantic contract for important fields, including purpose, requiredness, cardinality, anti-inference boundaries, privacy treatment, public-export behavior, examples, and anti-examples.

A schema change is incomplete until affected field contracts and governing documentation are updated where the change alters meaning.

Migration discipline

Legacy Shopify records are migration sources, not automatically canonical after import. Each documentation record carries an explicit migration state. Metadata-only imports remain incomplete. A document becomes Canonical Verified only after its current body and material metadata have been reconciled sufficiently to serve as UXR's source of truth.

Legacy Shopify IDs and paths are preserved for lineage, redirects, and reconciliation.

Deterministic Shopify cutover enforcement

As of August 18, 2026, the storefront-inaccessible/private HXR Shopify metaobject layer has been retired. The legacy uxr_case and uxr_evaluation definitions were retired after all 19 remaining legacy Shopify Incident identities and all 10 remaining legacy Shopify Evaluation identities were matched one-for-one to canonical Notion records with legacy Shopify IDs and handles preserved as migration lineage. Remaining private proposition, scope, processing-invariant, release/regression, participation, workaround, and related migration-era definitions were also retired after canonical-location or migration-source review.

A post-retirement inventory verified that every remaining uxr_* Shopify definition is storefront: PUBLIC_READ. Shopify therefore contains the public projection/support data model, not a second private canonical HXR data model.

The approved storefront definitions uxr_public_case and uxr_public_evaluation do not require the retired private definitions. Public Case projections carry stable Case identity directly; public Evaluation projections carry the canonical source Evaluation ID directly and relate to public projection records as needed.

This makes the routing boundary structural rather than merely inferential: canonical HXR records are authored in Notion. Explicit publication derives only the approved public/storefront projection from that canonical Notion state. Retired private definitions must not be recreated merely because historical references or migration records still mention them.

Projection-native Case and Evaluation publication

The target ordinary Case/Evaluation publication path is two record-specific steps only:

1. Author and maintain the canonical Incident/Evaluation graph in Notion.
2. Synchronize the approved public-safe payload into uxr_public_case and/or uxr_public_evaluation and set the projection's public state as part of that same synchronization transaction.

After step 2, storefront discovery and rendering must be consequences of the projection itself rather than additional per-record publication work. Ordinary publication must not require creating a Shopify Article, attaching an Article metafield, creating a separate Case Library index/card/composition record solely for discoverability, or remembering another manual inclusion step.

This pattern already exists in HXR Documentation v2: uxr_public_document_v2 records are directly enumerable by the storefront and render through their native Shopify metaobject URLs. On August 18, 2026, the same projection-native architecture was staged for uxr_public_case and uxr_public_evaluation: both public projection definitions now have Shopify Online Store and renderable capabilities enabled, their legacy article_handle fields are optional compatibility metadata rather than publication prerequisites, and an unpublished staging theme named HXR PROJECTION-NATIVE CASES - AUG 18 enumerates the public projection collections directly and provides native Incident/Evaluation detail templates.

Cutover state: staged, not yet the live Case Library renderer. Until the staging theme is deliberately published and the live Cases index plus native detail pages are read back successfully, the existing live article-centric renderer remains the active storefront path. Existing Articles may be retained as legacy compatibility/redirect history during migration, but future ordinary publication is intended not to create them.

The post-cutover acceptance condition is behavioral: a newly synchronized eligible public Case/Evaluation projection with no Article wrapper must automatically appear in the Cases library, participate in search/filter/sort behavior, and open a complete public detail page through its native system.url. If that does not happen, publication is not complete even if the projection object itself is ACTIVE.

Delta projection

The projection path compares the applicable canonical public-safe payload with the last successfully synchronized payload. If the deterministic payload hash is unchanged, no Shopify write should occur. If it changed, the publisher should update or create the projection, read it back, record the new hash/version/time, and append an operational sync record.

During Architectural Build Publication Mode, this mechanism is used for ordinary public case projection after Sean explicitly instructs publication and the substantive permitted-use, privacy/redaction, provenance, and canonical-scope requirements pass. A successful delta sync or active Shopify record still does not by itself prove completion; the live public result must be read back and verified.

Publication failures must preserve their actual class: application safety block, Shopify platform limit, schema/API error, validation failure, or readback mismatch should not be conflated.

Server-side execution

The publication process is intended to run in a cloud/server execution environment rather than on the founder's local computer. Manual publication remains available for testing and exceptional cases, but ordinary approved deltas should not depend on a desktop session.

Current implementation boundary

The Notion canonical architecture, revision ledger, development registry, publication sync ledger, Entity foundation, field-contract structure, projection mapping, and publication controls are operational, and the storefront is now being used as an active development surface.

Shopify remains projection-only. It does not restore Shopify as the canonical authoring/data layer. During Architectural Build Publication Mode, cases and Evaluations that Sean explicitly instructs to publish use the ordinary live storefront path so maintainers can inspect what the real public schema, indexes, counts, filters, relationships, search discovery, and templates actually produce.

Current public-projection rule

Notion remains canonical when the applicable record is Canonical Verified. Shopify remains the derived storefront layer.

During Architectural Build Publication Mode, Sean's explicit instruction to publish a specific case or Evaluation authorizes the complete ordinary public-projection transaction after the substantive permitted-use, privacy/redaction, provenance, and canonical-scope requirements pass.

A public case should use the same ordinary data model and public behavior UXR intends users to encounter: normal Case Library inclusion, counts, filters, pagination, relationships, renderer, and search indexing. Do not create a special testing representation merely because the overall project remains under development.

The stricter Release Broker, regression, semantic-review, Release Gate, and Human Release Approval architecture remains preserved for a later stage. Reintroducing those controls as the default publication boundary requires an explicit development-stage decision rather than inference from system maturity.

Projection-Native Source and Evidence Graph

Canonical Sources, Source Snapshots, Evidence Items, Evidence Contributions, and Source Engagements remain authored in Notion. Shopify receives only publication-safe source, evidence, relationship, bundle, dataset, reform, and engagement-summary fields needed for the public experience.

The public projection must preserve the graph in visible human-readable form. Google and other public consumers do not see Notion relations. Therefore, an eligible public Evaluation or Incident must render its evidence synthesis, attributable observation summaries, why each item matters, source provenance, limitations, shared dependencies, organization response, reform state, and descriptive crawlable internal links in the page HTML.

A public count without its meaning is insufficient. Public totals must distinguish Evidence Items, distinct Source records, distinct source pages, distinct public reporter accounts when supportable, distinct platforms, direct HXR artifacts, organization-authored sources, corroborating reports, counterevidence, and reform evidence. These counts describe coverage and dependency; they are not prevalence, truth votes, severity scores, or credibility scores.

Separate Public Projection Types

The existing public Evaluation definition is at its field-capacity boundary. Source and evidence growth must therefore use separate public projection/support types rather than overloading the Evaluation object. The intended projection family is:

• uxr_public_source for substantive public Source pages;
• uxr_public_evidence for substantive public Evidence Item pages;
• uxr_public_evidence_link for publication-safe Evidence Contribution edges rendered inside related pages, normally without standalone indexable pages;
• uxr_public_evidence_bundle for deterministic grouping, ordering, counts, and pagination keyed to a public Incident or Evaluation;
• uxr_public_dataset for versioned publication-safe evidence corpora and downloadable distributions;
• the existing or future governed public reform projection for verified outcome and reform pages.

The renderer should resolve an evidence bundle by stable Incident/Evaluation identity, not by adding another manually maintained inclusion field to a full projection definition.

Public Page-Generation Gate

Canonical existence never automatically creates an indexable Shopify page. A Source, Evidence Item, dataset, Incident, Evaluation, or reform becomes indexable only when it passes publication authority, privacy, provenance, distinct public value, adequate substance, meaningful public relationship, unique canonical URL, visible-text, crawlability, current-state, methodology, and technical-readiness checks.

Support records such as Source Snapshots, Evidence Contributions, Source Engagements, renderer bundles, incomplete drafts, and thin fragments should remain non-indexable by default. Their approved meaning may be rendered within substantive public pages.

The purpose of the gate is not to suppress evidence. It prevents the public system from turning canonical normalization into duplicate, misleading, or low-value pages. HXR may ultimately publish many pages because many records genuinely help people; page count is an output, not the objective.

Evidence Corpus and Dataset Projection

For substantial Evaluations, HXR may publish a versioned evidence corpus containing publication-safe structured metadata and HXR-authored analysis. Dataset pages should expose identifiers, provenance, temporal coverage, version, related Evaluation/Incident identities, evidence roles, limitations, and downloadable CSV or JSON distributions where authorized.

The original source content remains governed by its original author and platform. HXR’s dataset license applies only to HXR-authored metadata, normalization, relationship analysis, and approved derivatives unless a broader right is established.

Discovery and Internal Linking

Public Source, Evidence, Incident, Evaluation, Dataset, and Reform pages should use stable descriptive URLs, canonical tags, accurate material-modification dates, breadcrumbs, sitemaps, crawlable pagination, server-rendered text, and descriptive links in both directions. The public Evaluation must contain enough evidence synthesis to answer the searcher’s problem directly; supporting pages provide depth, provenance, and auditability.

Structured data may reinforce visible relationships through appropriate CreativeWork, Article, Dataset, DataCatalog, Organization, BreadcrumbList, citation, isBasedOn, about, mentions, hasPart, and isPartOf semantics. Structured data must never assert relationships or content not visibly present on the page.

Community Return Projection

A verified organization response, workaround, correction, reform, or regression may generate human-reviewed Source Engagement candidates for the communities whose public reports contributed to the record. Public Source or Reform pages may display approved engagement history and permalinks. Shopify must not automate posting to outside communities or treat the availability of a Source URL as permission to solicit its author.