How Lymis works

One sovereign platform between your data and your AI.

Lymis discovers sensitive data wherever it lives, maps who — and which AI — can reach it, and governs that access from a single control plane. Collection and classification run at the edge, next to the data; only compact evidence and decisions move. Nothing crosses the customer boundary.

Platform · Python / FastAPI Risk graph · PostgreSQL File collector · Rust M365 collector · Python Console · React / TypeScript Deploy · Docker / Compose
System

The whole platform runs inside one boundary.

Every component — sources, collectors, classification, control plane, store and console — sits inside the customer's environment. Data flows up as evidence, never as content.

Customer boundary · on-prem / air-gapped
Data sourcesread-only · agentless or agent-based
File sharesSMB · NFS · object
SharePoint+ OneDrive
Exchangemailboxes
DatabasesPostgreSQL · MSSQL
IdentityEntra ID · AD
AI & SaaScopilots · RAG · vector stores
Collection layer · runs at the edge, next to the datastateless · horizontally scalable
File collectorRust · Tokio async · full + delta walks · local fingerprint & classify
M365 collectorPython · SharePoint / OneDrive / Exchange / Entra · content + access graph
Database collectorper-column sampling · classify representative samples, not every row
Classification cascade · the scale enginethreshold-gated · tiered cheap → expensive
Deterministicregex · rule · reference lists
StructuralNER · fingerprint · EDM · validators
Semanticembeddings · small language model
Coverageper-source, per-engine completion
Platform core · control planePython · FastAPI (async) · ~440 REST routes · stateless app tier
Ingest APIevidence intake
Risk graph builderresolve & link
Policy engineABAC decisions
AI reachabilityblast radius
Remediationprioritise · route · verify
Complianceevidence packs
Risk graph & evidence storePostgreSQL · versioned schema
One unified modeldata assets · classifications · identities · groups · policies · applications & AI systems · access paths · classifier evidence & fingerprints · audit
ConsoleReact · TypeScript · Vite · Tailwind
Exec posturescore · next actions
Exposurewhere & who
AI governancereachability
Access reviewscampaigns · SoD
Detectioncases · MTTR
Privacy & reportsDSAR · RoPA · evidence
→ crosses the boundary Decisions, remediation plans and compliance evidence packs only. Derived artifacts — operator-controlled. Source content and raw records never leave.
Why it scales

Classification is a cascade, not a brute-force scan.

The expensive engines never run on everything. Cheap deterministic passes filter the field first; structural and semantic engines only ever see what survives. Run next to the data, this is what lets one platform classify petabyte-scale estates on commodity hardware.

All data — the full estate, petabyte-scale
every object
Tier 1 · deterministiccheap · runs on 100%
Pattern & reference
regex · built-in rules · reference lists — high recall, near-zero cost
candidates only — a few %
Tier 2 · structuralmedium cost
Validate & match
NER · fingerprint · exact-data-match · checksum validators
survivors only
Tier 3 · semanticexpensive · runs on a sliver
Understand meaning
embeddings · small language model — context & business meaning
every engine gated by a calibrated confidence threshold
Evidence, not contentdata class · confidence · fingerprint
01

Cascade filtering

Each tier hands only its survivors to the next. The GPU- and model-bound work touches a fraction of a percent of the estate — cost scales with sensitive data, not total data.

02

Sampling

Large stores — databases, big repositories — are classified by representative sample and extrapolated, rather than read byte-by-byte.

03

Edge execution

Classification runs in or beside the collector, where the data already is. Grams of evidence move upward; terabytes of content never do.

04

Horizontal collectors

Throughput scales by adding stateless collectors per source, site or region. The control plane and graph scale independently behind Postgres.

05

Precision & coverage

Threshold gating keeps each tier from wasting the next on noise, and honest per-source / per-engine coverage shows exactly what's been classified and by which tier.

Components

What each part is, and what it runs on.

CONTROL PLANE

Platform core

The async API that ingests evidence, resolves and links the risk graph, runs the ABAC policy engine, computes AI reachability and blast radius, drives remediation, and generates compliance evidence. Stateless app tier — scale out behind the database.

PythonFastAPI · async~440 REST routes
STATE

Risk graph & evidence store

One model of data, identities, groups, policies, applications, AI systems and the access paths between them — plus classifier evidence, fingerprints and audit. The single source of truth every surface reads from.

PostgreSQLversioned schemagraph + evidence
COLLECTION

Collectors

Edge workers that read sources read-only, classify and fingerprint locally, and ship compact evidence over mTLS. A high-throughput Rust agent for file systems; a Python collector for Microsoft 365 and identity; sampling collectors for databases.

Rust · TokioPython · M365mTLS
INTELLIGENCE

Classification engines

A library of engines — pattern, reference, NER, fingerprint, exact-data-match, embedding and small-language-model — arranged as a tiered cascade. Each emits a hit only above its calibrated confidence threshold, keeping precision high and the pipeline cheap.

regex · rule · EDMembedding · SLMthreshold-gated
PRESENTATION

Console

The operator and executive interface: posture and next-best-actions, exposure and reachability, AI governance, access reviews, detection & response, and privacy and reporting — one view over the API, entirely inside the boundary.

ReactTypeScriptVite · Tailwind
DEPLOYMENT

Runs in your environment

