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.

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.

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.

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.