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.

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, and department Evaluation is still one occurrence, not three independent incidents.

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.