UXR Field Semantics and Intake Agent Alignment Standard

Purpose

UXR fields are not generic storage slots. Current canonical field descriptions are local operational instructions, while active Field Contracts define the authoritative semantics of those fields. An Intake AI must discover and read the current canonical Notion schema before writing records rather than relying on an older document, prior thread memory, exported copies, legacy platform fields, or a similarly named historical field.

Mandatory Intake AI startup and field-discovery path

Before processing or writing intake, the agent must follow this order:

1. Read all Adopted records in UXR Processing Invariants that apply to the operation. These are cross-cutting controls for testimony, provenance, attribution, inference, organization-authored evidence, and related integrity rules.

2. Open UXR System Registry and locate the required canonical module. Follow its Canonical Location to the current Notion database. Do not guess a database from its name or from an old platform identifier.

3. Fetch or inspect the current Notion data-source schema for that module. Read the exact property names, types, select options, relations, cardinality, and every UXR AGENT: or INTAKE AI: property description before populating fields.

4. Open UXR Schema Dictionary & Field Contracts and read the Active Field Contracts linked to that module. Property descriptions are concise local cues; Field Contracts are the authoritative field-level semantics and anti-inference boundaries.

5. Read the applicable canonical operating or methodology document for cross-field and process rules.

6. Process the intake through the current workbench rather than writing directly to a convenient final object.

7. After writes, read back the resulting records and verify IDs, relations, provenance, privacy/release state, and any required work-order or release-gate state.

If the System Registry is missing or stale, use 01 — Canonical Data as the discovery fallback, flag the registry drift, and resolve the current database before writing. Do not substitute a historical Shopify definition, GID, exported schema, or prior-thread memory as current authority.

Current internal intake path: Processing Invariants → Intake Sessions → Candidate Propositions → Proposition Source Resolutions → Propositions, with Case Boundary Decisions and Case Work Orders used where applicable → resulting Incident Cases / Evaluations / Evidence / Updates / Handoffs → Release Gates and scoped Human Release Approval when public release is contemplated.

Reverse relations such as incoming/outgoing links are navigation aids unless a Field Contract explicitly makes them an editing surface. Create and edit the canonical relationship/edge record itself rather than manufacturing facts through a reverse relation.

Current Notion Intake Session field map

The live schema remains controlling, but a fresh Intake AI should expect the current UXR Intake Sessions record to organize fields into these functions:

• Session identity and control: Intake Session ID, Intake Session Title, Intake Contract Version, Intake Revision, Intake Workflow State, Created At, Last Updated At.

• Received narrative and source: Source Channel, Received At, Initial Received Narrative Summary, Secure Source Reference, Pre-Case Change Log.

• Contributor, privacy, and authorization: Contributor Label, Private Contributor Reference, Contributor Confirmation Status, Privacy Status, Permitted Use Authorization.

• Active intake analysis: Current Intake Summary, Unresolved Questions, Immediate Risk / Closing Deadline, Candidate Existing Cases, Candidate Evaluations.

• Boundary and workflow records: Boundary Decisions, Case Work Orders.

• Canonical outputs and release: Resulting Cases, Resulting Evaluations, Release Gates.

• Migration lineage only: Migration State, Source Retired, Legacy Shopify Handle, Legacy Shopify Metaobject ID, and Legacy Candidate Proposition Metaobject IDs. These fields preserve migration/audit history; they must not be used to recover obsolete field semantics or override current canonical records.

Active-record query default: when the task concerns current canonical state, current data quality, publication, reconciliation, or active-system behavior, exclude records where Source Retired = Yes unless the task explicitly requires migration lineage, supersession history, recovery, or audit evidence. Retired rows may intentionally preserve the same stable identifier, title, or factual payload as a current row. Their existence must not be reported as a live duplicate, current conflict, or cleanup target until Source Retired and any retention/supersession metadata have been checked.

The Intake AI must resolve relations to the current target database rather than copying display text into a text field. When a relation already exists, inspect the target record and its governing Field Contract before creating a duplicate.

