Every request that flows through a governed AI platform passes through several distinct layers, each with a narrow responsibility. Understanding the boundaries between them makes it much easier to reason about where a given control — routing, redaction, approval — actually lives, and why.
| Layer | Responsibility |
|---|---|
| Identity & access | Authenticates the requester via SSO, resolves their role and team via SCIM, and attaches that identity to every downstream decision. |
| Policy & guardrails | Evaluates the request against content, security, and budget policies before anything is sent to a model — this is where PII redaction and prompt-injection screening happen. |
| Routing & gateway | Classifies the task and selects the best available model for it, handling failover if the primary choice is unavailable. |
| Knowledge & connectors | Retrieves relevant content from connected sources, tags it with provenance and trust level, and attaches citations to the final response. |
| Approval workflow | Intercepts any action classified as consequential and routes it to a named human approver before it executes. |
| Audit & logging | Records every step above — request, retrieved content, model used, output, and approval decision — as an immutable record. |
Why the order matters
Policy evaluation happens before routing, not after — a request that violates a content policy should never reach a model at all, regardless of which one would have been selected. Similarly, retrieval and provenance tagging happen before the model generates a response, so the model always knows which parts of its context are trusted instructions versus untrusted retrieved data.
A request, end to end
- An employee sends a request through the chat interface or an API call. Their identity, role, and team are resolved immediately.
- The policy layer checks the request against content and budget rules. If it's within a team's budget and doesn't violate a content policy, it proceeds; if not, it's blocked or flagged before any model sees it.
- If the request needs external knowledge, the connector layer retrieves relevant documents, tags each with its source and trust level, and passes them to the model as clearly-marked data, not instructions.
- The routing layer classifies the task and selects the appropriate model, considering cost, quality requirements, and current provider availability.
- The model generates a response. If the response includes a proposed write action — sending an email, updating a record, executing code — it's intercepted by the approval workflow instead of executing immediately.
- A named human approver reviews the proposed action in context and approves, edits, or rejects it.
- Every step — the request, retrieved sources, model used, generated output, and approval decision — is written to the audit log as an immutable record.
Why this is a platform, not a wrapper
Each of these layers could, in principle, be built and maintained separately — a gateway product for routing, a security product for redaction, a workflow tool for approvals. The reason to run them as one platform instead of four integrated point products is that the layers need to share context: the approval workflow needs to know which policy rule flagged an action, and the audit log needs a complete record across every layer, not four separate logs that have to be reconciled after the fact during an incident review.