Platform model

Deeplinq sits between your trusted application backend and model providers. It does more than proxy requests: it resolves authority, enforces policy, and records usage before and after every model call.

Request path

Applications, organizations and members

Every request resolves to one application and one organization inside it, both read from signed claims in the token:

Application  → an identity-provider realm  → named by the token's `iss`
Organization → a customer inside it        → named by the `organization` claim
Member       → a person                    → named by `sub`, resolved to a principal

One engine serves many applications, and the same person can hold unrelated accounts in two of them under one email address. Identity model explains why the realm sits at the application level and who decides what a member may do.

Every request resolves to one internal organization. User identity is optional for organization-level operations and required for owner-scoped resources such as conversations, personal connections, and agent runs.

Tenant isolation exists at multiple boundaries:

• PostgreSQL rows are organization-scoped;
• vectors use one Weaviate tenant per organization;
• object keys carry a validated organization prefix;
• durable workers reload tenant identity from trusted records;
• tools are filtered to the invoking user's live connections.

Connectors and connections

These terms represent different ownership models:

• A connector is an organization-managed provider configuration used by the model gateway.
• A connection is a user-owned link to personal or external data, such as Gmail, Outlook, or an MCP tool server.

Governance

The engine applies model grants, credit availability, user limits, and guardrails before provider activity. Actual usage is captured into an append-only ledger and correlated with minimized audit events and traces.

This makes the API compatible at the edge without delegating authority, metering, or evidence collection to the upstream provider.