Evaluation contribution configuration fields

The canonical Evaluation schema includes three fields that configure the minimal contribution on-ramp without creating a separate contribution object family:

• Contribution Intake State controls whether one Evaluation is Not Configured, in bounded Pilot testing, Open, Paused, or Closed for new contributions. It is not Evaluation Activity State, publication status, evidence quality, or proof that the public intake route is operational.

• Public Contribution Prompt supplies one short ordinary-language invitation supporting the standard Add Your Experience action. It must not become a menu of contribution types, ask the contributor to classify their own account, presume the current Evaluation finding, or broaden the Evaluation's proposition.

• Minimum Matching Context states only the smallest facts needed to assess material relationship, scope, safety routing, or related-but-distinct status. It must not become a complete intake form or default proof requirement.

Read the three Active Field Contracts before configuring or interpreting these values. When Contribution Intake State is Pilot or Open, route the person's ordinary-language account through the existing Intake Session path. Classify similar, positive, materially different, corrective, contextual, evidentiary, workaround, response, reform, regression, or unresolved roles behind the scenes. A click, short signal, or candidate match does not automatically create an Incident Case, finding, vote, or prevalence claim.

Evidence remains optional unless a specific proposition genuinely requires it. If the contributor supplies a file, apply the canonical Evidence Files transaction without turning file upload into a condition for respecting testimony. Return a plain-language summary of what was recorded, candidate Evaluation relationship, privacy/use state, what the contribution may add, and what it does not establish.

During the current Phase 1 pilot, Pilot applies only to the two configured healthcare-access Evaluations. The field value does not mean the public contribution panel, secure submission broker, or end-to-end intake flow is live; those capabilities require independent implementation and validation.

Core object rule

Incident Case: one bounded real-world occurrence. Store what happened, the contributor objective, chronology, evidence, direct impact or benefit, individual outcome, directly involved systems/organizations, and incident monitoring.

Evaluation: durable analytical synthesis about an evaluable subject. Store cross-incident findings, mechanisms, organization/system performance, reform, positive-practice preservation, regression, comparison, benchmark posture, and Blue Score readiness.

Benchmark Feature: reusable implementation-neutral capability.

Feature Implementation: one concrete implementation of one Benchmark Feature in one bounded system/context.

Do not use Cases as Evaluations

New Incident Scope records must classify a Case as Incident. Historical Mechanism and System / Practice case levels are migration-only. If the new information is a reusable mechanism, organization-wide performance question, system assessment, department pattern, cross-system practice, or benchmarking proposition, create or update an Evaluation instead.

Many-to-many by default when reality is many-to-many

If a real-world relationship can legitimately contain multiple supported entities, prefer a list reference. Use a single reference only when the semantics truly require one canonical parent, one bounded owner, or one projection. One Incident may involve multiple systems and may contribute to multiple Evaluations.

References do not imply equal meaning

A reference does not by itself establish equal responsibility, equal credit, causation, motive, prevalence, importance, or evidentiary weight. Use the dedicated relationship or contribution record to state the role, evidence basis, supported claim, and claims not supported.

Privacy inheritance is prohibited

Private Incident details do not automatically flow upward. Names, emails, exact addresses or coordinates, request/account identifiers, confirmation numbers, phone numbers, and other identifying evidence remain private unless separately approved. Public Evaluations may reference only separately authorized Public Incident projections and public-safe subject records.

Evidence labels remain distinct

Contributor testimony, direct artifact observation, organization-authored statements, independently verified findings, inference, and not-established questions must not be silently converted into one another. Feature Implementations retain their own evidence status even when they are referenced by a positive Evaluation.

Testimony preservation is a field-level invariant

The adopted Testimony Preservation and Evidence Additivity principle controls field language. Contributor testimony is evidence as testimony. The absence of a screenshot, recording, document, organization response, or other corroborating artifact must never be used as a routine reason to weaken the contributor's account. “The contributor reports X” is sufficient provenance for testimony.

