Build an App From a PDF Spec With Knowledge Files

Most specs already exist before the app does. A requirements PDF from a client. A DOCX of field definitions someone in operations maintains. A Markdown design system in a repo. The usual way to get that into an AI app builder is to paste chunks of it into the chat box and hope the important parts survive.

Version 1.6.0, shipped in August 2026, removes the copy-paste step. You upload the document once and it becomes retrievable context for that app.

What changed in 1.6.0

Three things landed together:

• PDF, DOCX and Markdown ingestion. The Knowledge tab accepts .pdf, .docx, .md, .markdown and .txt. Files go to storage, and a background worker extracts the text and embeds it.
• pgvector RAG, isolated per app. Each app gets its own chunk table. Retrieval is vector search, not a full-document paste.
• The home page accepts documents and Loom URLs as scaffolding. Drop a PDF on the generator before the app exists, or paste a Loom link, and the extracted context is attached as a knowledge doc that the first generation reads.

If you want the conceptual version of why persistent project context beats repeating yourself, the older Knowledge Files guide covers it. This post is the mechanics of the August release.

How to build an app from a spec

1. Start from the document. On the home page, drop the PDF into the generator (the whole page is a dropzone) and describe the app in a line or two. The file is extracted and stored as a knowledge doc before generation, so the first version already reflects it.
2. Or attach it to an existing app. Open the app, go to the Knowledge panel, and upload. Uploading is owner-only.
3. Wait for ingestion. Extraction and embedding run in the background worker, not in your request. The document list shows each file with its chunk count once it is done.
4. Refine normally. Ask for "the intake form from the spec" and the retriever pulls the relevant chunks into the prompt. You do not tag the file or name it.
5. Delete what goes stale. Deleting a document removes the stored source, the Firestore record and its vector chunks together. An outdated spec left in Knowledge is worse than no spec.

What actually happens on retrieval

This is a retrieval system, not a context dump, and the difference shows up in behaviour.

Each knowledge document is chunked and embedded into a per-app table, genmb_apps_{appId}_kbchunks. That table is deliberately separate from the public vecchunks table that window.genmb.vectorDb writes to, so an app's own runtime vector data cannot shadow or read the owner's knowledge base.

When you generate or refine, GenMB embeds your prompt, takes the top 6 chunks by cosine similarity, and caps the injected block at 4,000 characters. Retrieved chunks carry their document id and page number, so the model sees where a passage came from.

Two consequences worth designing around:

• A 60-page PDF does not mean 60 pages of context. Six chunks come back. A prompt that says "build the reporting screen" retrieves the reporting parts. A prompt that says "build the app" retrieves whatever is closest to that vague sentence, which may be the cover page.
• Structure helps retrieval. Headings, field tables and short sections chunk cleanly. A scanned image-only PDF with no extractable text has nothing to embed.

Knowledge retrieval plugs into both the codegen PREPARE stage and the chat path, so it applies to the first generation and to every refinement after it.

Loom URLs and the home page

Paste a Loom, YouTube or Vimeo link into the home generator and GenMB pulls the page's oEmbed metadata and description, then stores that as a knowledge doc like any other. It is metadata and description text, not a full transcription, so treat a Loom link as a useful framing note rather than a substitute for the spec. A walkthrough video's title and description plus a two-line prompt is often enough to get the shape of an app right on the first try.

Limits, from the code

These are the values the API enforces, not marketing rounding:

Upload something outside the accepted extensions and the API rejects it by name. Hit the document cap and it tells you the cap and asks you to upgrade or delete a document.

The document cap is the one that bites in practice. Ten documents is enough for one app's spec, one API reference and a style guide. It is not enough for a folder of client PDFs, which is where the Pro cap of 100 per app starts to matter.

What to upload, and what not to

Good candidates:

• The requirements or scope document the app is being built from
• Field and validation definitions, especially if they exist as a table
• An API reference for a service the app has to call
• A design system or brand document with concrete values

Poor candidates:

• Scanned documents with no text layer. Nothing to extract, nothing to embed.
• Everything you have, uploaded defensively. More documents means more competition for the same 6 chunk slots, and a stale one can win a slot from a current one.
• Secrets. A knowledge document is context for code generation. API keys belong in environment variables, not in a PDF the model reads.

Where this fits next to the other document features

GenMB has more than one path for a document, and they solve different problems:

• Knowledge files are persistent context for the AI. The document informs the code.
• [Business Data Ingest](/docs/ingest) takes a CSV, Excel file or PDF, infers a database schema from it, and proposes three app shapes. The document becomes the data model and seed rows.
• [CSV Import](/docs/csv-import) is a runtime SDK for loading more rows into a table an app already has.

If your PDF is a spec, you want Knowledge. If it is a table of records, you want Ingest.

Try it

Take the spec document you already have, drop it on the home page, and describe the app in one sentence. Compare that first version against what you get from the sentence alone. The credits page covers what each generation spends, and capabilities covers what else GenMB wires into an app automatically.