Platform Core
The operating system kernel of the SERGENTA AI platform. Invisible to end users, essential to everything above it.
Overview
What is Platform Core?
Platform Core is the foundational layer of BIOS™. It provides the runtime environment, entity system, authentication context, and infrastructure primitives that every other module — Orchestrator, AI Runtime, Memory, Knowledge Hub — builds upon.
Think of it as the kernel of an operating system: end users never interact with it directly, but every application, every agent, and every integration relies on its contracts. When the kernel is stable, everything above it can evolve independently. When the kernel is fragile, every change cascades.
Platform Core enforces four invariants across the entire platform: a unified entity model, an authenticated execution context, an immutable audit trail, and tenant-level isolation. These are not features — they are preconditions for enterprise-grade AI.
Business Value
Why It Matters
Enterprise AI systems fail not because of model quality, but because of infrastructure fragility. Platform Core exists because without a stable foundation — consistent data models, authentication boundaries, audit trails and tenant isolation — every AI feature becomes a liability instead of an asset.
Business Challenges Addressed
Fragmented data models across teams — every feature reinvents entity definitions, causing integration failures and schema drift.
No consistent authentication or access control — API keys are passed around, security is bolted on after the fact.
Customer data leaking between tenants because isolation was never designed, only retrofitted.
Compliance requirements unmet by ad-hoc architecture — audit trails are afterthoughts, not structural properties.
Business Outcomes
Faster time to market — teams build features, not infrastructure. Auth, audit and multi-tenancy are inherited.
Lower maintenance cost — one schema, one auth model, one audit system. Changes are made once, not per-module.
Compliance by default — audit trails, access control and data isolation are built into the runtime.
Reliable multi-tenancy that enterprise customers require before signing contracts.
Departments That Benefit
The Problem
The Problem
Enterprise AI systems fail not because of model quality, but because of infrastructure fragility. Teams building directly on LLM APIs encounter the same structural problems every time.
No consistent data model — every feature reinvents entity definitions, leading to schema drift and integration failures.
No authentication boundary — API keys are passed around, access control is bolted on, and audit trails are afterthoughts.
No multi-tenancy — customer data leaks between tenants because isolation was never designed, only retrofitted.
No idempotency — retries create duplicate records, side effects compound, and the system becomes unpredictable under load.
The Solution
The Solution
Platform Core provides these primitives as a unified, contract-first layer. Every module communicates through the same entity model, the same auth context, and the same audit infrastructure.
Contract-first entity system — every data object has a JSON schema, validated at every boundary. Malformed data is rejected before it reaches the logic layer.
Authenticated execution context — every operation carries the identity, role and tenant of the caller. Access control is enforced by the runtime, not by application code.
Immutable audit trail — every read, write and administrative action is logged with timestamp, actor and diff. Compliance is a property of the system, not a report.
Tenant isolation — row-level security ensures that data from one workspace never leaks to another. Isolation is enforced at the database level, not the application level.
Architecture
Architecture
Platform Core is structured as five layers, each with explicit boundaries and contracts. Components communicate vertically through interfaces, never bypassing a layer.
Architecture Layers
API Gateway
REST and WebSocket endpoints, rate limiting, request validation
Identity & Access
Authentication, role-based access control, tenant resolution
Service Runtime
Function execution, background jobs, event bus, real-time subscriptions
Entity Layer
Schema-validated data model, CRUD operations, query engine, relationships
Infrastructure
Storage, compute, networking, secrets management, observability
How It Works
How It Works
Process Flow
Request arrives
An API request hits the Gateway with an authentication token. The Gateway validates the token, resolves the tenant, and enforces rate limits before the request enters the runtime.
Identity resolution
The Identity layer extracts the caller's user ID, role and workspace from the token. This context is attached to the request and propagated to every downstream operation — no function needs to pass it manually.
Entity operation
The request is routed to the appropriate entity handler. The Entity layer validates the payload against the schema, enforces row-level security, and executes the operation within the authenticated context.
Audit capture
Every state-changing operation generates an audit record: who, what, when, before, after. The record is written to an append-only log that cannot be modified or deleted.
Real-time propagation
If the operation modifies data that clients are subscribed to, the Entity layer emits a real-time event. Subscribed clients receive the update within milliseconds.
Benefits
Why It Matters
Business Benefits
Faster time to market — teams build features, not infrastructure. Every new module inherits auth, audit and multi-tenancy for free.
Lower maintenance cost — one schema, one auth model, one audit system. Changes are made once, not per-module.
Compliance by default — audit trails, access control and data isolation are built into the runtime. Compliance is structural, not procedural.
Technical Benefits
Contract-first APIs — the interface is the contract. Breaking changes are detected before deployment, not after.
Schema validation at every boundary — malformed data never propagates. Debugging starts from 'this can't happen', not 'how did this happen'.
Row-level security — tenant isolation is enforced by the database, not by application code. A bug in a query cannot leak data across tenants.
Idempotent operations — every action is safe to retry. Duplicates are prevented by design, not by convention.
Technical Deep Dive
Technical Deep Dive
01Entity Model
Every data object in BIOS™ is an entity — a JSON-schema-validated object stored in a document database. Entities have built-in fields (id, created_date, updated_date, created_by_id) and custom fields defined by the schema. The schema is the single source of truth: the database, the API, the SDK and the UI all derive their types from it. When the schema changes, the platform validates existing data against the new schema before the migration is applied.
// Entity schema example
{
"name": "Lead",
"type": "object",
"properties": {
"project_name": { "type": "string" },
"status": {
"type": "string",
"enum": ["Neu", "Validiert", "Kontaktiert", "Abschluss"],
"default": "Neu"
},
"opportunity_score": { "type": "number", "default": 0 }
},
"required": ["project_name"]
}02Row-Level Security
Multi-tenancy is enforced at the database level through row-level security (RLS). Every entity record carries an implicit tenant identifier derived from the authenticated context. Queries are automatically scoped — a user in Workspace A physically cannot read records from Workspace B, because the database enforces the filter before returning results. This is not application-level filtering; it is a database-level guarantee.
03Audit Trail
Every state-changing operation — create, update, delete — generates an immutable audit record. The record contains the actor's identity, the timestamp, the entity affected, and a structured diff of the changes. Audit records are append-only: they can be read, but never modified or deleted. This satisfies SOC 2, GDPR and ISO 27001 audit requirements without additional instrumentation.
FAQ
Frequently Asked Questions
Each workspace is an isolated tenant. Data isolation is enforced at the database level through row-level security — not through application-level filtering. A query executed in Workspace A physically cannot return records from Workspace B.
Platform Core is designed for cloud deployment. The runtime, entity layer and real-time infrastructure are managed services. For on-premise or air-gapped requirements, contact our engineering team to discuss deployment options.
The entity layer uses a document database (MongoDB-compatible) as its primary store. File storage uses object storage (S3-compatible). The platform abstracts these — your code interacts with entities and files, not with database drivers.
Through row-level security at the database level. Every query is automatically scoped to the caller's tenant. This is a structural guarantee, not a convention — a bug in a query cannot leak data across tenants because the database itself enforces the filter.
Schema migrations are validated against existing data before deployment. If the new schema is incompatible with stored records, the migration is rejected. This prevents the most common production incident: a schema change that breaks existing data.
Want to see Platform Core in action? Explore how enterprises use BIOS™ to build production AI systems.