Affine assisted evaluation

What this pilot supports

This assisted pilot reuses the original frozen MiMo evaluator for four diagnostic cases. It accepts public, ungated, full MiMo-compatible 9B safetensors checkpoints up to 20 GiB. A checkpoint reference is resolved to an immutable revision before preparation. Other architectures, adapters and private or gated repositories are outside this policy. Miner batch submission, GRPO candidate training and promotion-gate replay are separate operations and are unavailable through this diagnostic interface.

A completed run and a valid signature establish the recorded execution and artifact integrity. They do not establish official Affine authorization, acceptance of a benchmark, model improvement, mining rewards or parity across machines. Read the returned assurance fields without upgrading them.

Connect the owner and agent

The owner claims the private invitation with their own verified wallet in the browser and requests a window when ready. Keep wallet signing, invitation tokens and account setup outside agent tool arguments. No API key can claim a reservation or open its window.

Use the exact API origin supplied for the pilot with matching account keys. A production key or package version does not establish access to an isolated workspace. The SDK exports createAffinePilotClient and createAffinePilotTransport from @reliquary/api/affine-pilot. MCP exposes the same preparation flow through the existing training credential corridor and keeps writes disabled by default.

Read availability using the supplied origin

import { createAffinePilotClient, createAffinePilotTransport } from '@reliquary/api/affine-pilot';
const { request } = createAffinePilotTransport({
  origin: process.env.RELIQUARY_API_URL,
  apiKey: process.env.TRAINING_API_KEY,
  resourcesApiKey: process.env.RESOURCES_API_KEY,
});
const pilot = createAffinePilotClient(request);
const availability = await pilot.status();
console.log(availability);
// Stop if unavailable; requesting an operator window is a separate owner action.

Review, then approve checkpoint preparation

Read reliquary_affine_pilot_status first. Its available, reason, sessionId and windowEndsAt describe current preparation availability and owned history. An unavailable result is a stop condition; it is not permission to rent a GPU or change the service.

Use reliquary_affine_checkpoint_review with repository, reference, sessionId and maxCostMicroUsd. Present the exact repository, resolved 40-character revision, policy digest and ceiling before asking for preparation approval. The ceiling is in millionths of USD and cannot exceed 5,100,000 ($5.10). An open window must have at least 70 minutes remaining and a fresh coordinator heartbeat.

Only after that approval, call reliquary_affine_checkpoint_prepare with the reviewed repository, immutable revision, sessionId, maxCostMicroUsd, policyDigest, approvePreparation:true and a stable UUID requestId. Preparation may consume GPU time. After an ambiguous response retain the same UUID and exact inputs; never create another request to work around uncertainty.

Read reliquary_affine_preparation_get when progress is needed. Preserve queued, preparing, qualifying, ready and failed as distinct states. Ready provides an owned profileDigest; it does not mean the final evaluation has run. One preparation permits one final allocation.

Prepare and explicitly launch one final evaluation

• Call reliquary_affine_evaluation_prepare with the ready profileDigest, bounded maxHours and maxCostMicroUsd. Keep the returned request and configuration unchanged; the response also names its billing mode.
• With confirmed data rights, use reliquary_affine_request_upload to upload exactly the returned request. It writes JSON.stringify(request) followed by one newline with dataset format affine_native_evaluation_request. Do not upload model output or substitute a generic instruction dataset.
• Use reliquary_resource_create with kind training and the returned configuration plus dataset:{id:uploadedFile.id}, a name and a stable idempotency key. Do not use training_draft_create: this native configuration has its own method and immutable request pins. Keep the saved draft ID and revision.
• For service-credit mode obtain reliquary_training_quote for the exact draftId, revision and datasetId. Present its rate, ceiling and expiry. An explicitly available operator-funded pilot omits the quote; it still requires launch approval.
• After approval for those exact inputs, use reliquary_training_start with approveExecution:true and the original stable idempotency key. Include the exact quoteId when required. A timeout means reconcile the same action, not start a second evaluation.

Read the run and verify delivery

Read reliquary_training_task_get for the owned task, pinned configuration, actual state, result and artifact metadata. Retrieve the receipt and evaluation archive using the returned artifact IDs through reliquary_training_artifact_download. Downloads use bounded byte ranges; follow the returned range metadata explicitly.

Before trusting a receipt, verify its Ed25519 signature using the public key from the approved execution profile, and bind its task/profile/request/source/runtime/checkpoint/job identifiers to the reviewed run. Verify archive SHA-256 and size against the signed receipt. A key shipped only inside an untrusted receipt is not a trust anchor.

Keep receipt validity, diagnostic agreement, official Affine acceptance, financial settlement and mining rewards separate. The pilot preserves nativeParityVerified:false, operatorAccepted:false, nativeRewardVerified:false and chainTransactions:false. No successful download changes those claims.

