Develop with your Twin
Bring approved Twin knowledge into an application, service, or automated workflow.
Develop with your Twin when a team needs approved knowledge inside its own product, service, or workflow.
You can start with a small read-only question-and-answer flow, use typed tools in TypeScript, or guide setup from the command line. Every route uses the same published Twin knowledge and organisation access controls.
Connect an AI assistant
Use approved Twin knowledge from ChatGPT, Claude, Codex, or Claude Code.
Build with the REST API
Start and read governed Twin queries from your own service.
Use the TypeScript SDK
Build a managed Twin client with typed methods and results.
Use the Twin command line
Inspect channels, query your Twin, and submit feedback from a terminal.
Choose the simplest route
| What you want to do | Start here |
|---|---|
| Ask approved business questions without writing code | Twin workspace, ChatGPT, or Claude |
| Let a coding agent use Twin knowledge while it works | Codex or Claude Code |
| Add a governed question-and-answer flow to a service | REST API |
| Build a managed TypeScript client | TypeScript SDK |
| Inspect channels, query the Twin, or submit feedback from a terminal | Twin command line |
Start with the smallest route that meets the user’s need. A customer-facing application does not need access to internal administration or runtime controls in order to ask a governed question.
The public query shape
A public Twin question is intentionally focused:
- The user signs in.
- The client optionally selects a channel and asks a question.
- The Twin creates a private session through the canonical router.
- The client checks the result until it is complete.
- The result identifies the knowledge and evidence used.
The client does not choose the organisation, underlying relation, database query, AI model, or internal tools. The service derives those controls from the signed-in user, channel access, and server-owned routing policy.
Before you begin
You will normally need:
- a Twin workspace with the intended knowledge published and the exact version activated for its configured deployment;
- at least one accessible channel or other routed Twin context;
- a connection route enabled for that organisation;
- an approved sign-in or service identity;
- a real question for end-to-end verification.
For a person signing in through ChatGPT, Claude, Codex, or another external client, the provider registration and upstream organisation mapping must also resolve to the intended Twin organisation. Your connection pack confirms these details; clients must not supply or override them in a question.
Do not treat a health check or saved configuration as proof that the connection works. Complete sign-in and a real governed query before marking it ready.
Technical routes are adapters into the same Twin
REST, the TypeScript SDK, the command line, and remote agent connections do not create alternative data or execution paths. The Twin keeps the organisation, channel access, data bindings, and permitted capabilities under server-side control.
Build for people as well as software
Applications should show a useful answer, its status, and relevant channel links. Keep query, task, and session identifiers available for support, but do not make users understand run orchestration or database terms to benefit from the result.
When a question is unsupported, present the failure clearly. Do not silently switch to an unreviewed data source or a general AI answer.