Benchmark Features and System Implementations

Development status: Working Concept, published for review.

UXR needs to compare more than organizations and cases. It also needs to compare reusable capabilities and the quality of the way different systems implement them.

Project Features and Benchmark Features Are Different

UXR Feature is the project-development registry for UXR's own methodology, governance, infrastructure, documentation, and software work. It answers what UXR itself is building.

UXR Benchmark Feature is a reusable capability that can be evaluated across outside systems, such as persistent request tracking, proactive status notification, evidence attachment, direct responsible routing, safe correction, or another agency-relevant function. Intake agents must not substitute one type for the other merely because both use the word feature.

Feature, System, Organization, and Implementation Are Different Objects

An evaluated system is the bounded application, service, process, interface, program, policy, workflow, physical system, or infrastructure being examined. An organization is an actor that may provide, operate, configure, maintain, regulate, or respond through that system.

A feature implementation records how one evaluated system provides one reusable benchmark feature, what users can actually observe or do, the evidence that supports the implementation, its conditions and limitations, and which organizations can reasonably receive credit or responsibility.

Implementations Carry Provenance and Reform History

Because Feature Implementation records are public-readable comparison objects, they do not directly reference private canonical cases or private Case-System Links. They preserve non-sensitive source Case IDs and approved public case projections. Private Case-System Links carry the canonical case-to-system-to-implementation relationship inside UXR.

Canonical Outcome / Reform Events can reference affected benchmark features and concrete feature implementations. Publication-safe event projections can then attach to the public implementation record. This preserves reform provenance without exposing private case or evidence relationships through a public comparison object.

Why Implementation Method Matters

Two systems may both claim the same feature while imposing very different burdens. A tracking feature that says only processing is not equivalent to one that exposes meaningful state, responsible function, timestamped history, expected next action, and corrective options. Feature presence alone is not proof of quality.

Comparison Works in Both Directions

A reader should eventually be able to open a benchmark feature and see which systems implement it and how, or open an evaluated system and see its capability portfolio, evidence, reform history, and comparative position. Organization views can then connect to the systems they operate or provide.

Benchmarks Can Move

An implementation may become the best demonstrated example today and later be surpassed. UXR preserves both facts: what was demonstrated at the time and what later became possible. Earlier verified improvement does not become false when the frontier advances.

No Automatic Score Points

A benchmark feature may preserve agency in one implementation and create new burden in another. Some domains may not need it. Future scoring must examine implementation quality, scope, evidence, user-visible effect, legitimate constraints, and comparative performance rather than award points for feature presence.

Case-Library Comparison Surface

A public case card may expose publication-approved Evaluated System, Benchmark Feature, and Feature Implementation relationships when they materially help the reader understand where the interaction occurred and what reusable capability was evidenced. These remain distinct from agency dimensions, which describe what happened to human agency.

A comparative summary must preserve system and deployment scope. Evidence that one city configures a shared platform in a particular way does not establish that every deployment behaves the same way, and a positive implementation does not transfer platform-wide credit beyond the supported layers.

Question for Review

Which reusable capabilities are meaningful enough to benchmark across systems, and what evidence should be required before UXR calls one implementation stronger than another?