From engineering PDFs to a live catalog

For Altus, an aerospace equipment manufacturer with nearly a century of history, the starting point was a familiar one: the knowledge about every product existed, but it lived in specification sheets, test reports and brochures that were never meant to be read side by side. The goal was a corporate website with a product catalog, R&D and tenders in a single navigation. The catalog was the hard part.

We have since used the same approach in other document-heavy projects — Folio, an AI editor for learning content, follows a similar pattern of “model proposes, expert decides”. Here is how it works.

Step 1: get the documents into text you can trust

Technical PDFs are a mix of digital text, scanned pages, tables and drawings with callouts. Before any language model sees them, each page is converted to text with its layout preserved: tables stay tables, headings stay headings, and every chunk keeps its source file and page number. Scanned pages go through OCR and are flagged so they get extra review later. This step is boring and it decides the quality of everything after it.

Step 2: let the model propose the structure

A human reading five hundred pages to design a catalog taxonomy needs weeks. A model can read them and propose a structure — product families, variants, the parameters that distinguish them — in an afternoon. The proposal is rarely perfect, but it is a much better starting point for a workshop with the client's engineers than a blank whiteboard. We iterate on it with them until the categories match how their buyers actually search.

Step 3: extract into a schema, then write prose

The most important rule in document projects: extract facts into fixed fields first, and generate text from those fields second. For each product the model fills a schema — designation, purpose, key parameters with units, operating conditions, certifications — and leaves a field empty rather than guessing. Only then does it draft a readable description, using nothing but the extracted fields.

This order matters because it makes errors visible. A wrong number in a structured field is easy to spot and check against the source. The same wrong number buried in a fluent paragraph slips through.

A fluent paragraph hides a wrong number. A table field shows it.

Step 4: every fact has a source

Each extracted value carries a reference to the document and page it came from. The review interface shows the field and the source excerpt next to each other, so an engineer verifies a product in minutes instead of rereading the original. When the source documents contradict each other — and in decades-old documentation they do — the model flags the conflict instead of picking a side.

Step 5: engineers have the last word

For Altus, the language model proposed the catalog structure and drafted the descriptions; the company's engineers verified them before anything was published. That isn't a formality. In aerospace, a plausible but wrong parameter is worse than no parameter at all. The model's job is to remove the weeks of reading and typing, not the responsibility.

What you end up with

• A catalog structure designed around buyers' scenarios, not around the internal department that wrote each document.
• Structured product data that can feed the website, a PDF export and a tender response from the same source.
• A repeatable pipeline: when a new product or revision appears, it goes through the same extraction and review instead of a new manual project.

Keeping the catalog alive

A catalog that is correct on launch day and stale six months later has only moved the problem. The pipeline is built so that a new specification sheet or a revised document goes through the same steps: conversion, extraction into the schema, a diff against what's already published, and review of only the changed fields. Engineers check what changed, not the whole product again.

The same structured data can feed more than the website. Once products live in a schema rather than in prose, a tender response, a dealer price list or a printed brochure can be generated from the same verified source, and they stop contradicting each other.

Common pitfalls

• Letting the model write marketing copy from raw documents. It will be fluent, persuasive and occasionally invent a parameter. Extract first.
• Skipping the taxonomy workshop. A structure that mirrors the company's internal departments is easy to build and hard for buyers to use.
• Reviewing in a spreadsheet. Experts review much faster when they see the extracted field and the source page side by side.
• Treating units as text. “10 kg”, “10kg” and “10 kilograms” are the same value; normalise units in the schema or comparisons will break.

Where this applies

Anything with a large pile of semi-structured documents and a need for consistent output: product catalogs, regulatory dossiers, learning materials, contract libraries, maintenance manuals. If your team spends weeks copying facts from one format to another, that's the signal.

Case · Aerospace · LLM

Altus

A language model turned hundreds of pages of technical documentation into the product catalog of a manufacturer's website