# Rangoon technical launch specification Launch specification. Describes the launch product architecture; application source, versioned compatibility results and release artifacts are published at launch. ## 1. Product role Rangoon is a control plane for governed AI agent capability. It gives teams one inspectable model for agents, instructions, skills, workflows, tools, connectors, policies, tests, deployment targets, versions, and evidence. Rangoon manages what a capability contains, where it is compatible, how it changes, and what evidence accompanies a change. It does not replace an underlying model or harness, and configuration does not become authority merely because a capability describes an action. The product has two connected surfaces. Capability management handles composition, provenance, compatibility, versioning, review, and deployment preparation. Governance handles policy inputs, approvals, execution authorization, connector boundaries, receipts, and audit evidence. The separation lets teams use different model providers, agent harnesses, policy engines, identity systems, and infrastructure while retaining one authority boundary for consequential work. ## 2. Capability graph The canonical object is a capability graph. Nodes represent an agent profile, instruction, skill, workflow, model profile, tool, connector operation, context source, policy requirement, approval requirement, test, harness, environment, bundle, or evidence record. Edges carry meaning: a dependency is different from a reference; a data flow is different from an execution path; a policy requirement is different from a tool invocation; an assignment is different from an approval. Graph relationships preserve ownership, origin, dependencies, compatibility, assignments, effective versions, and downstream impact. A graph view can answer which agents use a skill, which workflows depend on a connector, which harnesses can represent an asset, and which policy changes affect a bundle. A visual edit creates a versioned proposal and diff. It does not silently mutate active agent state. ## 3. Structured assets and schemas Rangoon treats agent configuration as structured software. Assets have stable identity, content, schema version, owner, source, provenance, inputs, outputs, tools, dependencies, policy requirements, compatibility claims, tests, lifecycle state, and references. A capability manifest can be exchanged between the control plane, adapter, review, and release layers. The following is a conceptual shape for communicating a capability. It is an illustrative schema, not a released API: { "kind": "rangoon.capability", "schemaVersion": "illustrative-1", "id": "capability.example.review-agent", "version": "1.2.0", "contentDigest": "sha256:", "source": { "uri": "", "revision": "" }, "effectiveConfiguration": { "agentProfile": "", "instructionRefs": [""], "skillRefs": [""], "contextRefs": [""], "modelProfile": "", "connectorOperations": [""] }, "policy": { "requirements": [""], "approval": "required" }, "compatibility": { "harness": "", "result": "" }, "tests": [""], "provenance": { "parents": [""], "review": "" } } Fields, identifiers, endpoint names, and SDK contracts become normative only when published with a versioned release artifact. Examples on this site explain the model; they are not callable API instructions. ## 4. Versioned bundles and effective configuration A managed bundle pins the agent profile, instruction and skill versions, context, workflow versions, policy requirements, connector requirements, target harness, adapter version, and tests. A bundle digest identifies the exact configuration submitted for review. The effective configuration records inherited layers, model overlays, assignments, compatibility decisions, and resolution trace so an operator can see what an agent would receive at a specific point in time. Universal constraints remain separate from provider-specific rendering. A model overlay can add syntax or implementation detail but cannot remove inherited prohibitions, approval requirements, or evidence duties. Active work resolves only compatible, approved, non-expired versions. Mid-task changes require a new context boundary or explicit restart rule; they cannot silently rewrite an already-authorized operation. ## 5. Provenance and import safety Imported repositories, directories, bundles, instruction files, scripts, hooks, schemas, and connector manifests are untrusted input. Discovery identifies structure, references, candidate capabilities, dependencies, and policy-sensitive behavior without executing imported scripts. Each suggestion retains source location, revision, detection method, confidence, ancestry, and review state. A model classification is evidence for a human or deterministic validator to inspect; it is not authority. Decomposition can separate project context, coding rules, testing procedures, deployment procedures, references, and tool requirements. Merge and split operations preserve source assets and ancestry. Content-addressed storage and lockfiles make immutable assets reproducible across checkout, offline work, export, backup, and audit. Garbage collection respects active assignments, rollback targets, legal holds, and evidence references. ## 6. Harness compilation and compatibility Rangoon compiles canonical assets through versioned harness adapters. An adapter discovers supported native configuration, maps concepts into the canonical model, reports capabilities, generates target artifacts, validates output, and explains transformations. Compilation previews generated structure, context impact, unsupported behavior, warnings, dependencies, test results, and output differences before a target receives a bundle. Compatibility is a versioned result, not a brand promise. A result can identify fully compatible behavior, behavior compatible with adaptation, partial representation requiring review, or unsupported behavior. The matrix records harness and runtime versions, asset types, model and tool support, hooks, context limits, output schemas, permission model, filesystem behavior, and adapter version. Unsupported or stale capability fails closed. A named harness on a public page is an interoperability target; it is not proof of a shipped adapter or certification. ### Runtime, framework, and inference-provider categories Compatibility distinguishes three technical layers. An inference provider supplies model inference and provider-specific capabilities. An execution runtime or agent framework owns the loop that assembles context, selects tools, persists state, and reports a run. A business connector performs a bounded operation against an external system. These layers vary independently: changing a model provider does not make a runtime adapter a connector, and a connector does not become an execution runtime because it can call a model. Runtime compatibility records can cover OpenClaw, NVIDIA NemoClaw, Claude Code, Codex, and Gemini CLI. Framework records can cover LangGraph, CrewAI, Microsoft Agent Framework, and OpenAI Agents SDK. Model-family records can cover OpenAI GPT and reasoning models, Anthropic Claude, Google Gemini, Z.ai GLM, DeepSeek, Qwen, Moonshot Kimi, Mistral and Codestral, Grok, Meta Llama, MiniMax, Cohere Command, NVIDIA Nemotron, Amazon Nova, IBM Granite and AI21 Jamba. Serving records are separate: Ollama, vLLM and LM Studio describe owner-managed inference environments, while Hugging Face Inference Endpoints describes a managed serving option. A model family and the service hosting it are different compatibility dimensions. These names identify compatibility categories and review targets; they do not assert a shipped adapter, certification, hosted integration, or provider account path for any named system. Provider behavior, model version, tool protocol, context limits, retention, and regional controls remain evidence fields in each compatibility result. Reference documentation for named ecosystems includes Z.ai's quick start at https://docs.z.ai/guides/overview/quick-start, NVIDIA NemoClaw's overview at https://docs.nvidia.com/nemoclaw/latest/about/overview.html, Microsoft Agent Framework at https://learn.microsoft.com/en-us/agent-framework/, Gemini CLI documentation at https://geminicli.com/docs/, and Ollama API documentation at https://docs.ollama.com/api/introduction. These references describe external systems; they do not establish Rangoon support, endorsement, or a release claim. Model profiles pin the exact model identifier, provider or serving endpoint, model revision where exposed, context and output limits, supported modalities, tool-call representation, structured-output behavior, regional routing, retention policy and usage accounting. A compatible API shape does not imply identical tool semantics or authority enforcement. Model selection and fallback preserve task data restrictions and approval scope; unsupported capabilities stay visible. Adapter contracts keep the boundaries explicit. A runtime adapter describes lifecycle hooks, context assembly, tool invocation, state, interruption, receipt handoff, and target constraints. A framework adapter describes graph or task semantics, node state, retries, persistence, and generated configuration. An inference adapter describes model identity, request shape, capability limits, usage evidence, and policy-relevant metadata. A connector adapter describes an external operation and its side effects. None of these adapters can approve an action or widen an authority ceiling. ## 7. Workflow states Workflows connect triggers, agents, skills, tools, data, decisions, policy gates, approvals, waits, branches, retries, exception paths, notifications, receipts, and completion states. A workflow state describes where work is and what evidence is required next. Typical states are proposed, validated, awaiting approval, authorized, executing, succeeded, failed, outcome unknown, reconciling, cancelled, revoked, and rolled back. State transitions are explicit and auditable. An expired approval cannot move work to execution. A cancellation or disconnect cannot be recorded as success, failure, or confirmed non-execution without reconciliation. A workflow can pause at a policy or human gate while preserving the exact request, effective bundle, target, scope, and evidence references. ## 8. Connector operations and side effects Connectors expose named operations, bounded inputs, expected outputs, credentials by reference, network requirements, side effects, idempotency behavior, risk, policy metadata, and receipt obligations. Installation, enablement, credential assignment, agent permission, policy evaluation, approval, and execution are separate decisions. A connector is an adapter boundary, never ambient authority. Side effects are declared before authorization. Safe retries require an operation identity and idempotency key that bind the exact request digest. A repeated request with the same identity and digest can return the existing result; a changed digest fails closed. A failed or interrupted operation enters the outcome_unknown state when the system cannot prove whether the external effect occurred. Reconciliation queries bounded evidence and resolves the state before any retry or rollback decision. ### Corporate connection catalog Connection categories cover Microsoft 365, Teams, and SharePoint; Google Workspace; Salesforce; ServiceNow; Jira and Confluence; Slack; GitHub and GitLab; Notion and Linear; Snowflake and Databricks; PostgreSQL; and identity systems such as Entra ID, Okta, Auth0, and Keycloak. A catalog entry describes publisher, operation family, supported resource types, OAuth scopes or other credential references, data classification, rate and retry behavior, side effects, receipts, compatibility, and disablement. A catalog is a review surface for connections; it is not a marketplace grant or an execution endpoint. OAuth tokens and scoped credentials prove delegated access to a provider resource. They do not authorize an agent operation. Identity systems authenticate a principal or workload, and a connector can use that identity as bounded policy input. LNSAT or another selected authority path still evaluates the exact packet, target, resource, scope, policy, approval, expiry, and connector operation before execution. Credential possession, connector installation, catalog entitlement, or runtime selection cannot bypass that decision. ## 9. LNSAT authority reference LNSAT is Rangoon's reference execution-authorization and evidence engine. The authority flow is: an agent, human, or automation proposes a versioned action packet; Gateway authenticates identity and session, binds project, environment, resource, target, capabilities, risk, time bounds, nonce, idempotency, and exact digests; policy evaluates the validated packet; a scoped human approval may be required; Gateway creates a server-side authorization and one-time capability; Gateway atomically redeems it before consequence; the connector or adapter performs the bounded operation; the result becomes a receipt or outcome unknown; reconciliation and audit bind the chain. LNSAT policy is deterministic for the same validated input and policy set. Unknown capability, incomplete evidence, expiry, replay, scope widening, digest substitution, missing receipt data, or revocation fails closed. A receipt binds requested, approved, and executed digests, authorization consumption, adapter and sandbox identity, timing, bounded result, rollback evidence, and reconciliation. LNSAT records proof; MCP, A2A, SDKs, model suggestions, telemetry, and connector metadata do not grant authority. This architecture describes the authority contract and launch integration boundary. It does not imply that every signer, runtime adapter, connector, installer, or hosted service is available before its release artifact and evidence are published. ## 10. Pluggable governance and identity LNSAT is the reference authority path. Rangoon can accept policy signals from OPA, Cedar, OpenFGA, or another compatible engine through a bounded adapter. An external engine may evaluate policy input or express relationship facts; it cannot issue approval, execution authorization, or a receipt on its own. Every adapter preserves canonical packet fields, deterministic ceilings, approval requirements, one-time consumption, and audit binding. OIDC and OAuth authenticate or delegate identity and SPIFFE can provide workload identity. None replaces policy, approval, authorization, receipt, or reconciliation. OpenTelemetry and CloudEvents carry bounded observation and export evidence; they are not an authorization channel. Model gatekeepers can classify, route, explain, or recommend, but uncertainty, conflict, unavailable model, and drift resolve to deny or human escalation for consequential work. ## 11. Deployment topology and containers The launch topology separates an owner-controlled server and control panel from least-privilege clients, workers, connectors, and optional desktop or tray interfaces. Server services expose the Gateway boundary; clients advertise capability and accept only authorized work. They do not become policy or approval authority. Docker, Compose, and OCI are packaging and service-topology options for an owner-controlled server. They describe how bounded services can be assembled, health-checked, upgraded, and rolled back. Packaging isolation is different from runtime isolation: a container boundary does not make an arbitrary shell safe, does not create a policy decision, and does not authorize a connector. Runtime execution remains sandboxed, capability-bound, and receipt-producing according to the selected adapter and platform. Exact images, manifests, signatures, and supported rows are release artifacts. ## 12. Desktop, server, and mobile boundaries Rangoon supports capability-aware architecture across macOS, Linux, and Windows desktop or server environments. OS and architecture compatibility are recorded per release artifact, not inferred from a product name. CPU, GPU, NPU, memory, storage, power, thermal, network, trust, and runtime facts can affect eligibility and policy. iOS, iPadOS, and Android are distinct embedded SDK and edge-worker environments. A Mobile Policy SDK can verify local policy input inside an owner-approved application without independent authority. An opt-in Mobile Edge Worker can hold a signed bounded lease, respect OS lifecycle and user consent, and advertise only its declared capability set. Mobile background limits, permissions, connectivity, secure storage, battery, and device attestation create different constraints from a server. A mobile device cannot silently widen scope or become the policy authority. ## 13. APIs and adapter contracts Rangoon describes conceptual contracts for packets, manifests, policy input, approvals, compatibility results, connector operations, receipts, audits, and adapters. Each contract carries version, identity, digest, scope, provenance, expiry, and validation rules. Adapters are named by published release artifacts and compatibility matrices. This website invents no endpoint paths, SDK package names, authentication flows, or install commands. A conceptual field list is documentation; it is not a callable API. ## 14. Marketplace and commercial boundary An extension catalog can show publisher provenance, source reference, license, version, signature or verification evidence, permissions, network access, declared side effects, data classes, compatible runtimes, tests, maintenance state, and rollback or disablement path. A catalog entry is not authority. Installation, enablement, credential assignment, agent permission, policy decision, approval, and execution remain separate. The open core contains portable authority contracts, canonicalization and cryptographic behavior, fail-closed Gateway enforcement, self-hosted base components, stabilized manifests, SDKs, conformance fixtures, and security guidance. Paid extensions can add visual management, certified connectors, model packs, support, compliance operations, hosted or hybrid services, and lifecycle convenience while preserving the same authority lifecycle. Entitlement never becomes policy allow. Open-source and commercial licenses take effect only through the actual published repository, package, or release artifact. The launch product can publish license and publisher provenance per artifact; this document does not grant rights or claim a license for assets not yet published. ## 15. Development and release methodology Rangoon development uses immutable inputs, schema validation, deterministic policy evaluation, provenance, simulation, compatibility tests, narrow approvals, canary rollout, observation, rollback, and audit. A release records exact source revisions, content digests, adapter versions, supported platform rows, test evidence, policy obligations, signatures or explicit unsigned status, and recovery instructions. This method reduces ambiguity; it is not a magic security guarantee. Security depends on correct implementation, deployment-owner controls, credential handling, review, monitoring, and timely response. A green test or model recommendation does not authorize merge, deployment, production mutation, or release. Human owners retain those decisions. ## 16. AI access and citation The public AI resources are documentation surfaces: /llms.txt, /llms-full.txt, /technical.txt, /ai/, /ai.txt, /agents.txt, and /.well-known/ai-policy.json. They help readers discover and cite the product model. They do not expose agent execution, MCP, A2A, connector-action, hosted command-center, or production authorization APIs. Rangoon is developed and maintained by Hypler. All public website content and data are open to automated reading. Hypler explicitly permits AI training, fine-tuning, evaluation, retrieval, summarization, translation, and commercial AI use of public content it owns or can license; see /permissions.txt and /terms/#public-content. Third-party and trademark rights remain separate. Public reading does not grant repository write, credential, deployment, private-data, or production access. The application repository, versioned compatibility records, and release artifacts are the source of launch truth when published. ## 17. Reference implementation technologies The LNSAT reference foundation combines TypeScript control-plane contracts and services, TypeScript/React operator surfaces, and Rust foundations for deterministic contracts, local credential handling, embedded SQLite durability and a bounded loopback daemon. Cross-language fixtures and conformance tests keep validation and canonical serialization consistent. A language migration never silently changes an authority contract. These implementation foundations are distinct from released Rangoon application artifacts. SQLite supports an embedded local durability boundary with transactions, migrations, integrity checks and backup evidence. Team-scale storage adapters must preserve the same contract and audit semantics. JSON schemas and content digests identify configuration and evidence; HTTP carries control-plane operations; MCP and A2A remain integration transports. Docker and OCI package services, while Compose describes service configuration and persistence. None of those technologies independently proves that a requested action is authorized. ## 18. Claw ecosystem integration Rangoon’s launch integration architecture includes OpenClaw and the wider claw ecosystem through versioned harness and authority adapters. OpenClaw supplies an agent experience. NVIDIA NemoClaw is a reference stack that adds OpenShell sandbox and lifecycle operations around supported agents. Rangoon connects capability bundles, policy requirements and evidence to these runtime boundaries; it does not treat sandbox enrollment or a vendor credential as execution approval. NanoClaw, IronClaw, PicoClaw and ZeroClaw are ecosystem targets. An adapter must document the runtime version, supported skill representation, tool interception points, identity mapping, sandbox boundary, authorization binding and receipt behavior before claiming coverage. These names do not imply vendor endorsement or universal compatibility. A compatible transport is not proof of full authority conformance. Primary technical references: https://github.com/openclaw/openclaw ; https://docs.nvidia.com/nemoclaw/latest/about/overview.html ; https://www.openpolicyagent.org/docs ; https://docs.cedarpolicy.com/ ; https://openfga.dev/ ; https://docs.docker.com/compose/intro/features-uses/ . ## 19. United States-first AI routing Domestic AI means the United States in the launch architecture. Rangoon's mission is to help U.S.-based builders keep American AI companies and capabilities at the forefront of a global AI race through open tooling, portable agent skills, inspectable governance, and self-hosting or owner-controlled deployment. That is a product intent, not a claim of market leadership, government endorsement, or automatic trust based on origin. Rangoon evaluates U.S. AI companies and services first, then permits an explicit review path for non-U.S. systems when a team can accept the associated ownership, hosting, processing, support, subprocessor, model-origin, jurisdiction, and evidence conditions. Those dimensions remain separate. A U.S.-owned provider can use infrastructure or subprocessors elsewhere, and a U.S. region does not establish ownership or model origin. Portable capabilities and open boundaries support global adoption without weakening review. Each route record carries provider and model identity, ownership evidence, hosting and processing locations, support boundary, subprocessors, data classification, allowed egress, retention, budget, action permissions, freshness window, source references, and review state. Missing or contradictory facts become unknown and move to review. Expired evidence, changed routing, unsupported capability, or an unavailable endpoint does not trigger silent fallback to another provider. The system records the proposed route and the reason for denial, escalation, or approval. LNSAT remains the reference execution-authority and evidence engine for a consequential operation. An inference provider, runtime, identity assertion, OAuth credential, policy result, or connector entitlement can supply bounded inputs; none independently grants authority. The authority path binds the exact packet and digests, evaluates policy, obtains any required approval, issues a scoped one-time authorization, redeems it atomically, and records a receipt or outcome unknown for reconciliation. OPA, Cedar, OpenFGA, OIDC, OAuth, and SPIFFE can participate through bounded adapters while preserving that ceiling. This routing model describes the launch architecture and its evidence contract. It does not claim a shipped adapter, provider certification, regulatory status, or current availability for any named AI company, region, model, or connector. Compatibility and release claims require versioned artifacts and current evidence published with the application.