Build-time vs. Runtime Data

The Bivariant platform separates build-time definitions (blueprints) from runtime data (per-organization). This separation is fundamental to multi-tenant isolation and safe distribution.

The platform makes a clear distinction between build-time data (defined in blueprints) and runtime data (created per organization when apps are used). This separation is fundamental to how multi-tenancy, versioning, and distribution work.

Build-time data

Build-time data lives in the blueprint. It defines what an application can do and is shared across all organizations that install it.

Component	What's stored	Scope
Agent definitions	Name, description, avatar, knowledge base config, default flow	Shared across all installations
Flow definitions	Step graph, input/output schemas, configuration	Shared across all installations
Integration definitions	Operations, auth methods, event channels, data types	Shared across all installations
Action definitions	Input/output schemas, runner config, target IDs	Shared across all installations
Collection schemas	Field definitions, types, validation rules	Shared across all installations
Screen definitions	Component layout, data bindings	Shared across all installations
Event definitions	Type, schema, channel config	Shared across all installations
Auth method definitions	Credential field schemas, OAuth2 config	Shared across all installations

Build-time data is versioned with the blueprint. Publishing a new version creates an immutable snapshot. Changes to the draft do not affect published versions.

Runtime data

Runtime data is created when an app is actually used within an organization. It is isolated per organization — no organization can access another's runtime data.

Component	What's stored	Scope
App instances	Installation state, blueprint version link	Per organization + space
Connections	OAuth tokens, API keys, credentials (encrypted)	Per organization + user
Collection records	Actual data rows in tables	Per organization + base
Conversations	Messages, threads, participant state	Per organization
Tasks	Execution history, inputs, outputs, errors	Per organization
Event subscriptions	Active listeners and webhook URLs	Per organization + app
Service accounts	Identity provider entries for apps and agents	Per organization
Knowledge base content	Uploaded documents, embeddings, vector index data	Per organization

How it works in practice

Consider a "CRM" blueprint installed by two different organizations:

Blueprint "CRM" (v2.3) — build-time
├── Integration: Salesforce REST API
│   └── Operation: listContacts
├── Agent: "Sales Assistant"
│   └── Flow: "Handle inquiry" → greet → lookup → respond
├── Collection schema: "Deals" (fields: name, value, stage)
└── Event Channel: webhook (Salesforce events)

────────────────────────────────────

Organization "Acme Corp" — runtime
├── App: CRM (linked to blueprint v2.3)
├── Connection: "Salesforce - [email protected]" (OAuth2 tokens)
├── Collection: "Deals" → 1,547 records
├── Service Account: "Sales Assistant" (Acme identity)
└── Conversations: 2,340 threads

Organization "Beta Inc" — runtime
├── App: CRM (same blueprint, different instance)
├── Connection: "Salesforce - [email protected]" (different tokens)
├── Collection: "Deals" → 283 records
└── Completely isolated data

Both organizations use the same blueprint definition — the same agent logic, the same flow structure, the same collection schema. But their data is completely separate: different credentials, different records, different conversations.

Why this matters

Safe distribution

Because build-time definitions contain no customer data, blueprints can be safely published to the marketplace and distributed to any organization. Installing a blueprint never exposes one organization's data to another.

Version management

Publishing a new blueprint version creates an immutable snapshot. Organizations using the previous version continue to work unchanged until they explicitly update. The new version can add features, fix flows, or modify schemas without disrupting existing installations.

Composability

Since all build-time definitions follow the same structure, blueprints can reference actions from other blueprints. A flow in one blueprint can call an action defined in another, enabling modular composition of capabilities.

Blueprints — the container for build-time definitions
Apps — how blueprints become runtime instances
Organizations and Spaces — the multi-tenant isolation model
Publishing and Distribution — how blueprints are versioned and shared

Build-time vs. Runtime Data

On this page