Containerised and self-contained, with no outbound dependency required. Deploys on-prem in a customer VPC, a private datacentre, or a fully air-gapped enclave — the same platform in every case.

Docker / Composeon-premair-gapped
The boundary

What moves — and what never does.

The architecture is built around a single rule: content stays where it is; only evidence and decisions travel.

Never leaves the source

  • File, object and mailbox content
  • Full database records or raw PII
  • Any telemetry to a vendor cloud

Stays inside the boundary

  • Fingerprints & classifier evidence
  • The risk graph & access paths
  • Policy decisions & audit

Can cross — operator-controlled

  • Executive decisions & posture
  • Remediation plans
  • Compliance / evidence packs
Deployment

One artifact set — from a single enclave to an HA cluster.

The same containers deploy as an all-in-one node for a pilot or air-gapped enclave, or as a replicated cluster for production. Stateless tiers scale out; the database scales with replicas; collectors scale with the data.

Customer boundary
Access tierTLS termination · single entry point
Operatorsbrowser · SSO
Reverse proxy / load balancerTLS · routes to app tier
Consolestatic build · served here
Application tier · statelessscale outPython · FastAPI
API replicas×Ncontrol plane · REST
Async workers×Nscan & classification orchestration
Ingest endpointcollector evidence over mTLS
Data tier · statefulPostgreSQL
PostgreSQL · primaryrisk graph + evidence
Hot standbystreaming replication · failover
Read replicareporting · optional
Collectors deploy per site or segment and connect inbound to the ingest endpoint over mTLS — they scale with data volume and source count, independently of the core.
pilots · air-gapped enclaves

Single node

The whole platform via Docker Compose on one host — API, workers, PostgreSQL and console together. Ideal for proofs of value and isolated enclaves with no moving parts to operate.

production

HA cluster

API and workers replicated behind the load balancer; PostgreSQL primary with a hot standby and optional read replica; collectors distributed across sites. No single point of failure in the application tier.

DeploymentData estateTopologyAPI / workersPostgreSQLCollectors
Pilot / enclaveup to ~10 TBsingle node (Compose)1 / 1single instance1–2
Standard~100s TBHA cluster2–3 / 2–3primary + standby3–10 across sites
Large / multi-sitepetabyte-scaleHA · multi-sitescale-outprimary + standby + read replicatens, sharded by site

Sizing figures are illustrative reference points to show how the architecture scales, not hard limits or benchmarks.

Trust model

Built to run in the room with your most sensitive data.

Because Lymis sits inside the boundary, the security model is the product. Access is least-privilege, every component authenticates, evidence is signed, and nothing phones home.

IDENTITY & ACCESS

Operators

  • SSO through your identity provider (OIDC / SAML)
  • Local accounts for fully air-gapped enclaves
  • Least-privilege RBAC — administrator, analyst, approver, auditor (read-only)
  • All access scoped to a tenant
COMPONENT TRUST

Collectors

  • Per-collector identity, enrolled with a signed token
  • Authenticated by mutual TLS to the ingest endpoint
  • Read-only access to sources; revocable at any time
  • No inbound ports opened on the data sources
DATA PROTECTION

In transit & at rest

  • TLS / mTLS between every component
  • Volume encryption at rest for the database and evidence
  • Secrets sourced from the host secret store
  • Only fingerprints and evidence persist — never source content
KEY HANDLING

Signing & integrity

  • Evidence signed with a per-tenant key
  • Keys generated and held inside the boundary
  • Keys never leave the customer environment
  • Rotation supported without re-scanning
AUDITABILITY

Provable, append-only

  • Append-only audit of actions and approvals
  • Access-review decisions and case notes recorded
  • Tamper-evident fingerprints on evidence
  • Exportable evidence packs for regulators
AIR-GAP POSTURE

Nothing phones home

  • No outbound network dependency
  • No vendor telemetry or usage beacons
  • No license phone-home
  • Updates delivered as signed offline bundles

Protocol and policy specifics — IdP type, session lifetime, rotation cadence and exact role names — are the target control model and should be confirmed against the current build before formal diligence.

Data flow

One scan, end to end.

From an operator triggering a scan to a governed decision — the only thing that ever moves upward is evidence.

1
Console

Trigger

An operator runs or schedules a scan of a source.

2
Platform

Dispatch

The control plane assigns the job to the collector responsible for that source.

3
Edge collector

Read

The collector connects read-only and walks or samples the source — async file walks for shares, per-column sampling for databases.

4
Edge collector

Classify

Each object or sample runs the local cascade: deterministic → structural → semantic, every hit gated by a calibrated confidence threshold.

5
Edge collector

Evidence

Produces a fingerprint, data class, confidence and metadata, then signs it. The underlying content stays at the source.

6
Edge → Platform

Ship

Evidence streams to the ingest API over mTLS; progress heartbeats keep the job observable.

7
Platform

Persist

The signature is verified; assets, verdicts and coverage are written to the risk graph.

8
Risk graph

Link

Assets are resolved against identities, groups, policies, applications and AI systems; exposure and AI reachability are computed.

9
Policy engine

Evaluate

The ABAC engine flags overexposure, toxic combinations and what AI can reach, producing findings and next-best-actions.

10
Console

Surface

Posture updates; cases and remediation are created; evidence is ready for compliance — all inside the boundary.