Skip to content
ADVANCING AI. FOR THE BENEFIT OF HUMANKIND.A Mainely Code research & engineering vision
NORTHSTARBY MAINELY CODE

NORTHSTAR/Models & scale

Intended architectural reach

Across models.
Across machines.
Across boundaries.

The vision is one governed system of reasoning across every major general-purpose model family and every resource a mission is authorized to use—from local machines to sovereign infrastructure.

Architectural targets, not a list of certified integrations or provider partnerships.

Model breadth

No single model
defines the system.

General-purpose models, specialist models, open-weight models, commercial APIs, and private institutional endpoints—working together, and evaluating one another’s work.

Selection should consider demonstrated capability, evidence needs, available context, privacy, cost, deadlines, and independence. A model can investigate a subproblem, critique a finding, or contribute to synthesis without becoming the final authority.

Tools and MCP services belong behind their own admission and execution controls. Permission to read evidence is not permission to take an external action.

Elastic in more than one direction

A continuum of compute.
Not a fixed cluster.

“Omnidirectional” describes the intended ability to scale across resource count, capability, location, scheduling windows, and trust domains while preserving the mission’s constraints.

Local and distributed

A stack of old laptops, CPU-only workers, heterogeneous GPUs, and powerful workstations. Assign bounded work where it fits, and continue appropriately when nodes leave.

Private and institutional

Enterprise and research clusters, on-premises infrastructure, private schedulers, reserved GPU queues, and air-gapped environments where separately supported and qualified.

Public cloud capacity

The target includes major public cloud providers: queued GPU time, elastic instances, managed inference, and approved free-tier or paid-tier resources. Quota, billing, region, and availability must be observed—not assumed.

The scale we are working toward

Dozens. Hundreds.
A horizon of thousands.

Start with a coordinated constellation. Grow toward institutional fleets. Reach further as control-plane hardware and proven orchestration capacity advance.

Dozensof participating nodes

A constellation with purpose.

Complementary models and execution resources, coordinated around a shared mission—not simply answering the same prompt in parallel.

INITIAL DESIGN AMBITION

Hundredsof participating nodes

Institutional reach.

A wider field of inquiry across approved local, private, and cloud resources, with capacity, evidence, and authority kept explicit.

SCALING OBJECTIVE

Thousandsas a longer-term horizon

Grow the control plane.

Expand further as control-plane hardware advances—and only as scheduling, evidence handling, recovery, and coordination are proven at that scale.

FUTURE HARDWARE-DEPENDENT HORIZON

These are design ambitions, not measured capacities or a delivery schedule. Nodes, models, and simultaneous model calls are different counts; more nodes do not automatically mean better reasoning.

Topology-aware by design

Not just the same LAN.
Not just the same cloud.

The networking ambition includes private SD-LAN and SD-WAN, L2 switching, L3 routing, firewall policy, NAT, and approved IPsec or TLS-based VPN paths.

The system should reason from observed identity, reachability, topology, and policy, rather than assume a flat network. It must remain disconnected when no approved safe path exists.

Network planning and network enforcement are distinct responsibilities. The standalone Mainely Code network platform must establish its own simulation, staged enforcement, proof, and rollback before later product adoption. Inference workers do not inherit unrestricted network authority.

Windows-first and subsequent cross-platform implementations require separate backend and real-network qualification. An abstract contract or a website animation cannot establish packet forwarding, effective filtering, or tunnel interoperability.

Sovereign deployment direction

Control the boundary.
Not just the region.

01

Data

Decide what stays local, private, jurisdiction-bound, or eligible for external processing.

02

Identity

Bind nodes, services, approvals, and execution to verified identities.

03

Policy

Enforce tenant, budget, residency, and tool constraints before dispatch and publication.

04

Evidence

Retain an inspectable account of contribution, verification, uncertainty, and recovery.

Sovereign control is a design objective. Compliance, isolation, jurisdictional suitability, and security require deployment-specific assessment and evidence.