Concepts

Shared responsibility

What the consuming product, Deeplinq, the identity provider, and the deployment owner each control.

Deeplinq is an engine inside a product, not the product's identity system or payment processor. A production integration works when each boundary has one clear owner.

ConcernConsuming product or partnerDeeplinq engineDeployment owner
Product identityChooses the application and user experienceVerifies signed tokens and resolves them to engine principalsOperates Keycloak and its realms, organizations, clients, and memberships
Tenant placementSends users through the correct organization sign-inRequires one bound organization claim; never guesses or auto-provisionsCreates and maintains the engine↔provider identity binding
AuthorizationDecides who should receive elevated accessEnforces engine-held roles, model grants, resource grants, and ownershipGrants and revokes roles through the admin surfaces
Model accessChooses the product experience and requested modelRoutes only to entitled, priced, enabled connectorsRegisters connectors, pricing, grants, credits, and guardrails
End-user dataOwns notice, consent, and the product's source recordsIsolates tenant data and applies retention, deletion, screening, and audit rulesOperates PostgreSQL, object, vector, and optional memory stores
Provider credentialsNever exposes them to a browser or mobile clientSeals connector and OAuth credentials at restStores deployment secrets and controls egress
BillingOwns checkout and payment-provider processingOwns credits, holds, usage, limits, and reconciliation recordsFunds organizations or calls the billing top-up surface
AvailabilityHandles typed failures and degraded product statesFails closed when a configured governed dependency is unavailableMonitors readiness, capacity, backups, and recovery

Boundaries that must not blur

  • An application is one product and one Keycloak realm. A realm is a user namespace, so the same email in two applications is two unrelated people.
  • An organization is one customer inside that application. Its provider organization is explicitly bound to one engine organization.
  • A subject is the identity provider's identifier. A principal is the engine's stable identifier. Grants, ownership, limits, and teams use the principal.
  • A machine token represents a backend, not a person. It cannot reach user-owned conversations, connections, memories, or agent runs.
  • The engine processes credits, not payments. A payment service calls the idempotent billing top-up endpoint after money has settled elsewhere.

Handoff package for a consuming team

Give every integration team:

  1. the engine base URL;
  2. the application name and issuer;
  3. the engine organization UUID and provider organization alias;
  4. either a machine client or the end-user sign-in contract;
  5. the granted models, enabled capabilities, and commercial limits;
  6. the integration checklist;
  7. the support path and the X-Request-ID they must retain from failures.

Never hand over platform-administrator credentials, deployment secrets, or provider connector keys.

On this page