Runtime truth
- Model and expert release identity
- Lifecycle and memory planning
- Scheduling, batching, cache isolation, and cancellation
- Resource use, recovery, and inference receipts
Mainely Code’s first-party inference direction
Mainely CodeProvider.
Inference. Runtime. Proof. Provider is being built to own exact model execution, lifecycle, scheduling, resource truth, recovery, and verifiable inference receipts—without absorbing cognition, policy, entitlement, trusted placement, or product acceptance.
Active developmentExact release identityNo silent substitution
InferenceExact model or expert release
RuntimeLoad, warm, stream, cancel, drain, unload
RecoveryDurable requests and explicit unknown outcomes
ProofIdentity, usage, hardware, timing, and receipt
One concern. One authority.
Provider owns execution.
Provider’s job is to execute the exact approved inference plan on eligible compute and report what actually happened.
“Direction from Northstar. Permission through Providence. Execution through Provider. Acceptance by the consuming product.”
Other authorities
- Goals and cognitive judgment
- Permission, fallback authorization, or tool policy
- Product entitlement or node trust
- Buildroom, Orb-Weaver, Growthroom, or Sasquatch acceptance
Execution contract
Exact release. Governed plan. Verifiable receipt.
The endpoint name is not enough. Provider binds execution to exact identity and lifecycle evidence.
01
Release capsule
Weights or expert, tokenizer, prompt template, quantization, runtime compatibility, license state, lineage, signatures, and rollback identity.
02
Inference plan
The exact task, model profile, endpoint, hardware profile, budget, output contract, fallback policy, and evidence requirements permitted by Providence.
03
Runtime lifecycle
Admission, load, warm, ready, execute, stream, cancel, drain, unload, crash recovery, and explicit failure classification.
04
Inference receipt
What ran, where it ran, which release and plan were used, resource and timing evidence, failures, and the safe next action.
05
Product verification
The consuming product tests the candidate against its own real acceptance contract. Provider cannot self-promote execution into customer success.
Buildroom
A model returning text is not enough. Buildroom must bind the result to a work order, apply governed changes, run verification, adopt job-specific proof, and own terminal engineering truth.
Explore Buildroom →FORGE
FORGE develops and qualifies model artifacts. A Provider handoff is a possible destination—not an automatic release or a dependency for every FORGE export.
Explore FORGE →Providence
Providence keeps Provider powerful but bounded: exact plans, explicit authority, trusted placement, no silent fallback, and product-owned acceptance.
Explore Providence →Release boundary: Provider is in active development. Runtime, hardware, performance, compatibility, and deployment claims belong to named certified releases and their evidence—not to the roadmap alone.