Arena service types

An arena service is the validator-owned admission, screening, and qualification-planning boundary for an admitted proposal. The downstream qualification and durable controller produce and settle authoritative evidence. Public CLI arguments cannot construct the service.

Where the boundary sits

The arena service decides whether and how a finalized candidate reaches the qualification runner. It does not decide the economic result. This split lets deployment code own GPUs, model paths, entropy, hidden judges, and executors without letting an arbitrary provider return “crown = true.”

Closed registry

Production deployment injects an ArenaServiceRegistry into the validator loop. The registry maps preconfigured arena IDs to typed services. A service binds an exact runtime and workload identity, capacity and screen policy, qualification-policy digest, and reviewed provider identity. The provider returns the closed executor, entropy, hidden-judge, deadline, and plan-factory work needed by the qualification runner.

chain-validate --arena-id <id> selects an already injected service. Unknown IDs fail closed. Without an injected registry, only --intake-only is a valid public operation. Cacheon deliberately ships no general production ArenaServiceProvider and no --eval-cmd shell escape hatch.

Manifest anatomy

An ArenaServiceManifest is path-free and content-addressed. Its main sections are:

Every workload cell is typed, positive, and unique, and the sealed prompt batches must match each cell's declared concurrency before anything commissions. Tensor parallel size cannot exceed the bound GPU count. These checks turn “same arena” into a typed identity rather than an operator nickname.

Intake parks a proposal for a closed target before any evaluation, with reason target_unavailable:<target> and decision NO_DECISION — never a FAIL that byte-identical replay would echo after the family reopens — and releases the cited eval-cost payment pointer or admission credit in the same transaction. A closed family costs the miner nothing.

Boundary types

The provider protocol has only two authority-bearing operations:

def run_screen(manifest, stage, candidate) -> ScreenStageResult: ...

def build_qualification(request, state=None) -> ArenaQualificationWork: ...

ArenaService checks the provider digest on construction, requires the exact requested screen stage back, converts an over-time result to NO_DECISION, and verifies that qualification work preserves policy digest and finalized reservation order. Submission metadata never supplies a Python module or entry point for this provider.

Operators should construct these exact types in reviewed deployment code, not deserialize arbitrary contributor configuration into service objects. Final PASS/FAIL/NO_DECISION authority is represented by qualification evidence types, not by a generic arena outcome object.

What the service owns

• exact runtime, base-engine, model, worker, architecture, and topology identity;
• the scored workload cells and prompt corpus;
• queue depth/age, cohort size, active screen/qualification, and retry bounds;
• the fixed static/build/ABI/graph/abbreviated-serving screens;
• qualification-policy and provider digests; and
• a closed qualification plan and its executor/entropy/hidden-judge authorities.

Submissions cannot weaken or select these values.

Durable intake state, evidence reopening, independent reproduction, transactional settlement, evaluation-stack transition, and weight publication remain separate controller responsibilities. An ArenaService cannot crown or settle a proposal by returning a screen or plan.

Admission and capacity

Admission has three typed outcomes before evidence exists:

Screen and qualification capacities are distinct. A cohort larger than max_cohort_size is held; a cohort that fits policy but would exceed current active qualification capacity is queued. A resident screen promotion is also capped by both the registered policy and the provider's current service capacity. This avoids converting overload into candidate failure.

Retry exhaustion is post-evidence policy, not an admission input. After a screen or qualification produces NO_DECISION, retry_disposition() returns the separate PromotionDecision.RETRY while the lane-specific attempt is below budget, otherwise PromotionDecision.HOLD.

Screen receipt derivation

The screen receipt must be a canonical prefix of the fixed stage order. Every earlier result must be PASS, and the last grade determines the only legal decision:

A provider cannot skip static and report a graph result, reorder stages, attach another candidate digest, or promote an incomplete prefix.

The fifth, abbreviated-serving stage may use the persistent resident screen lane. That lane swaps a safely swappable bundle, recaptures graphs, and grades it against shared stock brackets and canaries. A direct AOT artifact, dependency patch, native rebuild, or setup hook receives a typed waiver for this stage and advances to dedicated qualification; the waiver is not represented as fabricated performance evidence. Screen receipts and waivers remain routing products only.

Outcome semantics

PASS : The run established every registered qualification predicate. A first PASS becomes reproduction_pending; it is not a crown.

FAIL : Authoritative evidence established a candidate defect or failure to clear the registered bar.

NO_DECISION : Infrastructure, drift, incomplete evidence, or another non-candidate condition prevented a valid decision. It must not be rewritten into a loss or a crown.

The controller reopens and regrades retained evidence rather than trusting an evaluator's summary text.

Deployment review checklist

• Construct the registry from a sorted, unique, reviewed arena list.
• Independently attest the reviewed installed provider bytes/configuration to the provider_digest embedded in each service manifest. ArenaService compares that digest with the provider object's self-declared value; the type boundary is not byte attestation.
• Keep model paths, executor handles, entropy sources, and hidden judges inside deployment code; expose only their typed identities at the boundary.
• Ensure queue snapshots and leases come from the durable single-writer controller rather than process-local counters.
• Bind resident-screen lifetime, swap generation, canary, waiver, and capacity policy explicitly; never feed screen measurements into qualification or settlement.
• Make run_screen() produce content-addressed evidence for every returned stage result.
• Make build_qualification() return the exact finalized reservation order, policy digest, deadline, executor, entropy provider, and hidden judge.
• Test timeout, malformed provider output, retry exhaustion, restart, and unknown-arena cases as fail-closed paths.
• Operate intake-only when no reviewed provider/registry is available; never replace the missing provider with a shell command assembled from a proposal.

Source: cacheon/arena_service.py.