Skip to content
Mainely Code
The Great NorthMainely Code Providence ArchitectureExploreArchitecture brief
First-party inference

Great North Provider

Direction from Northstar. Execution through Provider. Proof throughout Providence.

Great North Provider is being built as a Mainely-owned inference platform—not an Ollama wrapper, a vLLM skin, or a compatibility proxy. It is intended to own model execution, scheduling, lifecycle, trusted placement, usage truth, recovery, and evidence end to end.

Read the public architecture briefReturn to The Great North

Active development: specific runtime, hardware, deployment, and performance claims will be published only for certified release paths.

Great North Provider public vision page
The ownership line

Provider owns execution—not cognition, policy, trust, access, or product acceptance.

Great North Provider owns

  • Immutable model-release identity and lifecycle
  • Admission, scheduling, batching, cache, and runtime execution
  • Streaming, cancellation, usage, cost, and resource evidence
  • Local and distributed Provider nodes
  • Recovery, quarantine, rollout, drain, and rollback
  • Mainely-native and compatible API surfaces

Provider does not own

  • Northstar's cognitive judgment or executive route
  • Prefrontal policy or tool governance
  • Network Fabric identity or effective network state
  • Licensing, subscription, or entitlement authority
  • Buildroom engineering acceptance or merge authority
  • Orb-Weaver design acceptance or Sasquatch customer journey
Defining contracts

Exact release. Governed plan. Verifiable receipt.

These contracts give Great North Provider an identity beyond a model-server endpoint.

ModelReleaseCapsule.v1

The deployable unit

  • Weights, tokenizer, template, and configuration
  • Approved runtimes, quantization, adapters, and hardware profiles
  • Lineage, license state, evaluations, limitations, and rollback target
InferencePlan.v1

The governed execution contract

  • Exact release or approved capability target
  • Budget, deadline, locality, fallback, cache, retention, and evidence
  • Structured-output and unknown-outcome behavior
InferenceReceipt.v1

The evidence of what ran

  • Plan and request digests
  • Model, runtime, node, timing, usage, cache, fallback, and retry evidence
  • Bindings back to the consuming product's verification record
Native runtime direction

No required external provider daemon.

External runtimes can remain optional adapters, rollback paths, and benchmark competitors. The certified path must be able to install, import an approved release, execute, stream, cancel, recover, prove, and unload with Ollama, vLLM, and llama-server absent.

Runtime

Mainely model loading and memory planning

Direct lifecycle ownership, resource reservation, hardware profiling, load, warm, infer, drain, unload, and verified release.

Performance

Batching and cache management

Priority-aware continuous batching, tenant-isolated cache policy, backpressure, per-token cancellation, and hardware-aware scheduling.

Correctness

Structured and constrained generation

Schema and grammar constraints, exact prompt-template identity, bounded output, normalized failure, and no silent substitution.

Scale

Trusted heterogeneous compute

Windows and Linux nodes, signed identity, Fabric eligibility, leases, artifact staging, warm pools, and distributed recovery.

Supply chain

Capsules and promotion

Content-addressed artifacts, signatures, lineage, licenses, evaluation, canary, promotion, revocation, and rollback.

Operations

Evidence-first lifecycle

Durable requests, cancellation, unknown outcomes, crash reconciliation, backup, restore, quarantine, and supportable diagnostics.

Qualification

Buildroom is the first demanding customer.

The acceptance standard is not that a model returned text. The output must survive the consuming product's real verification contract.

1

Admit

Prefrontal compiles a signed plan.

2

Execute

Provider selects the exact capsule and eligible node.

3

Receipt

The inference path produces evidence.

4

Verify

Buildroom tests the candidate in its real work order.

5

Learn

Verified outcomes improve bounded routing and release decisions.

Measured superiority

Better must be named, controlled, and proven.

Benchmark claims should use the same model, weights, quantization, prompt template, context, sampling parameters, hardware, and concurrency profile. Certification should publish time to first token, throughput, memory use, cancellation, recovery, sustained stability, identity rate, false-success count, and cost per verified outcome.

No release note should say faster, safer, or better without the benchmark and proof artifact that supports the claim.

The larger system

Provider is powerful because Providence keeps it bounded.

See how Great North Provider connects to Northstar, Prefrontal, Network Fabric, Project Sasquatch, Buildroom, Orb-Weaver, and the Licensing Server.

Explore Providence ArchitectureOpen the public PDF
The Great North public architecture brief cover