Deployment modes

Use the best model available.
Keep the same mission contract.

Run licensed local models at disconnected edges, reach authority-approved frontier endpoints in connected systems, or combine both. Stark is designed to preserve the same roles, tools, approvals, and evidence as model access changes.

Designed for controlled environments

Stark fits inside the boundary your program approves.

The runtime architecture does not require a cloud control plane. Local operation still has to be assembled, measured, and accepted in the environment you actually deploy.

Approved / controlledModel providers

Licensed local artifacts, approved remote endpoints, executable identity, model digest, configuration, and trust policy.

Decision boundaryStark Runtime

Concurrent agents, bounded context, typed tools, lifecycle, policy handoff, and evidence record.

System of recordMission host + storage

State, time, identity, permissions, consequences, logs, and program-owned persistence.

Air-gapped operation is deployment-specific.

Model acquisition, updates, remote providers, telemetry, package retrieval, and operator workflows must each be explicitly closed or controlled. A local filename or absent cloud service is not enough. No-egress behavior is deployment-specific and must be verified in the named environment.

Operating profiles

One runtime from isolated edge to approved cloud.

Choose the model reach that fits each role and environment while preserving a consistent control model across the program.

01 / LOCAL

Disconnected edge

Keep models, tools, policy, state, and evidence inside the controlled environment with no external model API required by the architecture.

Verify per installation
02 / CONNECTED

Approved frontier

Use authority-approved endpoints while Stark preserves the same role, tool, approval, host-authority, and evidence contracts.

Provider path implemented
03 / HYBRID

Continuity by policy

Route work between local and connected providers by mission role, data boundary, availability, cost, or performance policy.

Routing planned

Deployment evidence

Turn a broad security promise into facts your program can review.

Stark gives delivery teams a concrete set of proof points for the named model, executable, host, and network boundary. Final scope and acceptance remain with the customer program.

01 / PROOF POINT

Know what can connect

Inventory every compiled provider, endpoint, telemetry path, and optional network feature.

02 / PROOF POINT

Know what is running

Record the executable, SDK revision, model digest, configuration, and imported dependency checksums.

03 / PROOF POINT

Prove the boundary holds

Measure network behavior, lifecycle, cancellation, failure, and teardown in the environment the program will evaluate.

04 / PROOF POINT

Make the result repeatable

Tie every conclusion to a reproducible build, named model, host, boundary, time, and acceptance procedure.

We help build the evidence. Your program decides what passes.

The runtime does not confer classification authorization, accreditation, certification, endorsement, operational suitability, or an Authority to Operate.

Pinpoint can support technical characterization, controlled packaging, instrumentation, repeatable acceptance runs, and remediation of observed gaps. The responsible program and its designated authorities decide what evidence is required and what the deployment is permitted to do.

Start with the mission boundary

Bring the system you trust.
We’ll map governed agents around it.

Keep all initial inquiries unclassified and non-sensitive. Do not send controlled data, credentials, export-controlled material, or system artifacts through the public website.

Schedule a mission briefing