# AI delivery for client systems

> Rangoon provides a launch architecture for development firms that need to design, review, and hand off agent capabilities while keeping client boundaries, approvals, and versioned delivery clear.

Canonical: https://rangoon.ai/solutions/development-firms/

Status: Launch specification. Application source and releases arrive at launch. Screenshots contain illustrative data.

## Separate client and integrator responsibilities

Client objectives, implementation work, runtime access, approval authority, and operational ownership are different responsibilities. Capability records make those roles explicit rather than treating a delivery team as the ongoing operator.

### Bounded client context

A record can identify the client workspace, project purpose, data classification, source material, and permitted target environments for a proposed capability.

### Integrator scope

Implementation teams can document the assets they created, dependencies they selected, transformations they made, and work that remains for the client to approve or operate.

## Version the deliverable and its dependencies

A delivery bundle can pin capability versions, workflow definitions, policies, connector requirements, adapter versions, target constraints, and supporting test evidence for a defined client handoff.

### Reviewable change sets

Reviewers can compare a changed capability with its provenance, dependent assets, generated target output, and compatibility warnings before it moves to a client environment.

### Target-aware delivery

Harness adapters explain the files, activation rules, and behavior that differ by runtime instead of presenting a generic capability as universally portable.

## Set deployment ownership before handoff

A delivery plan can state who prepares the bundle, who validates the target, who approves activation, who operates the environment, and who owns rollback decisions after handoff.

### No ambient production access

A connector credential, deployment bundle, or assigned skill does not grant an integrator or agent unrestricted authority to change a client system.

### Clear recovery responsibility

Staged delivery, pause, rollback, and reconciliation expectations can be included in the operational handoff record.

## Use approvals for the proposed operation

Where a workflow proposes a consequential action, the LNSAT reference lifecycle evaluates the exact target, resource digest, scope, policy input, approval, and adapter operation at execution time.

### Client decision authority

Client owners can review the requested action and its evidence without an implementation artifact becoming a blanket permission to operate.

### Evidence for support

Receipts and reconciliation states preserve the information needed to investigate an outcome or transfer operational context between teams.

## Hand off support with a defined operating record

A useful handoff includes version identifiers, target constraints, known limitations, test evidence, owner contacts, change history, and the boundaries between implementation support and client operations.

### Support boundary

The record can distinguish a delivery question, a runtime issue, a client policy decision, and a request for a new capability version.

### Launch availability

Application source and release materials will define available interfaces, packages, and support boundaries at launch; this page does not publish an SDK, installer, or managed support offering.


## References and related documentation

- [Security principles](https://rangoon.ai/security/)
- [Architecture](https://rangoon.ai/architecture/)

## More information

- [Documentation index](https://rangoon.ai/llms.txt)
- [AI access and policies](https://rangoon.ai/ai/)
- [Source repository](https://github.com/hypler-dev/rangoon)