When a Semantic Node starts, it does not simply expose an API — it understands itself. The boot pipeline connects to the assigned datasource, runs an LLM introspection pass to understand domain and risk, generates a Capability Card, and broadcasts it to the Cortex Pulse so the rest of the network knows this node exists and what it can answer.
The Capability Card is the node's identity in the protocol. It declares: node_id, domain, entities, intents it can answer, datasource type, and exposure risk level. The Orchestrator and Knowledge Graph consume this card to decide routing.
The user types (or speaks, or sends) a natural language request. Cortex Brain invokes the configured LLM in streaming mode, receiving a structured SemanticAnalysis object as it resolves. This object carries intent, dataType, filters, requestedFields, suggestedUI, and confidence — all derived from language alone, without schema knowledge.
Intent values: display_list · visualize_data · monitor_dashboard · summarize_content · display_information · create_resource · configure_settings · execute_action
Data types: user · product · order · financial · workflow · event · generic
When the user's intent matches intent: natural_language, the CommandGenerator at the Semantic Node level takes over: the node's own LLM instance interprets the free-text query directly against its schema knowledge, generating a QuerySpec without any mapping table. This enables arbitrary natural language queries against any datasource.
The Orchestrator Node holds a live registry of every active node's Capability Card. When an intent arrives, it scores every registered node using a weighted matching algorithm across domain relevance, entity coverage, and intent compatibility. The highest-scoring node (or nodes, for fan-out) receives the query. There are zero hardcoded routing rules.
When a query spans multiple domains (e.g. "compare delivery vs support SLA"), the Orchestrator routes to multiple nodes simultaneously, collects their responses, and merges them before returning. No single node needs to know about the others.
Open Policy Agent (OPA) runs as a sidecar to each Semantic Node. When a query arrives, the node calls OPA before executing any SQL. The policy receives the identity claims (role, tenant, user_id), the operation type, and the requested entity. It returns allow/deny plus masked_fields — a list of fields to scrub from results. If OPA denies, the query never executes.
Policies are written in Rego — a declarative language that is reviewed, versioned, and auditable like code. The policy file at each node defines: which roles can perform which operations, which fields are sensitive per role, and which tenants can access which partitions of data. Policies cannot be bypassed — they run at the node perimeter, not in a middleware that can be routed around.
After OPA grants access, the Semantic Node executes the query against its local datasource. Raw data never leaves the node perimeter. What travels over the network is a structured result: an array of records, a count, a summary — all post-OPA scrubbing. The difference is fundamental: no raw data in transit means no interception, no accidental exposure, no compliance risk from the transport layer.
The MessageInterpreter translates an intent string (query_customers, list_products) into a QuerySpec — entity, action, filters, requested fields, limit. It follows the convention: verb_entity → action + entity. For complex free-text queries, the CommandGenerator generates the QuerySpec directly via LLM against the node's schema knowledge.
Cortex One is a streaming-first platform. No operation waits for a complete result before returning. Intent parsing streams token by token. The Semantic Node streams data in chunks. Every status event (policy result, query start, render type decision) reaches the browser as it happens. The user sees the system thinking in real time.
thinking — intent received, LLM query spec generation started
policy — OPA evaluation result: allow/deny, masked fields
query — SQL query starting on entity
chunk — batch of records: offset, records[], total
result — final: status, policy summary, records, count, summary
render — FluidRenderer trigger: renderType, schema, records, policy
Beyond direct SSE connections, all nodes communicate through Cortex Pulse — the platform's internal event backbone. Cortex Pulse carries boot announcements, capability card registrations, inter-node query routing, and session events. Every message on Cortex Pulse carries identity metadata — there are no anonymous signals in the network.
Cortex Pulse is the nervous system of the platform. It is a transport concern — the protocol does not expose which technology implements it, and the architecture is designed to allow swapping the underlying implementation without changing node code.
The Identity Node is the trust anchor of the platform. Every user authenticates once — via social login (Google, GitHub, Microsoft, LinkedIn, Slack) or password. The Identity Node issues a LaaP JWT: a signed token carrying laap_id, tenant_id, role, provider, and granted_datasources. This token travels with every request — to the Interaction Backend, through Cortex Pulse to the Semantic Node, and into the OPA policy evaluation. Identity is not bolted on — it is structurally present at every hop.
The LaaP JWT carries: sub (laap_id), tenant_id, role, provider (google/github/…), granted_datasources (list of node IDs this user has consented to), iat, exp. These claims are read by OPA at every Semantic Node — no additional lookup required.
Users can explicitly grant or revoke consent for each Semantic Node's datasource. The Identity Node stores these grants in the user profile. OPA policies can require node_id in granted_datasources as an additional condition — giving users fine-grained control over which nodes can answer queries on their behalf.
The Knowledge Graph Node maintains a continuously-updated digital twin of the entire platform. Every time a Semantic Node boots and publishes its Capability Card, the KG ingests it, indexes the entities and relationships, and makes them available for context-aware routing. The Orchestrator queries the KG to enhance routing decisions, especially for multi-hop or cross-domain queries.
When multiple nodes declare overlapping entity types (e.g., both a CRM node and an HR node declare customer), the KG builds a resolution index that maps each entity type to all nodes that can answer it, ranked by declared expertise. This enables the Orchestrator to make nuanced routing choices rather than simply picking the first match.
In production, no node reads credentials from environment variables. The Vault Node holds AES-256 Fernet-encrypted secrets. When a node needs a credential (API key, DB password, external service token), it sends a signed request to the Vault via the event backbone. The Vault validates the JWT, checks the requesting node's permission, and returns the decrypted secret in-memory. The secret is never written to disk, never logged, never transmitted in plain text.
Every secret access is logged: requesting node, secret name, timestamp, outcome. The audit log cannot be modified by the requesting node. This provides a complete chain of custody for every credential in the platform.
The Node Builder allows operators to spawn new Semantic Nodes at runtime — simply by providing a datasource path, an LLM configuration, and a node name. The Builder uses the Docker SDK to launch a pre-built Semantic Node container, injects the configuration, and streams the entire boot process back to the UI via SSE events. The new node self-registers with Cortex Pulse and becomes immediately available for routing.
Dynamically spawned nodes are assigned ports from the pool 8600+. The Node Builder tracks allocations and prevents collisions. Each spawned node announces its port and node_id in its boot card — the Orchestrator picks it up automatically.
Traditional UIs are built for specific data shapes — you design a table for this endpoint, a chart for that one. Cortex does the opposite: the FluidRenderer receives a render event (renderType, schema, records, policy) and assembles the right UI component automatically. The backend infers the render type from the response shape and the LLM's suggestedUI hint. The browser renders it without any pre-built template for that specific data.
create / configure → form — empty fields, action buttons
1 record → kv card — key-value grid with masking badges
≤ 6 records, numeric → metric grid — large numbers, trend indicators
suggestedUI: chart OR date+numeric columns → auto chart — bar or line
date columns, ≤ 20 records → timeline — chronological events
≤ 2 keys + name column → list — compact named items
else → table — sortable, paginated, masked fields highlighted
FluidTable — sortable columns, pagination (10/page), masked field badges
AutoChart — bar or line, auto-extracts numeric/label columns
MetricGrid — large metric cards, trend up/down indicators
RecordKV — key-value grid, masked fields shown as ░░░
RecordList — name + sub-field compact list items
TimelineView — date-sorted chronological events
DashboardView — metric cards + chart combined
To be a valid LaaP node, a service must:
1. Implement GET /health returning {status:"ok", node_id}
2. Publish a Capability Card to laap/nodes/{node_id}/boot on startup
3. Expose an execute endpoint accepting {intent, filters?, requested_fields?, limit?}
4. Enforce OPA policy before any data operation
5. Return a response containing {status, records, count, summary, policy}
laap/nodes/{node_id}/boot — capability card publication
laap/intent/{session_id} — parsed intent routing
laap/reply/{request_id} — result delivery
laap/session/{session_id}/events — browser session stream
laap/nodes/{node_id}/health — heartbeat channel
REST optimises for predictability — you know the endpoint, you know the schema, you know the response shape. This works perfectly when the consumer knows what data it needs and where it lives. LaaP optimises for intent — the consumer knows what they want but not where it lives. These are fundamentally different problems. LaaP does not replace REST; it provides the layer above it, where language is the interface and nodes are the routable knowledge units.
For decades, software architecture has been built around applications. Applications own users. Applications own sessions. Applications own data. Identity has always been a feature of an application — never a first-class participant in its own right.
This was sufficient when systems were isolated. When intelligence enters the picture — when nodes reason, decide, and act autonomously — the assumption breaks. Intelligent entities do not simply communicate. They interact. And to interact meaningfully, they must possess identity.
These five properties are distinct and non-interchangeable. A system can grant access without knowing who someone is. A system can know who someone is without trusting them. A system can understand language without reasoning about context. Future intelligent ecosystems require all five — simultaneously, structurally, natively.
A Trusted Identity is not an account. It is not a session. It is not a set of credentials stored in a provider's database. A Trusted Identity is a persistent, portable, contextual representation of a participant that exists independently from any application through which it interacts.
Identity must become:
A Trusted Identity may represent any autonomous participant within an intelligent ecosystem:
Identity does not begin complete. It accumulates. Every interaction adds depth — roles accepted, knowledge applied, relationships formed, expertise demonstrated, reputation earned. Over time, an identity becomes something richer than credentials.
This is Semantic Identity: an evolving representation of participation. Where a credential says who you are, Semantic Identity says what you are, what you have done, and what you have become through your interactions within the ecosystem.
Traditional architectures treat trust as a binary gate. You are authenticated or you are not. You have a token or you do not. This model is adequate for access control. It is entirely inadequate for intelligent collaboration.
Future intelligent systems must reason about trust at a far deeper level. They must understand not just who is interacting, but what they represent — and why they should be trusted in this specific context, for this specific interaction, at this specific moment.
Ownership of identity has historically defaulted to whoever built the system. The provider stores your profile. The application issues your session. The platform controls your reputation. This dependency is not a technical constraint — it is an architectural choice. And it is the wrong choice for intelligent ecosystems.
Language as a Protocol established that language is the universal interface between systems. Trusted Identity is its natural and necessary evolution. Language enables components to communicate. Identity enables participants to interact. Trust enables participants to collaborate. Together, they create the foundation upon which genuinely intelligent ecosystems can be built.
This is not an expansion of the LaaP vision. It is its completion. A protocol without trusted participants is a transport mechanism. A language without identity is noise. An intelligent ecosystem without sovereignty is a dependency. The three pillars together define what it means to build systems that are not merely functional — but genuinely intelligent, accountable, and sovereign.