Metric movement evaluation and startup audit

Edition 9 October 2026. Current decision: Prototype diagnostic. Prices and product uses remain hypotheses. No independent source-proof verification or buyer validation has been completed.

Research finding

The source separates existence of a causal squared-log competitive policy from its uniform finite-rational-metric implementation. The latter simulates a finite table constructor for floor(log2(t+1)) steps at request t and activates at t*=2^T_P-1. Before activation it always serves with the first label. Its displayed additive constant is (t*-1)D+(2a+2)kD. The zero-additive distinct-start existence clause does not transfer to this implementation.

Problem and buyer

Systems teams evaluating interchangeable resources or locality policies need to know whether a movement guarantee matters within their deployment horizon. A polynomial request-time statement can coexist with startup behavior that defeats the intended savings.

What the finding could enable

A finite-horizon replay report can validate a rational metric, compare an implemented policy with exact small offline optima, and expose activation and additive-loss assumptions before adoption. This is a deployment-readiness module within the shared evidence platform.

Technical and commercial limits

The source uses fixed oblivious requests, 2<=k<n, labeled servers and one move per request. It does not include deadlines, queues, unequal capacities, adaptive input or economic losses. T_P is not measured here. An extreme displayed schedule is not a lower bound for every possible implementation.

Minimal architecture

Metric/encoding validator -> policy adapters -> bounded exact offline DP and exact named-policy expectations -> constructor/activation worksheet -> movement and measured-latency report. The implemented reference caps eight points, four servers, 64 requests and three million state-label transitions. Exhaustion leaves the final comparison unknown.

Existing alternatives and differentiation

Existing workload replayers and custom caching/resource heuristics are substantial substitutes. Differentiate through exact finite controls and transparent startup obligations when the workload genuinely fits the metric model. The reference implements fixed-label, nearest-label and independent uniform-label policies; none is the source competitive algorithm.

Monetization hypothesis

Hypothesis: AUD 6,000 for a narrow evaluation project. At an assumed 25 specialist hours and AUD 180/hour, AUD 1,500 remains before sales, support and overhead; 35 hours exceed that fee. No quote, customer engagement or profitable delivery is demonstrated. Count this as one assurance module, not an independent subscription market.

Validation experiment

The saved three-point line fixture starts at (0,1) and alternates requests 1 and 2 for 30 requests: first-label cost 30, exact offline cost 2. The two-request prefix optimum is 1, so horizon matters. 137 finite checks compare DP with complete label-string enumeration and test exact expectations, witness replay, invalid metrics and budgets. Next use a public request workload with a defensible metric and evaluate a real policy adapter.

Conditions to reject or defer

Defer the literal source backend until its constructor, activation and practical per-request costs are measured at a useful horizon. Reject the integration if operational constraints break the model or no decision changes relative to current replays.

Next concrete action

Add one existing deployed policy adapter and record the concrete horizon, movement unit and mandatory constraints. Preserve source existence, formal statement and implemented policy correctness as separate evidence stages.

Source evidence

Repository sources are pinned to revision fd4aeeb2ee4fc729c18d98444fed42fd0529eeeb. Selected scope notes and manuscript statements have been reviewed to the extent described above; these links do not represent successful kernel checks.

Family 110

Subject: Optimal-order randomized <i>k</i>-server on arbitrary metrics.

New local evidence

Computational feasibility, semantic comparison, eighteen utilities. All sources remain pinned to the cited revision.