Build and share
Portable capabilities and open interfaces can help developers build on U.S. systems, compare alternatives, and carry useful work into global settings without hiding the source or authority boundary.
Rangoon.aiUnited States first.
Domestic AI
United States first.
Evidence before routing.
A launch architecture for choosing AI systems with explicit ownership, processing, geography, evidence, and authority boundaries.
Compose · Govern · Verify
More capability. Clearer boundaries.01
A U.S. builder mission
Rangoon is intended to help U.S.-based builders keep American AI companies and capabilities at the forefront of a global AI race. Open tooling, portable agent skills, inspectable governance, and self-hosting or owner-controlled deployment give teams practical ways to build, evaluate, and adopt useful systems across borders. This is a product mission, not a claim of market leadership, government sponsorship, or automatic trust based on origin.
Evidence travels with adoption
Global reach remains reviewable: teams can inspect provider facts, route evidence, governance inputs, and deployment controls before choosing a system for a workload.
02
Launch specification
Domestic means the United States. Rangoon starts with AI companies, services, and operating assumptions that teams can review through U.S.-focused evidence. It also supports an explicit reviewed path to non-U.S. systems when a team accepts the data, jurisdiction, support, and authority implications. Geography is a decision field, not a marketing shortcut.
A declared route
Every proposed model route records provider, model origin, hosting location, processing location, support location, subprocessors, data class, retention, egress, budget, and action permissions.
A bounded decision
A route can be accepted, restricted, sent to review, or denied. A model suggestion or provider credential cannot silently widen the route or authorize a consequential action.
03
Separate the facts
Ownership, hosting, processing, support, subprocessors, and model origin describe different relationships. A U.S.-owned company may host or process through infrastructure in another jurisdiction; a U.S. region does not prove U.S. ownership; a model family’s origin does not identify the current endpoint. The record keeps each field explicit and evidence-backed.
Provider record
Capture the legal or commercial provider, service operator, model publisher, endpoint region, support boundary, and subprocessors as separately reviewable facts.
No inference by brand
Names, logos, domains, reseller relationships, and cloud regions are discovery clues. They do not replace current provider disclosures, contract terms, or release evidence.
04
Review non-U.S. systems deliberately
Non-U.S. systems remain available as an explicit review choice. The review can require a permitted data class, a named business owner, a documented processing path, an approved retention posture, an egress decision, and a narrow action scope. The result records why the route is acceptable for that workload and when the evidence expires.
Known is not approved
A known provider, model, or region can still require human review. Approval applies to a packet, scope, purpose, and time window rather than to a brand in the abstract.
Unknown becomes review
Missing, contradictory, stale, or unverifiable geography and subprocessor evidence moves the route to review. It does not fall back to a less visible provider.
05
Freshness and fallback
Evidence has a source, observed time, freshness window, and review state. When a provider changes routing, retention, subprocessors, supported capabilities, or contractual posture, the affected route can become stale and require re-evaluation. Rangoon does not silently substitute another model or endpoint when a route is unavailable or uncertain.
Fail closed at the boundary
An expired lease, missing digest, changed data class, unsupported capability, or unresolved provider fact blocks the proposed action or escalates it for review.
Explain the decision
Decision evidence identifies the selected route, rejected alternatives, policy inputs, approval requirements, and the exact reason a human must decide.
06
Control data and consequence
Routing is only one control. The launch architecture evaluates data classification, allowed egress, retention, budget, destination, operation type, and action permissions together. Reading a public document, drafting a response, changing a repository, sending a message, and modifying a production system have different consequence levels even when they use the same model.
Data boundaries
A packet declares what may leave the boundary, which transformations are allowed, how long the provider may retain it, and which destinations or subprocessors are excluded.
Action boundaries
Budget and credential scope do not authorize a side effect. The requested operation, target, approval, one-time authorization, and receipt remain specific to the action.
07
One authority path
LNSAT is the reference execution-authority and evidence engine. Other policy and identity engines contribute bounded inputs. A conforming external execution-authority adapter can provide the same lifecycle; a policy allow by itself cannot replace it. The flow binds an exact request packet and digests, evaluates policy, obtains approval when required, creates a scoped one-time authorization, redeems it atomically, and records a receipt or outcome unknown for reconciliation.
Inputs are not permission
OPA, Cedar, OpenFGA, OIDC, OAuth, SPIFFE, model classifiers, provider credentials, and connector metadata can inform identity or policy. None independently grants execution authority.
Evidence survives uncertainty
Replay, scope widening, stale route evidence, revocation, missing receipt data, and uncertain external effects remain visible states that require denial or reconciliation.
08
Review at launch
The application launch architecture presents provider and route evidence as versioned compatibility records. It does not claim a shipped adapter, certification, regulatory approval, or universal domestic status for any named system. Teams review the published release artifacts and current evidence before enabling a route for a real workload.
Release truth
Supported providers, regions, model families, connectors, platform rows, and policy behavior become claims only when the corresponding versioned evidence and release artifact are published.
Owner decision
A launch record helps an owner make a documented choice. It does not remove the need for organizational review, contractual judgment, or a separate production authorization.
