Latence Framework¶
Turn messy, siloed enterprise data into high-quality, AI-ready data — model-agnostic and cloud-agnostic.
Latence is a pipeline framework that takes documents from where they live (a folder, an object store, a source system) all the way to two portable, AI-ready deliverables: a RAG-ready corpus and a knowledge graph, both written as files (ADR-0017). It defines the stack and orchestration contracts; the concrete models and infrastructure are the adopter's choice.
- Model-agnostic. The framework never names a model. It names Capabilities —
narrow, typed interfaces like
Parser,EntityExtractor,PIIDetector— and lets Providers (an in-process model, a remote endpoint, a cloud service) fulfil them as plugins. See Capability protocols with provider plugins. - Cloud-agnostic. Storage is an fsspec seam; the
same Pipeline runs on a laptop or as an Airflow DAG through a swappable
Runner. Two Runners ship today — the
built-in local one and
latence-runner-airflow; other substrates (Databricks Workflows, plain containers) are seam-compatible follow-ons, not shipped adapters. - CPU-first, offline by default. Every Stage ships a deterministic, dependency-light reference Provider that runs on a laptop with no GPU and no network (ADR-0007). GPU serving is an upgrade path, not a prerequisite.
- Honest about licensing. Reference Providers ship permissive weights only;
restricted-license models are opt-in (ADR-0012).
Every Provider declares a
ProviderProfilewith its verified weights-and-code license, compute, and footprint.
The pipeline at a glance¶
That is the spine the blessed GPU stack declares (stacks/gpu-sota.yaml). Three further
Stages are optional and inert unless a stack declares them — Schema Induction
(ADR-0038),
Type Consolidation
(ADR-0054)
and Context Enrichment
(ADR-0039)
— and embeddings are an opt-in Export augmentation rather than a Stage of their own
(Embedders). Pipeline Stages documents each of them,
with what it consumes and produces.
A Pipeline is a DAG of Stages over a set of input documents, declared once and executable by any Runner. Every record at every Stage carries immutable Provenance back to its source, and each run emits a first-class Quality Report.
Find your reading path¶
Four kinds of reader arrive here. Each path below is ordered — follow it top to bottom and you should not need to hunt for anything else.
You want to know whether the claims hold before spending a day on it.
- Messy data to knowledge-graph retrieval — a deep dive — the long-form argument: what happens at each step, and why fusing a knowledge graph into retrieval answers questions dense and lexical search structurally cannot.
- Concepts & Architecture — the five load-bearing concepts (Capability, Provider, Stage, Runner, Storage) and where the seams are.
- Pipeline Stages — the contract of every Stage, Source through Export.
- Public benchmark results — measured numbers, each carrying its dataset, hardware and measurement date. A Stage with no section there has not been measured; that is stated, never implied by silence.
- Provider catalog — every shipped Provider with its compute, footprint and verified weights-and-code license.
- Threat model · Continuity & security process · SBOM & supply chain — the procurement answers, each claim pointing at the artifact in the repository that proves it.
You want a corpus and a knowledge graph out of a folder of documents.
- Getting Started — install,
latence setup,latence process, and what lands in the output directory. - Run & validate a stack — the blessed stacks and
latence stack validate. - Read the results — the run console — one command, a localhost page, a quality verdict a non-engineer can act on.
- Tune a stack per device —
latence tuneprofiles the actual box and keeps only settings that do not change output. - Deploy (Compose · Helm · air-gapped) · Observability · Secrets handling — what production asks for.
- Going deeper: the fresh-pod walkthrough drives the full GPU stack stage by stage, and Run a bake-off picks a Provider on evidence rather than reputation.
You want the framework to use your model, endpoint or cloud service.
- Concepts & Architecture — what a Capability is, and why a Provider needs no base class and no import of core to satisfy one.
- Authoring a Provider — the end-to-end path: implement one method, declare a profile, register an entry point.
- Writing an adapter with
AdapterBase— the optional helper that factors out device selection, batching and error mapping. - ProviderProfile & device handling — the typed descriptor the framework routes device selection from.
- Passing Provider Conformance — the C1–C6 checklist that is the definition of enterprise-ready here, and the gate every adapter package passes.
- API Reference — the contracts, protocols and error taxonomy you program against, autodoc'd from the source.
You want to change the framework itself, or to understand why it is shaped this way.
- Decision Log (ADRs) — the authoritative source. Every seam has a record with the context, the choice, and the alternatives rejected.
- Releasing — one version across every publishable distribution, and the gate that must be green before a tag.
- Continuity & security process — how vulnerabilities are handled, and what happens if the maintainer stops.
CONTRIBUTING.mdin the repository root — the local dev loop, the merge gate, and the doc-truth tests that fail the build when a page drifts from the code.
Browse by section¶
-
Get started Install, run, and read the results.
-
Concepts & architecture Capability / Provider / Stage / Runner / Storage, and every Stage's contract.
-
Providers The catalog, the authoring guide, and the conformance gate.
-
Guides Operate, tune, deploy, benchmark, and feed a retrieval engine.
-
API reference Contracts, protocols, Runner, Storage and errors, autodoc'd from source.
-
Decision log The 65 architecture decisions behind the framework.
What the repository actually contains¶
| Packages | 33 distributions under packages/ — one thin core plus one package per Provider family (ADR-0016). |
| Decisions | 65 architecture decision records in docs/adr/, numbered 0001–0066 (0040 was never issued). |
| Runners | Two shipped: the built-in local Runner and latence-runner-airflow. |
| Deliverables | A RAG corpus and a knowledge graph, as files — Parquet, JSONL, TTL, GraphML (ADR-0017). |
Install¶
Nothing is published to PyPI — the distribution channel is the signed GitHub Release (ADR-0062, whose rationale is superseded and whose decision is reopened, not reversed, by ADR-0063). You install from a clone:
git clone https://github.com/ddickmann/latence
cd latence
uv sync
# Providers are separate packages — add only what a stack needs, by path, e.g.:
uv pip install -e packages/latence-parser-pdfplumber # CPU PDF parser
uv pip install -e packages/latence-ner-gliner # learned zero-shot NER
uv sync installs the dependency-light core — contracts, Capability protocols, Pipeline,
local Runner, Storage and the latence CLI — plus the CPU-first, offline default set. The
core has near-zero dependencies (ADR-0016):
pydantic, fsspec, pyarrow, pyyaml, typer. Heavy model stacks live in their own
Provider packages, so the core stays lean. Step-by-step: the
quickstart.
Project status
Latence is a personally-owned, open-source framework licensed under the
Apache License 2.0; commercial use is
granted by the licence and needs no agreement
(COMMERCIAL.md).
Ownership and the personally-owned posture are unchanged
(ADR-0001). See the
README for the marketing overview,
and the Decision Log for the reasoning behind every seam.