Every model, behind one governed API.
ORCA is our LLM gateway. Your applications call a single interface, name the provider and model they want on each request, and get authentication, spend limits, retrieval, and a governance guardrail set applied on the way through. Every tenant starts with guardrails built on the IMDA AI governance framework already in place.
A governed front door to the model providers.
Most teams wire their product straight into one model provider. That is quick to demo and awkward to run: one vendor, one set of keys, and no single place to enforce spend limits or safety checks. ORCA sits in between. Your product keeps calling the same interface while providers, models, and policies change behind it.
Quick to start
- Provider keys spread across applications
- Switching or adding a model means code changes
- Safety checks rebuilt in every application
- Spend visible only in the provider’s own billing
- Retrieval over your documents is a separate build
Built to run
- One key per tenant, with scopes and rate limits
- Providers and models chosen per request
- Governance guardrails on from the first request
- Budgets and per-request cost recorded in one place
- Document retrieval available on the same call
One interface, a lot less plumbing.
Everything the layer needs to do, done centrally and done quickly: providers, controls, retrieval, and a broad set of tools that run on our servers rather than yours.
Many providers, one API
Reach the major model providers, and any endpoint that speaks the same standard, through a single interface. You name the provider and model on each request, so adding or switching one is a change of parameter, not a rewrite.
Keys and scopes you control
Each tenant gets its own key with only the permissions it needs. Provider credentials are held encrypted, or you bring your own, and keys are stored hashed.
Guardrails on by default
Every tenant is provisioned with a governance guardrail set built on the IMDA AI governance framework, active from the first request. Checks run before the request reaches a provider and again on the response, and the set can be extended per tenant, per user, or per key.
Retrieval over your documents
Load your material into a vector store the gateway manages for you, then have the relevant passages added to a request automatically. Search it directly when you would rather handle that yourself.
Budgets and rate limits
Set weekly, monthly, or custom spending caps per tenant and hold traffic inside sensible limits, so a runaway job cannot become a runaway bill.
Request logs and cost attribution
Every call is recorded with its tokens, cost, guardrail results, and a request reference, so spend and behaviour can be traced back to the tenant and the moment.
Provider fallback
If the chosen provider fails, the request can fall back rather than surfacing an error to your user.
Fast by design
The gateway adds a thin layer over the provider call: checks run in parallel where they can, results stream back as they arrive, and repeat lookups are cached. Your users wait on the model, not on us.
A large tool set, running on our servers
Web search, page fetching, cached reads, document search, text extraction from files, image description, date and time, and more. They execute on the gateway, not on the user’s machine, so nothing needs installing and every tenant gets the same capability from day one.
Drop-in for existing code
The interface follows the shape most teams already build against, so standard client libraries work by pointing them at the gateway and using its key.
Answers grounded in your own material.
A model on its own knows nothing about your policies, contracts, or products. ORCA holds that material for you and puts the relevant parts in front of the model at the moment of the request.
Create a store
Each tenant gets its own vector store, managed by the gateway. If your documents already live in a provider-hosted store, that can be pointed at instead.
Load your documents
Send plain text, a file, or a link. Scanned pages and images can be read first, so the content of a PDF is searchable rather than sitting as an image.
Ask, with context attached
Name the store on a request and the relevant passages are included automatically, or query the store directly and decide what to do with the results yourself.
Singapore’s AI governance framework, implemented by default.
Governance is not an optional extra you remember to switch on. Every tenant is provisioned with a guardrail set built on the IMDA AI governance framework, live from the first request, applied in the layer you control rather than left to whichever provider answered. From there it can be tightened for a particular tenant, user, or key.
Accountability
Every request carries a tenant, a key, and a reference, so what was asked, which model answered, and what it cost can be established afterwards.
Data protection
Personal-data detection can flag or block sensitive content before a request leaves your boundary, and which provider may receive what is a matter of configuration.
Testing and assurance
Guardrails can be tried against a request before you commit to them, so a rule is proven before it starts blocking real traffic.
Incident visibility
When a check blocks something, the event is recorded against the request rather than disappearing into an application log.
Security
Scoped keys, hashed storage, encrypted provider credentials, and limits that stop one tenant affecting another.
Traceability of output
Responses are recorded with the provider and model that produced them, so an answer can be explained long after it was given.
Note: the IMDA AI governance framework is guidance, not a certification scheme. ORCA implements guardrails designed around its dimensions by default; it does not confer accreditation on your organisation.
A gateway, not your application.
ORCA deliberately handles one request at a time and does it well. Conversations, memory, and your own business logic stay in your product, which keeps the gateway predictable and keeps you in control of your own behaviour.
The call itself
- Authentication, scopes, rate limits, budgets
- Default governance guardrails, before and after the call
- The provider call, and fallback if it fails
- Retrieval from your document stores
- Its own tool set, executed server-side
- Logging, cost, and the audit record
The judgement
- Conversation history and memory
- Your prompts, rules, and house style
- Your own tools and the systems they touch
- Approvals and who is allowed to do what
- The experience your users actually see
The layer under everything we build.
ORCA is not a side project. It is what our own platforms call, which means it is exercised in production every day rather than only in a demo.
Behind TINA
Everything people do in the workspace reaches its model through ORCA, so day-to-day work runs under the same limits, guardrails, and records as everything else.
Behind YAPA
Assistants in employees’ pockets run under the same policies as the systems behind them, with no separate rulebook to maintain.
Inside what we deliver
Software built through the AI Delivery Pod can sit on ORCA from day one, so governance is part of the build rather than a later retrofit.
Put the controls where you can see them.
Tell us which providers you use and what you need to keep control of. We will show you how ORCA sits in front of them.
Get in touch → or write to enquiries@tangent9.com