Incident Cases, Evaluations, and the UXR Evidence Graph

Architecture status: Active UXR architecture, published for review.

Purpose

UXR separates bounded real-world occurrences from durable analytical evaluation so one person's experience can remain intact while many evidence sources accumulate around the same system, organization, department, mechanism, feature, implementation, or practice.

Incident Cases

An Incident Case records what happened in one bounded occurrence: contributor objective, chronology, evidence, direct burden or benefit, involved systems and organizations, individual outcome, and later incident-level monitoring. The Incident remains an independent record even when it contributes evidence to broader analysis.

Evaluations

An Evaluation is a durable analytical record about an evaluable subject. Evaluations may examine products or applications, organizations, departments or units, mechanisms, cross-system practices, interfaces, infrastructure, benchmark features, feature implementations, reform, positive practice, regression, or comparative performance.

Mechanism and System / Practice are Evaluation types, not new Incident Case levels. Historical analytical cases created before this split remain migration artifacts; live synthesis continues in Evaluations.

Durable Subjects, Features, and Implementations

Organizations, UXR Systems, Benchmark Features, and Feature Implementations are durable subjects connected to cases and Evaluations. A reusable capability is a Benchmark Feature. One concrete implementation of that capability in a bounded system and context is a Feature Implementation.

Evidence flows upward without becoming a vote

An Incident may support, narrow, challenge, or contradict one or more Evaluations. Case count is not truth, prevalence, severity, or score. Evaluations must preserve counterexamples, scope differences, version differences, and competing evidence.

Evaluation-origin contribution before Incident creation

A person may begin from a public Evaluation by choosing Add Your Experience, but the public Evaluation does not receive raw evidence directly and the action does not create a canonical contribution edge.

The governed Phase 1 path is:

Public Evaluation → private Intake Session → candidate Evaluation match → proposition, provenance, privacy, and occurrence-boundary review → optional Incident Case → optional Incident-to-Evaluation Contribution edge.

A short account may remain an Intake Session or candidate lead when there is not yet enough information to bound an occurrence responsibly. It is not automatically an Incident Case, finding, corroboration, vote, prevalence estimate, severity measure, or score input. Positive outcomes, materially different experiences, corrections, workarounds, and counterexamples enter through the same doorway and must not be filtered out for failing to match an expected negative pattern.

One bounded Incident may later contribute to several Evaluations, with a separate evidence-specific edge for each supported analytical role. The contributor should not be required to submit the same occurrence repeatedly for each Evaluation.

Synthesis ceiling

An Evaluation may combine contributor testimony, artifacts, organization-authored evidence, independent accounts, comparison evidence, replication, public records, and other sources. It may reach a broader conclusion only to the degree the combined evidence supports that conclusion. It must not silently give a proposition more certainty, scope, causal force, or attribution than its evidence supports.

Limited coverage constrains generalization. It does not weaken the validity or dignity of a bounded contributor report. Testimony remains testimony whether or not additional corroboration is available.

Shared Incident dependencies

One Incident may contribute evidence to several Evaluations at different analytical levels. When that shared dependency matters to interpretation, UXR must disclose it. One occurrence viewed through an app Evaluation, organization Evaluation, department Evaluation, regulator Evaluation, and cross-system Evaluation is still one occurrence, not five independent incidents.

A multi-organization incident should normally remain one bounded Incident while supporting separate Evaluations for the functions actually being tested. This allows HXR to ask different questions of a health plan, delegated medical group, referring office, specialist, regulator, marketplace, or end-to-end process without pretending every participant had the same authority or failed in the same way.

Institution-Controlled Functions and User Agency

Evaluation wording must not silently convert an institution-controlled function into a user entitlement to exercise that function personally. When a system legitimately reserves provider assignment, authorization, adjudication, dispatch, settlement, or another consequential lever to an institution, the Evaluation should ask whether the user can effectively invoke the applicable right or remediation pathway and whether the responsible institution then performs its controlled function.

For example, lack of unrestricted specialist choice is not automatically an agency failure in a managed-care plan. A supportable failure may instead be that the normal referral pathway could not meet the applicable access requirement and no effective escalation caused the responsible entities to arrange a lawful alternative. This distinction prevents HXR from confusing product-model differences with failure to perform obligations within the chosen model.

Responsibility and credit stay evidence-specific

Evidence can progressively identify responsibility without requiring the contributor to diagnose the backend system. If several institutions independently identify the same upstream actor, UXR can record that convergence. If an organization does not control the root cause but provides a verified mitigation, that mitigation can receive credit without falsely assigning root-cause responsibility.

Reform can propagate evidence without propagating finality

A verified reform, positive practice, regression, or superior implementation may change the evidence carried into an Evaluation without erasing the Incident that exposed or demonstrated it. Individual remedy belongs to the Incident. System reform, benchmarking, positive-practice preservation, regression, and comparative synthesis belong to the relevant Evaluation.

Testimony preservation

The adopted Testimony Preservation and Evidence Additivity principle governs every edge in the graph. Contributor testimony is not weakened because more evidence could exist. Additional evidence is additive. Genuine uncertainty belongs on separate propositions such as causation, attribution, prevalence, motive, precision, durability, or actual evidentiary conflict.

Public presentation

