← All work 12 / Open source

URP

I built URP to verify that a cheaper result preserves what matters, and to return the baseline whenever the check fails.

v0.1.0 · Local proof

Role: Author & lead builder
Duration: 2026
Team: Independent project
Status: v0.1.0 · Local proof

A cheaper answer has to pass the same test

A cache hit or smaller file can look like a saving. The harder question is whether it still does the job. I built Universal Reduction Plane to check that before accepting an optimization. Each work unit specifies what must stay the same and which changes are allowed. URP carries those requirements as a preservation contract and policy.

URP plans and runs the optimization, checks the result, then records the decision in a manifest and ledger. A result passes through only if it satisfies the verifier. If it fails, the caller gets the baseline result. Exact preservation is the default. Semantic, lossy and deletion paths require explicit permission.

Show what would happen before enforcing it

I designed observe, shadow and enforce modes so an operator can inspect behavior before applying changes. Tenant isolation and a hash-chained ledger keep decisions attributable. I connected the same workflow to exact AI caching, context compilation, model routing and object, file and data-processing interfaces. Python, TypeScript and Go SDKs sit over Rust core crates.

The Apache-2.0 v0.1.0 release contains deterministic tests that run locally without cloud credentials and a 16-page report. Docker, Helm and Terraform artifacts pass CI checks. Deployment and measured production savings remain open.

Explore the repository and report.

The record

What the evidence says.

Open-source release: v0.1.0; Apache-2.0 repository
Technical report pages: 16; Published project report

Universal Reduction Plane / Workflow

When can URP use a reduced result?

Plan
Read the work unit’s preservation contract and policy to choose an eligible reduction.
Execute
Produce a candidate result, for example with exact caching.
Verify
Check whether the candidate meets the preservation contract.

Two possible verifier outcomes

Choose an outcome to read why the next action changes. This illustrates the logic; it does not run a verifier.

Pass · Accept candidate Return the reduced result after verification succeeds. Fail · Return baseline Use the baseline if verification fails.

Pass · Accept candidateThe verifier found that the candidate meets the preservation contract. Return it and record the accepted reduction in the manifest and ledger.

Fail · Return baselineThe candidate did not pass the preservation check. Return the baseline and record the failed reduction in the same manifest and ledger.

After either outcome, the manifest and ledger record the decision.

Worked explanationFollow an exact-cache candidate

Input: A work unit defines what must be preserved, and policy allows exact caching.
Decision / rule: Treat the cached result as a candidate. Verify it against the preservation contract before accepting it.
Outcome: Pass returns the candidate; failure returns the baseline. Either outcome enters the manifest and ledger.

Scope of this exampleA conceptual example of the local proof. Selecting an outcome in this diagram does not perform a cache lookup or verification.

Exact preservation is the default. Policy must allow semantic, lossy or deletion paths. This is a local proof, not a deployed service or a measured savings claim.

What I’d do next.

Validate the governed reduction workflow in a real deployment before making production savings claims.

Working through a similar decision?

Talk to me about your project

Next project / 13 / Open source RDLLM I built a reference implementation that attaches evidence to AI claims and checks rights before producing allocation instructions.