Introducing LLMind: the file enrichment engine

Published 2026-04-22

The problem: every AI tool rewrites the same file

Every time you upload a file to ChatGPT, Claude, NotebookLM, Cursor, or Perplexity, something wasteful happens. The AI tool re-parses the file from scratch. If it's a PDF, it runs OCR again. If it's an image, it re-extracts metadata and structure. If it's an audio file, it re-transcribes.

You've done this work before. ChatGPT already OCR'd your scanned contract. Claude already extracted entities from your research PDF. NotebookLM already chunked your audio transcript. But each tool has no way to reuse that work — they can't see inside each other's representations, and they can't read a standardized format that says "this file has already been enriched."

The cost compounds. Users waste time re-uploading the same file. AI tools waste compute re-parsing it. The file itself carries no semantic structure that machines can trust.

The bet: the file is the index

Rather than shipping another RAG framework, another vector database, or another parser, LLMind makes a simpler bet: metadata should live in the file.

We embed a structured, signed semantic layer directly into each file's XMP metadata packet. Not as a separate artifact. Not in a database. In the file itself. The file becomes the source of truth for its own enrichment.

When you enrich a file with LLMind, you're not creating a database record or a vector embedding. You're writing a permanent, verifiable annotation into the file's own XMP namespace. That layer travels with the file. Upload it to any AI tool, and the tool can read the enrichment natively — no database lookup, no additional parsing, no integration with an external service.

What "LLM-ready" means

An LLM-ready file carries a structured, signed semantic layer that any AI tool can read without re-parsing.

It's not a new file format. PDF is still PDF. JPEG is still JPEG. MP3 is still MP3. We use XMP, the extensible metadata platform that's been part of the PDF and image standards for decades.

It's not a property of how you use the file. It's a property of the file itself — like "readable" or "signed." Once a file is LLM-ready, it stays LLM-ready. You can store it, copy it, share it, move it. Any downstream consumer — Claude, ChatGPT, your own custom RAG pipeline, an MCP server, a batch processing job — can read the layer.

How it works

The flow is simple. You have a file: research.pdf. You run the LLMind CLI:

pipx install 'llmind-cli[all]'
llmind enrich research.pdf

The CLI reads the file, analyzes it (or uses a model you specify), and writes structured metadata into the file's XMP packet under the namespace https://llmind.org/ns/1.0/. It includes:

  • A concise description of the file's content
  • Extracted entities (people, organizations, concepts)
  • Structural summary (headings, sections, key points)
  • For audio files: transcription (or reference to it)
  • For scans: OCR output (or reference)

Each layer is signed with HMAC-SHA256 (for private corpora) or ed25519 (for public verification). The entire file gets a SHA-256 checksum so consumers can detect tampering.

The enriched file is written back to disk. It looks and behaves like the original — you can open it in any PDF reader, image viewer, or audio player. The semantic layer is silent to those tools. But when you upload it to Claude, or feed it to your custom AI agent, or pass it to an MCP server, those tools can read the layer natively from the XMP packet.

The open spec: LRFS

The real leverage is the specification. LLM-Ready File Specification (LRFS) is an open standard that defines:

  • The XMP namespace URI (https://llmind.org/ns/1.0/)
  • The payload format (JSON in XMP)
  • The signing scheme (HMAC, ed25519, checksums)
  • Conformance levels for third-party readers and writers

Owning an open spec is how you turn enrichment into a category. Look at the precedents: llms.txt (Answers.ai), robots.txt, sitemap.xml, MCP (Anthropic). These started as single tools. They became standards because they were open, versioned, and implementable by anyone.

LLMind publishes LRFS so third parties can write conformant readers and writers. A startup can build a competing enrichment engine and write LRFS-compliant metadata. A university can publish a research corpus with LRFS semantics embedded. An enterprise can integrate LRFS into its DAM pipeline. The standard grows the category.

Standard beats product.

What's shipping today

We're launching LLMind with:

  • Python CLI (llmind-cli): Available now on PyPI — pipx install 'llmind-cli[all]'. Runs on macOS and Linux — your laptop, your datacenter, your CI/CD pipeline. Air-gapped. No telemetry.
  • Web converter: Drag a file into app.llmind.org, get an enriched version back. No install, no API key. Works for PDF, JPEG, PNG, MP3.
  • LRFS v1.0 specification: Full documentation at llmind.org/spec/. Normative details on payload format, signing scheme, and conformance levels.

What's next

We're shipping in phases. Sprint 2 (now) ships the spec and CLI. Sprint 3 brings a dedicated MCP server so AI agents can natively consume enriched files. We're writing a reference implementation in a second language (likely Go or Rust). We're publishing a white paper to arXiv. We're working on integrations with popular DAM platforms, batch processing services, and AI tools.

But the core bet is the spec, not the tool. LLMind is open-source Python. Adopt it, fork it, extend it. Better yet: implement the spec your own way. Write your own LRFS reader. Build a competing enrichment engine. The standard was built for that.

Install, star, follow

The CLI installs via PyPI in one line — pipx (or uv) puts it on your PATH in an isolated environment without touching your system Python:

pipx install 'llmind-cli[all]'
llmind --version

Requires Python 3.11+. PDF rendering also needs poppler-utils on the system (brew install poppler on macOS).

Star the repo: https://github.com/dmitryrollins/LLMind

Read the spec: https://llmind.org/spec/

Try the web converter: https://app.llmind.org

Follow along on Mastodon or the GitHub discussions. We're building in public.

The file is the index. Let's make every file LLM-ready.