Architecture

Loambase Foundry is designed in layers around data integration, semantic modeling, agent runtime and governance. This document is for platform administrators and developers — covering the overall logical layers, data flows, and the security isolation design.

1. Core architecture layers

From the underlying data up to the top-level applications, the platform is strictly organized into four layers:

1. Data integration layer Extracts data from internal and external sources (MySQL, PostgreSQL, APIs, Kafka, etc.) into the platform. Supports CDC (change data capture) real-time sync as well as scheduled batch sync.
2. Lakehouse & compute layer The powerful foundation that handles massive-scale data processing.
   • Unified storage (Apache Iceberg): datasets are stored on the open Iceberg table format, which provides ACID transactions, schema evolution, and time-travel queries at scale.
   • Compute engines (Flink & Spark): DAG pipelines are routed automatically by workload characteristics — high-throughput offline cleansing/aggregation is scheduled onto Apache Spark, while real-time streams with millisecond latency are pushed down to Apache Flink.
3. Ontology/semantic modeling layer Maps the physical Iceberg tables underneath into business-understandable ontology objects, providing object-oriented graph queries, link navigation, and business action definitions.
4. Application & analytics layer Provides the ontology-based application builder (App Builder) for end users, plus the developer-facing SDK layer (React / Agent SDK).

2. Data flow and control flow

In Loambase Foundry, the data flow and the control flow are cleanly separated:

• Bottom-up data flow: data enters the platform from external databases, is cleansed through pipelines into derived datasets, and is finally mapped into ontology objects rendered on frontend pages. This is a pure “read” path, keeping the underlying data safe.
• Top-down control flow: frontend apps and LLM agents can never execute UPDATE or DELETE statements against the underlying databases. Every “write operation” must go through a business action defined on the ontology layer. Only after the platform’s unified permission check and audit does the change get committed.

3. Security, isolation and observability

As an enterprise platform, Loambase Foundry builds strict security and governance into the architecture:

3.1 Identity & multi-tenancy

• OIDC integration: the platform supports standard OIDC providers (Keycloak, Auth0, etc.) for enterprise SSO.
• Tenant isolation: domain-based multi-tenancy fully isolates data, ontology models and application assets between tenants, physically or logically.
• Workspaces: within one tenant, you can create multiple workspaces and control member access to specific datasets or apps with fine-grained RBAC.

3.2 Data lineage

• Lineage tracking is built in. When a property of an ontology object changes, or a chart on an app page looks wrong, the lineage graph traces it back to the pipeline transform that computed it and ultimately to the originating external table.

3.3 Audit & logs

• Every call across the architecture layers — external API triggers, Agent SDK tool calls, actions fired from App Builder — goes through the API gateway and is written to the audit log, so “who changed what, and when” is always traceable.

4. Extensibility & open interfaces

The platform is not a closed black box — every key layer exposes open capability:

• Datasource extensions: implement the standard connector interface to onboard custom external sources quickly.
• UI component extensions: in the App Builder layer, developers can register and upload custom React rendering components.
• APIs & webhooks: when data changes or actions fire on the ontology layer, event notifications can be sent to external business systems via webhooks.