Skip to main content

Knovaryn — every training example, traced to its source. The Tracemark mark beside the name; a strip shows source spans converging through a quality gate into verified dataset rows; caption: MCP-native, open source, Apache-2.0.

Knovaryn is an open-source, self-hosted, MCP-native training-data foundry: it turns permitted PDFs and documents into traceable, quality-gated SFT, DPO/preference, KTO, and evaluation datasets that any MCP-capable agent can build, review, and export.

Every training example, traced to its source. Each exported row is linked to persisted source evidence, quality decisions, review state, version metadata, and a reproducible release bundle — so you can walk any example back to the page, section, or chunk it came from, and prove it.

Status: self-hosted open-source alpha (0.2.2). You run Knovaryn on your own machine or infrastructure — there is no hosted service. The bundled demo runs entirely offline on a deterministic fake provider: no API keys, no network. Live model generation is an explicit opt-in. Maturity and limitations are listed honestly below.

PyPI version Python versions CI status Documentation MCP SDK compatibility: 1.x and 2.x, acceptance-tested License: Apache-2.0 Security policy Release status: alpha (0.x line)

Start here: install from PyPI · run the offline demo · read the quickstart · connect an MCP client · view the documentation · inspect an example release · contribute


Why Knovaryn

Applied-LLM teams generate "N examples" with no way to show where an example came from, whether it is any good, or whether the source was usable at all. Knovaryn treats evidence and acceptance decisions as first-class data:

  • Provenance is enforced, not decorative. Every accepted example carries source_document_ids, source_span_ids, and a content_hash; exports are blocked if a reference cannot be resolved to real evidence.
  • Quality gates fail closed. Candidates are scored against a dated acceptance policy; failures are quarantined with reason codes — never silently exported.
  • Expensive work is durable. Jobs run on leased workers with heartbeats, checkpoints, and idempotency keys — a crash resumes instead of redoing paid work.
  • MCP is the primary interface. 23 typed tools mirror the CLI verbs; any MCP-capable agent can drive the whole pipeline. The tool surface is tested against both MCP SDK major lines (mcp>=1.28,<3).
  • Local-first, team-ready. SQLite + filesystem by default; PostgreSQL + S3-compatible storage is a configuration change, not a code fork.
  • Honest by construction. Quality is measured relative to a policy and corpus; the claim matrix ties every public claim to evidence and known limitations.

Compared factually with related tools in the peer landscape.

How it works

Pipeline flow: source documents are ingested, parsed, split and chunked, then a generation plan produces candidates that are validated by quality gates, reviewed, versioned, and exported as trainer-ready datasets with provenance

Everything runs as durable jobs; the full diagram set (system architecture, durable jobs, MCP session, security, value) is in architecture at a glance.

Install

One command, no API keys, no network needed to get started:

pip install knovaryn

From source (for development):

git clone https://github.com/waalwalker1/knovaryn.git
cd knovaryn
uv sync --extra dev

Optional extras are opt-in: docling, docetl, litellm, s3, parquet, hub, mcp, ml. See the configuration reference.

Run the offline demo (no API keys)

The demo runs the complete pipeline on bundled sample documents with a deterministic fake provider — no API keys, no network:

uv run knovaryn demo --examples 20 --json
uv run knovaryn doctor        # environment + storage health

In about 90 seconds you get a release bundle: dataset card, per-file manifest, quality/source/license/privacy reports, lineage, and a detached checksum. The full command lifecycle (project → source → run → review → dataset) is in the CLI reference.

The same lifecycle is drivable from the browser console that ships with the REST server (knovaryn server):

Animated demo: the Knovaryn web console walking through source intake, a pipeline run, the dataset quality report, per-example provenance, and a checksummed export. Open the linked GIF to play the 24-second animation; this static poster shows the console header and project panel. 24-second silent walkthrough — source → run → quality result → provenance → export. Every frame is the real console driven against the deterministic demo workspace; the GIF is linked (not autoplaying here) so motion-sensitive readers can skip it, and the scene table in that guide is a full transcript.

Use it over MCP