Additional evidence may corroborate, contextualize, challenge, contradict, correct, narrow, or expand a proposition. It is additive. It must not be described as the moment at which the contributor's report first became worthy of belief.

Uncertainty language belongs on the specific proposition actually uncertain, such as causal mechanism, organizational attribution, prevalence, motive, exact precision, durability, interpretation, or genuine evidentiary conflict. Missing corroboration is not contradiction.

Mandatory quality gate: before saving or publishing contributor-derived language, ask whether any sentence makes contributor testimony sound weaker merely because additional evidence could theoretically exist. If yes, rewrite it.

Binary artifact fields and attachment semantics

Evidence Files is the canonical file-attachment field for original and separately governed derivative artifacts on UXR Evidence Items. It is conditionally required when a contributor supplies a file-based artifact and an approved Notion upload path can durably attach it. A transient chat attachment ID, local path, external-platform history entry, screenshot description, or reviewer summary is not equivalent to the original file. Such a pointer may be preserved in Secure Storage Reference for provenance or recovery only.

The Intake AI must treat binary preservation as a verified transaction:

1. create or reuse the correct Evidence Item and record source class, provenance, dates, sensitivity, redaction, authorization, retention, supported claims, unsupported claims, and limitations;

2. upload the original through an approved Notion binary-upload path and attach the resulting Notion file to Evidence Files;

3. read the Evidence Item back and verify the intended filename, file count, accessible Notion file reference, and unchanged evidence metadata; and

4. report completion only after the readback proves the file is present.

If direct Notion binary transfer is unavailable, retain the Evidence Item and all supported metadata, preserve the exact temporary source pointer, and use only an approved fallback. The verified August 18, 2026 transient Shopify-to-Notion relay is approved for evidence whose privacy and authorization state permits its temporary transport risk: stage the original in Shopify Files only; resolve Shopify originalSource rather than a transformed CDN rendition; verify source/original byte length; import the original into the intended Notion Evidence Item; read back the durable Notion-hosted artifact; delete the temporary Shopify asset; and independently verify deletion. The staging asset must not be attached to a product, Article, public HXR projection, or other storefront content. Direct Notion upload remains preferred, and highly sensitive evidence must not automatically use a relay with a temporarily addressable URL. If the binary is durably preserved in the Evidence Item but the structured Evidence Files property cannot bind it, preserve that narrower binding limitation explicitly. The agent must not claim more attachment completeness than readback supports, weaken contributor testimony because of a connector gap, silently convert the artifact into testimony or text description, or improvise email, arbitrary public hosting, or another unapproved repository.

The privately retained original and any crop, annotation, compression, transcription, redaction, or publication-safe derivative are separate artifacts. Never overwrite the original. Public eligibility of the Evidence Item, Incident, Evaluation, or textual excerpt does not authorize release of the file itself; evidence-specific authorization and redaction review control file publication.

UXR corrections and contributor corrections are different

Use Contributor Correction only when the contributor changes or corrects their account. Use UXR Record Correction when UXR corrects its own transcription, extraction, summary, classification, or analysis. UXR must not transfer its own mistake onto the contributor.

Feature discipline

Do not create vendor-specific near-duplicate Benchmark Features when an existing implementation-neutral capability fits. Do not infer implementation quality from feature presence. Link Incident evidence only to features and implementations actually demonstrated or tested by that occurrence.

Agency vocabulary discipline

Use the current Agency Vocabulary working definitions when assigning agency-related labels. Dimensions may overlap. Do not invent a near-synonym because a different phrase sounds better in one case. Dignity, Voice, Contestability, and Practical Access remain related concepts under audit rather than automatically becoming renamed Agency Dimensions.

Case count is not a vote

Repeated incidents may strengthen evidence of recurrence, but raw count is not truth, prevalence, severity, or score. Counterexamples, contradictory incidents, sampling limits, version differences, and scope differences must remain visible.

Shared dependencies must be visible

