Incident Cases, Evaluations, and the HXR Evidence Graph

Architecture status: Active HXR architecture, published for review.

Purpose

HXR 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, HXR 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, HXR 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, HXR 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-to-Evaluation Contributions, Evaluation Subject Links, Entity Relationships, Evidence Items, and Institutional Handoffs carry the supported final graph semantics.