Skip to main content

Platform Resource Model

Taimoe organizes AI resources into tenant boundaries so that access, configuration, usage, and audit data can be evaluated in the correct scope.

Taimoe Platform resource hierarchy and tenant boundary

Organization and Team​

An Organization is the top-level customer boundary. It owns subscription and branding settings and provides the scope used to isolate administration, audit, conversation, and observability queries.

A Team is the operational ownership boundary inside an Organization. Virtual Keys, Agents, Runtimes, Knowledge Bases, and Connectors belong to a Team. Team selection therefore changes which resources a user manages, while Organization selection changes the tenant whose data can be queried.

Changing a selector in the console is not the security control by itself. Backend authorization and organization-scoped queries enforce the boundary.

Principals, roles, and bindings​

A Principal represents an identity such as a user, service account, or group. A Role is a named set of permissions. A Role Binding states that a Principal has a Role on a resource such as the platform, an Organization, a Team, or an Agent.

This relationship-based model supports resource-level grants without duplicating a separate membership table for every resource type. See Governance and access control.

Control plane and runtime plane​

Taimoe's console and management APIs form the control plane: they store configuration, ownership, policy, and status. Agent code, connector jobs, and provider inference services form the runtime plane: they execute work.

The distinction matters because registering a resource does not automatically force all related traffic through Taimoe. Governance applies to paths that use the platform's Gateway, managed APIs, and identity boundaries. Direct calls made with credentials owned by an external runtime remain outside application-level enforcement.

Current boundary​

The hierarchy and organization-scoped read paths are available. Some resource models still carry optional Organization or Team fields for migration compatibility; integrations should rely on documented APIs instead of inferring tenancy from database columns.