Rangoon: Inspectable SI Capabilities

The documented capability contract

Rangoon is a workspace in development for making an SI capability inspectable before a team plans deployment. Its public material describes records for profiles, skills, workflows, connectors, model targets, tests, and versioned artifacts. The point is to show the parts that shape behavior together, rather than treating a prompt, a selected model, or a tool list as a sufficient technical description.

This is a composition and review model. Public interface images use illustrative data and integration marks, and they do not establish runtime availability, connector compatibility, or a general right to act. A capability can be documented well while still requiring target-specific testing, operational decisions, and a separate authorization path for consequential actions.

Records make relationships reviewable

A useful capability record needs relationships as well as fields. A workflow can reference an agent profile, selected skills, expected inputs and outputs, model targets, connector operations, evaluation cases, and the artifacts used to create a compile preview. Each relationship gives reviewers a place to ask what changed, who owns it, and what evidence supports the proposed behavior.

Rangoon separates composition, execution, and governance views because they answer different questions. Composition describes what is assembled. Execution describes a planned path to a target and the test evidence expected for that path. Governance keeps compatibility, provenance, policy requirements, and version relationships visible before a deployment plan is accepted.

A record should also make its limits legible. A reviewer needs to see whether a relationship comes from declared configuration, a completed evaluation, a compatibility assessment, or an unresolved assumption. That distinction prevents a polished workspace from becoming evidence for more than the underlying records actually establish.

Hypothetical example: a research review assistant

Consider a hypothetical internal assistant that retrieves approved project documents and drafts a comparison for a human reviewer. A Rangoon workspace could represent the profile, retrieval skill, document-source constraints, output format, model target, evaluation cases, and artifact versions used for the draft. The reviewer can inspect the dependency graph before deciding whether the proposed capability is suitable for a particular environment.

That record makes concrete questions easier to surface: which document sources are in scope, what should happen when sources disagree, whether a model change alters the expected format, and which owner must review a connector update. The example is illustrative architecture work. It does not describe a deployed assistant, a hosted service, or a verified integration.

Testing should follow the declared boundaries

Capability tests should protect declared contracts rather than produce a vague success signal. For the hypothetical assistant, useful cases could cover an approved source, a missing source, conflicting context, an unsupported output request, and a model target that does not meet the stated constraints. The evidence should say what was tested and what remains outside the tested scope.

A passing test can support a local behavior claim; it cannot prove production availability, current connector behavior, or suitability for every team. Rangoon's public direction is to keep test context and compatibility planning visible so a reviewer can distinguish a validated component relationship from an assumption carried forward without evidence.

Failure states belong in the capability record

A composition review is incomplete if it models only the preferred path. Missing inputs, incompatible versions, unavailable targets, unapproved source material, and failing evaluations are all useful states to record. They clarify whether a workflow should stop, request review, use a bounded fallback, or remain unavailable while the owner resolves the issue.

This is also why versioned artifacts matter. When a profile, skill, connector operation, or model target changes, the affected workflow and its evaluation evidence can be reviewed as a relationship rather than inferred from a label. The change does not become acceptable merely because a related capability worked in an earlier configuration.

Capability composition stays separate from authority

Rangoon describes what a capability is configured to request and how that configuration can be inspected. It does not turn a connector, workflow, or model target into blanket execution authority. This distinction remains important even when a capability has useful tests and a well-understood dependency graph.

LNSAT is the separate pre-release authority and evidence model for one exact consequential action. Rangoon makes a proposed capability and planned execution path legible; LNSAT's model evaluates a bounded request against policy, scoped approval, and outcome evidence. Integration design connects the capability record to the exact action packet while keeping each system's responsibilities explicit.

Related capabilities

• SI infrastructure development
• SI agent governance and authorization