What is an LLM-ready file?

Published 2026-04-22

Definition

An LLM-ready file is a file that carries a structured, signed semantic layer in its own metadata. Any AI tool can read that layer without re-parsing the file.

More formally: A file is LLM-ready when it contains enrichment metadata conforming to LRFS (LLM-Ready File Specification) embedded in its XMP packet, signed with a verifiable scheme, and readable by any tool that understands the LRFS namespace.

It's a property, not a pipeline

LLM-ready is a property of the file, not a step in a process you run on-demand.

Think of "readable" or "signed" — these are properties. A file is either readable or not. A document is either signed or not. An LLM-ready file is the same way. Once you enrich a file with LLMind, it stays LLM-ready forever. You can copy it, move it, store it, share it — the enrichment layer travels with it.

This is different from how RAG systems work. In a RAG pipeline, you parse a file, extract chunks, embed them, and store vectors in a database. The file itself is dumb — the smarts are in the database. If the database goes down, or you switch to a new database, the enrichment is lost.

With LLMind, the enrichment lives in the file. The file is smart. No external database required.

Why existing file formats aren't LLM-ready

PDF, JPEG, MP3, PNG, DOCX — these are all mature, well-engineered formats. They carry rich metadata.

PDFs have an Info dictionary. JPEGs have EXIF. MP3s have ID3 tags. Most image formats support IPTC or XMP. But none of this metadata is designed for AI. These tags describe the physical properties of the file (camera settings, author, creation date, copyright). They don't describe the semantic content in a way an AI system can parse and trust.

When ChatGPT receives a PDF, it doesn't read the Info dictionary — it reads the raw bytes and reconstructs the content. When Claude sees a JPEG, it doesn't parse EXIF — it processes the pixels. When Perplexity plays an MP3, it doesn't read ID3 tags — it transcribes the audio.

The file's existing metadata is opaque to these tools. And even if it weren't, the metadata formats weren't designed for semantic structure — they weren't built to carry descriptions, entity extraction, or structural summaries.

How you make a file LLM-ready

You run LLMind.

llmind enrich myfile.pdf

The LLMind CLI:

  1. Reads the file
  2. Analyzes it (parses the content, optionally calls a model for richer extraction)
  3. Computes structured enrichment: description, entities, structure, transcription (if audio), OCR (if scanned)
  4. Writes the enrichment into the file's XMP packet under the namespace https://llmind.org/ns/1.0/
  5. Signs each layer with HMAC-SHA256 or ed25519
  6. Writes a file-level SHA-256 checksum
  7. Saves the enriched file back to disk

The file is now LLM-ready. The enrichment is permanent and portable.

Working example

Before enrichment: You have contract.pdf. You upload it to Claude.

Claude's system:

  1. Receives the PDF bytes
  2. Runs PDF parsing (layout analysis, text extraction)
  3. Runs OCR on scanned sections
  4. Chunks the content
  5. Embeds chunks into vectors
  6. Retrieves relevant chunks based on your query
  7. Sends context to the LLM

Claude sees what the raw PDF bytes tell it. If the PDF is poorly scanned, or has unusual layout, Claude has to reconstruct structure from the raw signal.

After enrichment: You run llmind enrich contract.pdf before uploading.

Now the PDF carries enrichment in XMP: a description ("5-page legal contract dated 2024, Section 3 addresses liability limits"), extracted entities ("Acme Corp", "damages limit $1M"), structural summary (sections and headings).

Claude's system:

  1. Receives the PDF bytes
  2. Reads the XMP packet
  3. Finds the LRFS enrichment layer
  4. Verifies the signature
  5. Uses the pre-computed description, entities, and structure
  6. Skips re-parsing and re-OCR
  7. Sends the enriched context directly to the LLM

Claude gets better context faster, without re-parsing work.

Why the signature matters

Trust is critical. If metadata can be silently modified without detection, it's not trustworthy.

The signature solves this. Each enrichment layer in the XMP packet is signed with a key. HMAC-SHA256 for private corpora — your organization controls the key, other tools can verify with your public key. Ed25519 for public verification — anyone can verify the signature without the signing key, making it suitable for published datasets or public records.

A downstream consumer reads the metadata and verifies the signature. If the signature is valid, the metadata hasn't been tampered with — it came from the signer and arrived intact.

File-level SHA-256 checksum: If someone modifies the file content itself after enrichment, the checksum no longer matches, and consumers know the file and its metadata are out of sync.

Where to read the spec

Everything is documented openly at llmind.org/spec/:

  • Payload format: Exactly what goes into the XMP packet. JSON structure, required fields, optional extensions.
  • Signing scheme: HMAC-SHA256 vs. ed25519, key management, verification algorithm.
  • Conformance levels: How a tool signals whether it's a minimal reader (just recognizes the format) or a full reader (verifies signatures, re-enriches if needed).

The spec is version 1.0, open for comment, and designed to evolve. If your use case needs a new enrichment layer (e.g., embeddings, domain-specific metadata), you can propose an extension to the spec.

The bigger picture

LLM-ready files are designed to solve three problems:

  1. Waste: Stop re-parsing and re-OCR'ing the same file across tools.
  2. Trust: Embed verifiable metadata in the file itself, not in an external database that can disappear.
  3. Portability: Enrich once, use everywhere. The enrichment travels with the file.

The file is the index. LLM-ready files make that index portable and verifiable.