One Incident may legitimately support several Evaluations at different levels. When it does, disclose that shared dependency where it affects interpretation. One occurrence analyzed through an app Evaluation, an organization Evaluation, and a department Evaluation remains one occurrence.

Outcome versus reform

Incident Outcome State describes the bounded human objective. System reform, positive-practice state, benchmark posture, regression, and Blue Score readiness belong to Evaluations. Workarounds are not reforms merely because they succeeded once.

Owner rule for pathways and events

Outcome / Reform / Monitoring Pathways, Steps, and Events should normally have exactly one canonical analytical owner: Incident Case for individual remedy/outcome/monitoring, or Evaluation for system reform/positive practice/benchmark/regression. Do not set both merely for convenience.

Equal treatment

Different intake agents should produce materially equivalent records from materially equivalent evidence. Agents may ask only questions that could materially change facts, boundaries, privacy, evidence, attribution, Evaluation matching, or reform analysis. Uncertainty must be preserved instead of guessed away, but uncertainty must not be manufactured around contributor testimony merely because further corroboration could exist.

Blue Score discipline

Do not invent Blue Score values, weights, thresholds, rankings, or automatic feature points. Score-relevant observations belong in Evaluations and feature/implementation records until a governed scoring methodology is adopted.

HXR Source and Evidence Graph Field Semantics

The following module boundary is now controlling for new source/evidence work:

• HXR Sources identifies one information-bearing object and its provenance, hosting, authorship/attribution, dates, availability, rights, privacy, publication, and outreach state.

• HXR Source Snapshots preserves the bounded version HXR actually inspected. Snapshot custody does not create publication permission.

• UXR Evidence Items records one atomic evidentiary observation or a deliberately labeled bundle/dossier. It identifies what was observed or reported, where within the Source it appears, contextual variables, limitations, and publication state.

• UXR Proposition Source Resolutions resolves intake-stage proposition provenance. It is not the durable final evidence relationship edge.

• HXR Evidence Contributions records why one Evidence Item matters to one target and carries contribution role, target proposition/finding, scope, limitation, independence, dependency, review, and public display semantics.

• HXR Source Engagements records human-reviewed useful information returned to a Source or community after synthesis, response, workaround, reform, correction, or regression.

Required anti-inference rules

A Source is not automatically credible, public, independent, or relevant merely because it has a URL. An Evidence Item is not automatically corroborating merely because it resembles another report. A Contribution edge is not valid merely because a direct relation exists. A Source Snapshot is not authorization to republish. A public reporter count is not a prevalence measure. A community follow-up link is not proof of endorsement by that community.

Atomicity and dependency

Evidence Items should normally preserve one materially distinct observation. When a record is a source-level bundle, research corpus, or generated dossier, its Atomicity Review must identify that status so it is not counted as one independent observation or silently counted alongside its component Evidence Items.

Reporter, thread/page, platform, incident, test-session, organization-authorship, and shared-source dependencies must remain separately representable. Public counts and synthesis must distinguish these dependencies rather than flattening them.

Public page eligibility

Public Evidence Page Eligibility answers whether one Evidence Item supplies enough approved, distinct public value to receive an indexable page. Public Support Data Only and Noindex / Thin Record remain public-renderer states, not credibility labels. Private-only and redaction states always outrank related-record publication.

Discovery intent and problem-language preservation

Search visibility is a legitimate public-access outcome because people often encounter HXR through a current problem rather than prior interest in the project. Intake research should therefore preserve materially accurate vocabulary used by affected people: exact messages, ordinary descriptions of actions and failures, informal problem labels, and question forms people use when seeking help. Preserve provenance for those phrases and use them, when natural and evidence-bounded, to inform Public / Search Title, Public Subtitle, opening summaries, headings, and body copy.

This does not authorize thin-page generation, keyword stuffing, manufactured synonym lists, hidden structured data, mass community posting, sensational phrasing, scope broadening, or weakening evidence standards. The public page must be useful first; discoverability should follow from accurately exposing useful work in language the people experiencing the problem recognize and search for.