UXR Release Broker, Provenance Invariants, and Closed-Pilot Release Protocol

Status: Adopted stricter release-control architecture preserved for a later development stage. Current ordinary case publication follows UXR Architectural Build Publication Mode.

The need

UXR asks contributors to trust that their accounts will retain the dignity, provenance, and evidentiary strength with which they were supplied. Documentation alone is not sufficient evidence that this promise is operational. UXR adopted explicit testimony-preservation language and then reproduced the prohibited behavior during live case maintenance. That acceptance-test failure requires enforcement outside free-form model compliance.

The core architecture

An intake agent may organize, clarify, extract propositions, assemble evidence relationships, and prepare a publication candidate. The Release Broker preserves UXR's stricter future-stage release architecture. During the current Architectural Build Publication Mode, however, Sean's explicit instruction to publish, make public, promote to public, or take a specific case or Evaluation live authorizes the complete ordinary public-projection transaction under the UXR Architectural Build Publication Protocol. The Release Broker is not the default gate for those current publication instructions.

The broker evaluates structured propositions before release. Each material proposition separates the statement from its provenance, proposition class, evidence relationships, current status, scope limits, and proposed public wording. Provenance is not a credibility score.

Deterministic and semantic controls are different

UXR does not describe a natural-language rule as a hard control merely because it uses the word SHALL. Each adopted processing invariant contains two explicit classes of clauses.

Deterministic broker clauses are limited to rules executable from structured fields, stored source classes, enumerated states, references, timestamps, Shopify system metadata, or explicit prohibited constructions. A deterministic failure blocks persistence or publication according to the invariant.

Semantic review clauses require contextual judgment, such as whether wording rhetorically discounts testimony or silently overstates an inference. These are handled by a fresh-context Semantic Adversarial Review and, during the closed pilot, by the human reviewer. They are not represented as deterministic guarantees.

Adopted provenance invariants

Testimony Preservation. Contributor testimony remains contributor testimony without credibility discount merely because corroborating evidence is absent. Genuine contradiction, material internal inconsistency, or contributor correction can change UXR's conclusion, but they do not retroactively alter the provenance of the original testimony.

Organization-Authored Evidence. An organization's own record establishes what the organization recorded, asserted, communicated, classified, or represented. It is not downgraded into contributor testimony merely because a contributor supplied the artifact. It also does not automatically become independent proof that the underlying physical or external event occurred.

UXR Inference Scope. UXR analysis remains UXR analysis. Causation, responsibility or credit, prevalence, motive, intent, legal conclusions, system-wide behavior, and durability require evidence supporting those specific propositions.

Provenance Immutability. Later evidence may support, challenge, contradict, narrow, correct, or supersede propositions through explicit relationships. It does not transform the original source class. Contributor testimony remains testimony after corroboration. Organization-authored evidence remains organization-authored after independent confirmation.

Stricter release sequence

The following sequence preserves the release-control architecture UXR may activate as a default boundary in a later development stage. It does not govern ordinary case publication during current Architectural Build Publication Mode when Sean explicitly instructs publication. Current publication instead follows the UXR Architectural Build Publication Protocol, including permitted use, privacy/redaction, provenance, canonical linkage, ordinary public-system behavior, and write/readback verification.

1. Extract material propositions.

2. Assign provenance and proposition class.

3. Assign evidence relationships, status, and scope limits.

4. Run deterministic broker checks.

5. Run privacy and redaction checks.

6. Run fresh-context Semantic Adversarial Review.

7. Apply required regression-suite status.

8. Move the candidate to Ready for Human Review.

9. During the closed pilot, require a valid human-created approval before release.

A prepared public projection, article, index record, or release-gate record is not itself publication authority.

The pilot human boundary

The Human Release Approval design remains preserved as part of the stricter release-control system UXR may activate in a later stage. It is not a prerequisite for ordinary publication during current Architectural Build Publication Mode after Sean has explicitly instructed that a case or Evaluation be published. A valid future-stage approval is not merely a text field that says Approved. Under the current Shopify integration, the broker can deterministically reject any approval whose Shopify createdByApp system field is non-null. A valid pilot approval must therefore be created outside the app, after the gate enters Ready for Human Review, and must not be subsequently edited. Where Shopify exposes createdByStaff, the broker should verify that too; this store/API combination does not expose that field to the current integration.

Regression testing

The production regression corpus begins with twelve release-blocking fixtures split across both directions of error. Evidence-preservation fixtures test improper discounting of testimony. Evidence-overreach fixtures test improper promotion of testimony, organization assertions, prevalence, responsibility, motive, legal conclusions, and reviewer hypotheticals. Actual UXR failures become permanent regression fixtures.

The first recorded 12-fixture manual baseline produced 8 passes and 4 failures under the limitations documented in Current Project Status. The required clean-room rerun remains Not Run. UXR will not convert an unexecuted rerun into a passing claim or an invented score. Pass, Fail, and Not Tested remain distinct states.

During Architectural Build Publication Mode, regression status remains evidence about the maturity of UXR's stricter release-control system. It does not, by itself, block an otherwise safe publication that Sean explicitly authorizes. This phase rule exists so the real frontend can be used to discover projection, anonymization, schema, relationship, counting, filtering, indexing, and rendering defects before UXR treats release gating as the primary development objective.

Public self-case scope

When UXR files a case against its own operation, the public evidence scope must be set before publication. A public self-case may use a narrowly redacted UXR-authored failure excerpt or UXR's own characterization of the failure. It must not expose unrelated contributor details, addresses, third-party finances, or case facts merely because they appeared in the surrounding conversation.

Current readiness

Open public case solicitation is not active. UXR is operating in Architectural Build Publication Mode within the closed/private-alpha development period using existing case maintenance, internal benchmark cases, and invited or known pilot contributors. When Sean explicitly instructs publication and the substantive privacy, permitted-use, provenance, and canonical-scope requirements pass, cases and Evaluations may be published through the ordinary public path so maintainers can inspect the real public data system. Outside criticism, methodological review, domain expertise, and public scrutiny remain welcome.

A clean-room regression pass is a minimum milestone for expanding the pilot, not evidence that the entire intake system is permanently safe. UXR will keep actual failures as regression evidence and will not treat a policy edit as verified reform.

Known technical limit

The broker makes the approved UXR release path fail closed, but the current Shopify integration still shares write-capable tooling across work performed in this environment. A tool-capable agent could theoretically attempt a direct write outside the broker path. UXR therefore does not claim cryptographic or sandbox-level impossibility at this stage.

The approval record itself can be protected from app impersonation because app-created metaobjects carry a non-null createdByApp system stamp that the broker can reject. Direct public-write capability remains a separate technical risk. During the current architectural-build phase, that stricter human-approval boundary is intentionally not the default gate for ordinary publication after Sean explicitly says publish. A future production hardening step may separate credentials and tool permissions so intake agents can propose candidates but do not possess public-release capability at all, but activating that stricter boundary requires an explicit development-stage change.

Acceptance principle

A reform is not verified because the policy changed. It is verified when the changed system stops producing the failure under the acceptance tests designed to catch it.