Knovaryn is an MCP training-data server: a Model Context Protocol server any MCP-capable agent can drive. The authoritative tool catalogue is generated from the server registration — see MCP tools. Supported MCP SDK range: mcp>=1.28,<3 (an acceptance matrix exercises both the 1.x and 2.x lines over stdio and authenticated streamable HTTP — see ADR-0007).

pip install "knovaryn[mcp]"
knovaryn-mcp                     # stdio (default MCP host transport)
# or remote over Streamable-HTTP:
knovaryn-mcp --transport streamable-http --host 127.0.0.1 --port 8000

Connect your agent and ask it to build a dataset — see MCP training-data server and MCP clients.

For real documents, drive the pipeline through the MCP tools (or REST / SDK): knovaryn_create_project → knovaryn_add_source (permitted documents, declared licenses) → knovaryn_estimate_run (dry-run cost) → knovaryn_start_pipeline → knovaryn_validate_dataset → knovaryn_create_dataset_version + knovaryn_export_dataset. Walkthroughs: PDF → SFT dataset, build DPO preference data, grounded QA datasets.

What Knovaryn produces

A Knovaryn release is an immutable, versioned bundle:

  • trainer-ready records in JSONL / Parquet and framework layouts (trl_sft, trl_preference, kto, sharegpt, alpaca, openai_chat, huggingface_layout, evaluation) — generated table in the exporter reference;
  • a dataset card, per-file manifest, quality/source/license/privacy reports;
  • a detached checksum + reproducible bundle, verified with knovaryn verify-release.

Web console export result: the dataset lifecycle panel reports the exported bundle as 4656 bytes over 6 lines with sha256 checksum 867f61554477e5403d1b5e38f7772bb848640a6380e118422d412364cbef6e9

Concern Supported
Inputs PDF, Markdown, office/documents (via Docling), local files, archives; URL ingestion opt-in
Topologies SFT, DPO/preference, KTO, evaluation (grounded QA)
Providers Offline deterministic fake provider; LiteLLM gateway (OpenAI-/Anthropic-/DeepSeek-compatible)
Deployment Local (SQLite + filesystem); team (PostgreSQL + S3-compatible); Docker / Compose / Kubernetes
Interfaces CLI, MCP server, REST + web console, Python SDK

Traceability: walk any example home

Every exported row carries source_document_ids, source_span_ids, and a content_hash:

TrainingExample → chunk → SourceSpan → ParsedDocument → SourceDocument
                                                          → location + precision

Every span carries a machine-verifiable location precision, derived from what the parser actually recorded — never asserted by callers: exact_bbox (page + bounding boxes, Docling-backed documents), exact_page, page_range, section, chunk, or unknown. Markdown and plain-text sources honestly report section/chunk granularity instead of fabricating page numbers; lineage (API /v1/projects/{id}/examples/{eid}/lineage, MCP knovaryn_lineage) returns the per-span precision so consumers can verify provenance claims.

Web console lineage view: the examples list shows a kto example, and the lineage panel traces it to its source document id and span id with location precision "section", pages left empty and bounding-box count zero because the markdown source carries no page geometry

The export provenance gate resolves every document/span reference to an existing record in the same project and recomputes the content hash. A row that cannot be resolved blocks the export — Knovaryn never returns a "successful" export it cannot defend.

Quality gates and human review

Candidates are scored against a dated acceptance policy and pass fail-closed gates — failure means quarantine, never silent export:

  • schema · grounding · completeness/answerability · format
  • refusal · duplicate · contamination (train/val/test leakage)
  • semantic consistency — deterministic contradiction checks (offline-fast, default), optionally extended by a cited-evidence-only LLM judge (certified-semantic; deterministic contradictions are final, an unavailable judge yields unverified, never verified)
  • preference signal (DPO/KTO pairs) and information gain
  • privacy · license

Human review (knovaryn_review_example) records an approve/reject decision as a new immutable revision — it never mutates an example in place. The gate list is generated from validator registration: quality gates; validation profiles are in validation profiles.

Web console quality report and review: the dataset lifecycle panel reports 6 examples all accepted with per-topology counts (5 sft, 1 kto), and the review panel records an approval that creates revision 2 with parent revision 1

