Core concepts

Before using Loambase Foundry, understanding the following core concepts will help you build applications more effectively. The platform’s model revolves around the logic chain of “data integration → data processing → semantic mapping → action execution”.

1. Datasource

Definition: a physical connection configuration for interacting with an external system — the entry point for all data flowing into the platform.

• It stores no data itself; it only keeps connection credentials and network reachability.
• Supported types include relational databases (MySQL, PostgreSQL), message queues (Kafka), file systems (S3), and third-party REST APIs.
• The platform encrypts sensitive fields such as passwords at rest.

2. Dataset

Definition: the smallest unit of data storage on the platform (a physical table, or a collection of files). Datasets are the only input and output objects of data processing pipelines.

Depending on their lifecycle on the platform, there are two kinds:

• Raw dataset: data synced directly from external systems through a datasource, exactly as-is.
• Derived dataset: a higher-quality dataset produced by platform pipelines (cleansed, transformed).

Either way, every dataset is abstracted into a unified schema (STRING, INTEGER, TIMESTAMP, …), hiding the differences of the underlying storage engine.

3. Pipeline & transforms

Definition: a pipeline is the logical orchestration of data transformation and processing, abstracted on the platform as a directed acyclic graph (DAG).

• Nodes: the nodes in the graph are datasets (input or output).
• Edges: graph edges or intermediate compute nodes are called transforms.
• Transforms define the concrete compute logic, e.g. native SQL queries, filtering, joins, aggregation.

Pipelines can run manually, or be scheduled with CRON expressions. After each successful run, the version number of the output dataset increments automatically.

4. Ontology (semantic layer)

Definition: the ontology is a higher-level abstraction of data — the semantic layer end users explore in a graph view and build applications on top of.

It maps the cold datasets underneath to real-world entities business users understand directly. The ontology consists of three main parts:

4.1 Object types

Define a class of business entity, e.g. “Employee”, “Order”, “Factory”.

• Every object type maps to an underlying high-quality dataset.
• You must designate one column from the dataset as the unique primary key of the ontology object.

4.2 Properties

Define the properties of an object type, mapping dataset physical columns to business attributes.

• For example, physical column first_name maps to business attribute employee_name.
• You can configure whether a property may be used as a filter condition for global search.

4.3 Link types

Define associations between object types — the edges of the knowledge graph.

• For example: a belongs_to relation from source object type “Employee” to target object type “Department”.
• Relations support ONE_TO_ONE, ONE_TO_MANY and MANY_TO_MANY cardinality configuration.

5. Actions

Definition: the ontology solves data “read” and “association”; actions solve data “write” and “business validation”.

• An action is not a bare database UPDATE/INSERT statement — it is an operation with business semantics (e.g. “approve a leave request”, “update an order status”).
• Actions support strongly-typed input parameters and pre-condition validation rules, and every operation is recorded in the system audit log.
• This is also the safest, most controlled entry point (Tool) when LLM agents interact with business systems.