HXR Field Semantics and Intake Agent Alignment Standard

Purpose

UXR fields are not generic storage slots. Their live descriptions are operational contracts for intake agents. Before writing a UXR record, an intake agent must read the live Metaobject definition and follow each field description rather than relying on an older document, prior thread memory, or a similarly named legacy field.

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.