Benchmarks, with their limitations

Reproducible benchmark suites cover parse fidelity, lineage resolution, generation validity, groundedness, duplicate/leakage rate, pipeline overhead, crash recovery, and export compatibility; semantic-judge quality is measured as false-accept / false-reject rates with Wilson confidence intervals against an adversarial corpus. Honest framing: offline fake-provider throughput measures framework overhead only — it is not synthetic-data generation throughput or model quality. Current numbers: report 0.2.1, methodology in benchmark methodology — reproduce them before relying on them.

Security and privacy

  • Offline-first — no credentials required for the demo, tests, or first run.
  • Secrets from the environment only — never hard-coded, never logged, redacted at the display boundary.
  • Secure intake — path-traversal/symlink protection, verified archives, URL ingestion off by default, SSRF defenses, loopback HTTP binding, no shell-command MCP tools.
  • Publication is dry-run by default and gated on license approval — nothing is pushed anywhere without explicit action. See license & privacy and hardening. Report vulnerabilities per SECURITY.md.

Maturity and limitations

  • Alpha software (0.x): APIs, storage layout, and the MCP surface may change before 1.0; do not build unmanaged long-lived dependencies on 0.x internals. Breaking changes are documented in the changelog.
  • The offline demo uses a deterministic fake provider — its output demonstrates the pipeline mechanics, not generation quality. Real datasets require real providers and your own review effort.
  • Location precision depends on what the parser records: plain-text/markdown sources cannot yield page or bounding-box precision, and spans are reported at the honest lower granularity instead.
  • Deterministic semantic checks catch specific contradiction classes only; they cannot prove entailment. Judge-based verification requires configured, reachable providers and inherits their limitations; unavailable judges fail closed to unverified rather than guessing.
  • Publication gating enforces license/privacy policy inside Knovaryn; it is not legal clearance. You are responsible for the rights to your sources.
  • Single-node SQLite mode is local-first and not multi-writer; team scale expects PostgreSQL plus object storage.

Documentation

Contributing and community

Please read CONTRIBUTING.md, the code of conduct, and SECURITY.md. See GOVERNANCE.md for how the project is run and CHANGELOG.md for what changed.

License and citation

Apache-2.0 for original code (see LICENSE). Dataset licensing is kept separate from code licensing and governed by the source-license registry. Third-party licenses: LICENSES-THIRD-PARTY.md.

If you use Knovaryn in research, please cite it — see CITATION.cff.

Metadata

Release files for knovaryn 0.2.2

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for knovaryn 0.2.2
File Size Uploaded Provenance Actions
knovaryn-0.2.2.tar.gz 3.7 MB With provenance Details for knovaryn-0.2.2.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for knovaryn 0.2.2
File Interpreter ABI Platform Actions
knovaryn-0.2.2-py3-none-any.whl Python 3 none any Details for knovaryn-0.2.2-py3-none-any.whl

Total release size: 4.0 MB

Release files / knovaryn-0.2.2.tar.gz

Download URL knovaryn-0.2.2.tar.gz
Size 3.7 MB
Tags Source
SHA-256 checksum
How to use checksums
c3396fced5440965dd78dfe8f5f2a4c17ad0f28c6d71a35a39c44299d9b0a5cb
BLAKE2b-256 checksum
How to use checksums
2881fbb59e56f5466208a6317ac942459830307cdc922427d623e18667dd2aa5
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 27, 2026.

Transparency log

Release files / knovaryn-0.2.2-py3-none-any.whl

Download URL knovaryn-0.2.2-py3-none-any.whl
Size 274.1 kB
Tags Python 3
SHA-256 checksum
How to use checksums
be2632729df79ff419e035fc660fc2bb60c544351ec8e3070986ff66e15c276d
BLAKE2b-256 checksum
How to use checksums
4de99a99159a43f4aeaf52fc510c7bb382f0d0ae21d9ab710cd1feaecf897332
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 27, 2026.

Transparency log

Security for knovaryn 0.2.2

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for knovaryn-0.2.2.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 27, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page