Keep the window closed until the owner is ready. Do not schedule polling, provision capacity, submit chain transactions or restart any executor as part of this workflow.

Affine pilot OpenAPI — Exact scoped routes and request formats.

Training API — Saved revisions, quotes, task approval and artifact reads.

Saved resources API — Separate resource credentials and immutable draft revisions.

What you get

One explicitly approved bounded diagnostic or the precise unavailable, expired, failed or unknown-outcome boundary with original request identity.

Requires a human-claimed workspace, open pilot window, connected coordinator, exact preparation approval and separate execution approval. No live GPU is enabled by default.

Ask your assistant

Example task

Prepare my compatible checkpoint for the assisted Affine pilot and show each approval boundary.

Install this skill

Use an existing compatible MCP connection or the customer CLI. Skills provide instructions; installing them does not configure credentials, grant permissions or enable execution.

Install reliquary-affine-pilot

reliqua skills install --skill reliquary-affine-pilot --directory "$HOME/.agents/skills"

Download SKILL.md — Official task instructions, version 0.9.0.

Install the customer CLI — Verified release downloads, commands and troubleshooting.

Connect MCP — Keep writes disabled for discovery and planning.

Authentication and exact scopes — Corridor names identify key configuration; the API checks its actual read and write scopes.

Follow the workflow

• Call connection then affine_pilot_status. The catalog combines availability and owned history. Preserve its offline reason; unavailable status, a closed window or fewer than 70 minutes remaining requires stopping. Wallet invitation claim and request-window actions remain human browser actions; never automate wallet authentication or invent a session route.
• Accept only a public full MiMo-compatible 9B safetensors checkpoint at most 20 GiB. General Hugging Face architectures, private checkpoints and LoRA adapters are unsupported. Call affine_checkpoint_review with repository, reference, returned sessionId and maxCostMicroUsd at most 5100000. Present resolved immutable revision, policy mimo-diagnostic4-v1, policyDigest, four diagnostic cases, the 900-second native-stage limit, cost and review expiry. Preparation includes materialization and qualification and requires at least 70 minutes remaining in the pilot window.
• After explicit approval of the exact unexpired review, call affine_checkpoint_prepare with repository, resolved revision, sessionId, maxCostMicroUsd, policyDigest, approvePreparation:true and one stable caller-supplied UUID requestId. Persist these exact inputs and key before sending. Preparation can consume its approved budget; it does not authorize the final evaluation. Read affine_preparation_get by returned ID; stop on failed or expired status, and use only the profileDigest of ready preparation.
• Call affine_evaluation_prepare with that profileDigest, maxHours and maxCostMicroUsd. Retain the exact returned request, configuration, billing mode and nativeJobExpiresAt. Expiry is an absolute bound, not a new allocation window. Preparing these inputs does not launch execution.
• Confirm rights and authorization for the exact upload, then call affine_request_upload with request, a simple .jsonl filename and rightsConfirmed:true. HTTP sends JSON.stringify(request) plus a newline, Content-Type application/x-ndjson, X-Dataset-Format affine_native_evaluation_request, X-Filename and X-Data-Authorized:true. Save returned configuration unchanged with resource_create kind training, name, config and a stable idempotencyKey. Training and resources keys have separate scopes: training:write cannot save a resource; resource_create needs resources:write.
• Retain returned dataset ID, draft ID and revision. In service-credits mode call training_quote for those exact inputs and present the fresh quote and expiry; operator-funded-pilot mode omits quoteId only when explicitly supported. Obtain separate explicit approval for this exact execution, runtime and budget before training_start with approveExecution:true and its own stable idempotencyKey. Keep preparation, draft and launch keys separate.
• Read training_task_get and select artifacts only from that owned task metadata. Download bounded ranges, verify byte size and SHA-256, then verify the signed receipt against independently retained profile pins and receipt public key. Report submitted, running, succeeded and verified delivery separately. A signature establishes receipt integrity against its pinned key, not official authorization.
• This is a same-host internal diagnostic with source-pinned behavior, not verified current official Affine parity, operator acceptance, reward verification, chain activity or a promotion gate. Do not claim any of those outcomes from a successful task. Preserve exact keys and safe diagnostics on outcome_unknown; reconcile owned history/task state without automatic write retries, replacement keys or unattended polling.

Tools and API routes

Call reliquary_connection first and use only tools registered in that connection. Route templates need the owned resource identifiers described by the existing API reference.

Availability and authorization

This workflow can prepare an action using existing contracts. Execution requires current server capabilities, qualified capacity, appropriate account scope, a fresh quote when applicable, and explicit approval of the concrete action. Only the documented staged Affine batch CLI supports an explicit launch. MCP writes stay disabled by default.

Back to the skills catalog — Find another workflow or connect an interface.