Saem — Korean for a natural spring: scattered streams seep in, gather, and rise again as a wellspring of knowledge
An on-premises intelligence layer that sits on top of an organization's existing line-of-business systems, connects their scattered data into a single ontology, and lets you build and deploy grounded answers and widgets on top of it.
Status: early implementation — the first connector exists; nothing is published. The only code is one read-only connector (below). The rest of this README describes what saem is meant to be, not what it currently does, and the architecture and ADRs are still under active revalidation.
Business knowledge lives across several line-of-business systems (ERP, MES, CMMS, and others), and each system is complete only within itself. Questions answerable inside one system are already solved. The ones that are not are the questions that cross system boundaries.
How that gap is handled today, and where each approach breaks:
| Current approach | Where it breaks |
|---|---|
| People walk between systems and assemble the answer by hand | Cost scales with human time, and the result is never reused |
| BI and reporting dashboards | Only show the axes someone chose in advance; a new question means a new development request |
| Vector RAG chatbots | Get relational and structural questions (multi-hop, cross-system) plausibly wrong, and cannot show the path that produced the answer |
The third one is where saem sits — and that position is two separate statements.
Why it exists. An ontology contract raises accuracy and turns failure into an error rather than a plausible wrong answer. Refusing to answer without grounding is how that gets enforced; give it up and saem is an expensive RAG.
What is still empty. Sitting read-only on top of existing line-of-business systems, attaching grounding to every answer, and respecting source-system permissions — we have not found a product that does all three. That is an empty seat, not a proven advantage: of the three, the permission axis is still unsolved.
Re-checked 2026-08-24: newly released control-plane, agent-building, and MCP-integration features from several graph database and ontology-platform vendors were reviewed against this claim, across two passes. None of them alter it — the tools reviewed operate on data already loaded into their own managed store, with access scoped to that store's own accounts, rather than live, per-end-user delegated queries back to the original source systems that enforce that system's own row- and field-level permissions. This remains an observation to re-verify periodically, not a permanent fact.
Re-checked 2026-09-06: three further 2026 entrants — a cloud data platform's cross-source shortcut feature, an enterprise search assistant, and an ontology platform's MCP endpoint — each evaluate access against their own store or a mirrored copy of the source's ACL (a configured connection credential, an ACL mirrored at crawl time and evaluated at query time, the platform's internal permissions). None runs the query back to the source system as the end user. The seat is still empty. Re-check by 2026-12-06. A claim about who else is in the market is true on the day it is made and quietly stops being true afterwards; the date says when this one has to be looked at again rather than leaving "periodically" to whoever remembers. One thing the same review did establish: pass-through session credentials, constrained delegation and on-behalf-of flows are standard features of established data virtualization products, so the delegation this project assumes is an adoption, not an invention — with a documented cost, one connection pool per user, that the assumptions above now carry.
Explainability is non-negotiable, and it is enforced by the contract — not by a prompt.
A response is a structure of {claim, sources[], path[]}, and a claim with no sources cannot be
expressed at all. Natural language is a rendering of that structure. When a query returns
nothing, saem refuses without invoking the model. If a principle is non-negotiable, the format
must not be able to express a violation. This costs real coverage, real latency, and — deliberately —
synthesis: "defects on this line are trending up" is a claim that lives in no single record.
(Grounding here is that citation — an answer traceable to the source records it was read from.
It is not what LLM-based biomedical extractors call ontology-based grounding, the normalization
of a mention to a reference-ontology term id; saem does no such lookup, and "grounded" in these
documents always means "traceable to records".)
saem never writes to source systems. It is read-only. When something must be recorded, it goes into saem's own space, and that space is bounded by a reducibility rule: every ontology instance node must reduce to at least one source record. Nodes that unify entities across systems are references to several records, and concepts that exist only in the organization (a line, an equipment group, a crew) may exist only as groupings — they carry no facts of their own, and their grounding is their members. This is the data-model form of the same principle: no ungrounded answers, no ungrounded nodes.
saem does not reimplement authorization — but it enforces it at two points. What is materialized never passes through query-time federation, so delegating to the source system at query time alone would leave the relationship graph outside the permission model.
| Point | Covers | How |
|---|---|---|
| Materialization | Graph, indexes, embeddings | Materialized per group profile; instance edges inherit source-record visibility |
| Query | Record bodies | Federated with the asking user's own credentials; row- and field-level rules are enforced by the source system |
Edges by group, bodies by user. A documented residual: within a group, differences between individuals are not reflected in edge visibility — group partitioning narrows that exposure but does not eliminate it.
What grows is models, not code. Connectivity is limited to a small set of generic primitives. Growth happens through ontology assets — domain packs and mapping templates.
Hybrid data ownership, in three layers. saem materializes ontology structure and relationships; record bodies are federated at query time and are never materialized. Ownership of the original data stays with the source system. What is materialized is partitioned by visibility:
| Layer | Visibility |
|---|---|
| Type and relationship schema | Organization-wide |
| Instance edges | Inherit the source record's visibility |
| Indexes, graphs, embeddings | Built only within what the channel's scope permits |
Embeddings are the sharpest edge: they are derived from record content, so content crosses the boundary at materialization time — before anyone asks a question.
Build pipeline.
saem-agent channel surface
────────── ─────── ───────
knowledge scoping → access assignment → chat widget
(optional) users / groups saem-artifact widget
API-only (also the materialization (both call the agent API)
partition key)
The contract is the first-class output. A saem-agent is a contract, not a runtime — saem does
not build an agent loop. What that contract carries is the distinguishing part: a knowledge scope,
the grounding a claim must cite, and the authority the query runs under. How it is delivered is
not — saem owns an MCP server and the built-in chat surface consumes it through an MCP
client, but exposing an ontology over MCP is table stakes as of 2026 (see the re-check above:
every recent entrant does it). Read the protocol as the transport it is, not as the reason to
choose this. What it does buy is structural rather than aspirational: the built-in chat connects
over the same contract everyone else does, so "the built-in UI is a reference consumer" is a fact
about the wiring instead of a promise.
Ontology authoring combines standard domain packs, entity/relation proposals from Eyu (the LLM-assisted extraction and mapping engine, consumed — not built here), and human review. Changes flow as changesets through simulate → apply → rollback.
Model access goes through a single provider-neutral entry point, so saem runs fully on-premises against whatever inference an organization already operates — a local model farm or a hosted provider. Local inference is available out of the box, not required.
A connector reads one system that already exists and is owned by someone else, and hands
Eyu what it judges from: what the system declares about a subject
(Eyu's IStructureSource) and the records it holds (IRecordSample). The ports are Eyu's public
contract, not saem's, so a connector could be lifted out without being rewritten.
- One source per connector, read-only. A connector never writes, and never infers — entities and relations are Eyu's to propose from what it returns.
- Across the process boundary. A connector talks to its source over the source's own interface; it does not load the source's engine or read its storage.
Saem.Connectors.Formbase is the first: it reads a Formbase
instance over HTTP — a form type's declaration as declared structure, and its raw document stream as
records, so fields nobody has declared yet reach Eyu too. It needs Formbase 0.11.0 or later, the
first release that serves GET /formtypes/{type}/documents; an older instance is named as such
rather than answered with a bare status.
Where the instance is not the only Formbase on its PostgreSQL and MorphDB, pass its namespace
(new FormbaseConnector(http, formbaseNamespace: "…"), sent as Formbase-Namespace): a connector
pointed at the wrong host then fails with 404 instead of reading someone else's documents. The
namespace only checks which host answered — it does not keep data apart. Formbase hosts sharing one
PostgreSQL and one MorphDB need a schema and a project each (Formbase__Schema,
Formbase__MorphDb__ProjectId); hosts that differ only in namespace serve the same data.
dotnet test --solution saem.slnx
SAEM_FORMBASE_URL=http://127.0.0.1:8080 dotnet test --solution saem.slnx -p:IncludeFormbaseLiveTests=truesaem is self-contained and can also be integrated as middleware. All three modes are first-class:
- Standalone — an organization runs saem and manages and queries the ontology inside it
- Client-side widget embedding — a host application embeds saem's chat or
saem-artifactwidgets - API / MCP only — a host application brings its own UI and uses saem as a knowledge provider
- Not an app builder. saem does not author domain entities of its own
- Not a write path. It does not write back to source systems; acting is the consuming system's job
- Not a BI or reporting dashboard. It shows relationships, not figures
- Not an agent runtime. The loop, session handling, and compaction belong to the agent host
- Not a workflow execution engine
- Not an ETL platform, and not an LLM training tool
saem-agent — a contract: a knowledge scope, the set of MCP tools it exposes, and the response
contract. API-only.
saem-artifact — a deployable unit produced by the builder: an ontology contract binding,
zero or more generated UI units, and surface configuration.
Two name collisions, one strategy.
vivariumusesartifactfor a single generated UI unit, and bothvivariumandironhiveuseagentfor things asaem-agentis not — a changeset-authoring harness and an execution engine, respectively. Asaem-artifactcontains vivarium artifacts; asaem-agentis a different category altogether (data, not a runtime). The prefix keeps them apart in both cases.
Chat is a built-in capability, not a saem-artifact. What gets built is a chat instance with a
particular knowledge scope.
- Eyu — the ontology inference engine; saem hands it declared structure and raw records, and materializes what it proposes
- Formbase — integrated at the container boundary, not as an SDK reference; it stores what saem materializes
- vivarium family — sandboxed UI runtime and the changeset lifecycle
- iron-prow — provider-neutral inference gateway
- lm-supply — local inference, available by default
Two further pieces are consumed as libraries rather than built here: agent hosting (the loop, session handling, and the MCP client that the built-in chat surface runs on) and hybrid retrieval (vector plus keyword search over what saem materializes). The specific packages are not pinned in this README yet.
AGPL-3.0 with a commercial license available. External contributions require a CLA. saem does not take external AGPL/GPL dependencies.