Public cards and detail pages should identify whether a record is an Incident Case or Evaluation, distinguish evaluated systems from organizations, show evidence-graph relationships and shared dependencies where material, and expose revision behavior without turning workflow metadata or evidence counts into credibility scores.

Cross-industry architecture

The same model applies across finance, healthcare, software, government, transportation, education, commerce, and other human-made systems. The architecture is domain-neutral; evidence, constraints, expertise, and acceptance tests remain domain-specific.

Intake-agent rule

Before writing any graph record, Intake AI must follow the current UXR Field Semantics and Intake Agent Alignment Standard: read adopted Processing Invariants, resolve the current canonical module through the UXR System Registry, inspect the live Notion schema/property descriptions, apply the module's Active Field Contracts, and verify writes by readback.

Intake agents must preserve the bounded occurrence first, then determine which durable subjects and Evaluations it contributes to. They must not make the first named organization the case boundary by default, invent hierarchy to fit one case, multiply one incident into several occurrences, or use missing corroboration as a reason to weaken contributor testimony. Candidate Case/Evaluation relations are workbench hypotheses; canonical Incident→Evaluation Contributions, Evaluation Subject Links, Entity Relationships, Evidence Items, and Institutional Handoffs carry the supported final graph semantics.

Canonical Source, Observation, and Contribution Layers

HXR now separates four questions that were previously easy to collapse into one Evidence Item or a block of prose:

1. Source: What information-bearing object exists, and where did it come from?
2. Source Snapshot: What version did HXR actually inspect or preserve at a particular time?
3. Evidence Item: What specific observation, report, artifact, statement, result, or outcome does that source support?
4. Evidence Contribution: Why does that Evidence Item matter to one particular Incident, Evaluation, proposition, entity, feature, implementation, or reform?

A Source may be internal or external. Contributor testimony, HXR tests, screenshots, emails, organization-authored documentation, community threads, public records, datasets, and academic or technical material all use the same provenance model. “External” is not a credibility class.

One Source may yield several atomic Evidence Items. One Evidence Item may contribute differently to several analytical targets. Each durable relationship uses a separate Evidence Contribution edge so HXR can preserve contribution role, target proposition, relationship explanation, scope, limitation, independence, shared dependency, publication eligibility, and public display context without copying the Source or Evidence Item into every Case or Evaluation.

Direct Source-to-Case or Source-to-Evaluation relations may be used as derived navigation or rollups, but they are not the authoritative relationship meaning. The supported Evidence Contribution edge is authoritative.

Proposition Source Resolution Boundary

UXR Proposition Source Resolutions remains the intake-stage mechanism for resolving where candidate propositions originated and how raw intake material maps into attributable propositions. It does not replace durable Sources, Evidence Items, or Evidence Contributions. The processing boundary is:

Intake material → Proposition Source Resolution → resolved Proposition → Evidence Item → supported Evidence Contribution edge.

The exact order may overlap in practical processing, but the semantics must not. Proposition Source Resolution explains proposition provenance during intake. Evidence Contribution explains final evidentiary relevance in the durable graph.

Source Snapshots and Change History

A live URL is not durable provenance by itself. Public posts and organization pages may be edited, removed, locked, redirected, or made inaccessible. HXR Source Snapshots preserve what HXR inspected at a bounded time through metadata, hashes, screenshots, downloaded files, archive references, or another governed capture method.

Snapshot preservation does not automatically authorize republication. Copyright, platform rules, privacy, contributor authorization, and evidence-specific public-use controls continue to govern the captured material. Public HXR pages should normally link to the original, summarize or paraphrase what matters, and expose only approved excerpts or artifacts.

Source Engagement and Community Return

A Source may later receive useful information back from HXR after a material synthesis, organization response, verified workaround, reform, correction, or regression. Each interaction is recorded as a Source Engagement with its purpose, community benefit, platform rules, affiliation disclosure, human approval, message, permalink, moderation state, response, and any resulting new evidence.

Source Engagement is not a backlink-posting queue. Community return must answer the originating community’s actual need, disclose HXR’s role, respect platform rules, avoid duplicate or mass posting, and remain human-reviewed. Referral and discovery benefits are legitimate consequences of useful return, not the governing reason for the engagement.

Public Discovery as Human Access

Notion is the canonical private system, but affected people, organizations, researchers, and contributors can only discover HXR through the public Shopify projection and other public references. Public discoverability is therefore an access and intake concern, not a separate marketing objective.

HXR should meet people where they are by making publication-safe evidence relationships visible in useful, crawlable public pages. Evaluation and Incident pages should render the evidence synthesis, relationship explanations, limitations, organization responses, reforms, and descriptive links needed for a person or search engine to understand the subject without access to Notion.

HXR must not generate thin pages merely because a canonical row exists. Sources, Evidence Items, Incidents, Evaluations, datasets, and reforms become indexable only when they provide distinct public value. Snapshots, join edges, engagement events, renderer bundles, and other support records are normally non-indexable and are rendered contextually inside substantive pages.

Symmetric Accountability

The same source and contribution architecture must preserve evidence that supports concern, narrows or challenges a claim, contradicts a claim, documents positive performance, identifies better practice, reattributes responsibility or credit, documents remedy or reform, verifies reform, or identifies regression. The graph is designed to make supported performance visible, whether the resulting Evaluation is unfavorable, favorable, or mixed.