PDF to Knowledge Base · Your App Cloud
Turn PDF manuals into a knowledge base
Upload the service manual or SOP binder your team prints from. Choose the section numbers that start each article, leave out running headers and footers, and keep the revision and page number on every article.
From a manual built for print to procedures people can look up.
Narrow the pages, choose where articles start, then read each procedure next to the page it came from.
01
Choose the pages worth keeping
A 200-page manual holds a lot nobody looks up on the job: warranty terms, regulatory statements, installation steps for a site already built. Attach the PDF with the upload button above and name the chapters or page ranges to use.
02
Pick the number that starts an article
Manuals number their sections, such as 4 Maintenance, 4.3 Burners and 4.3.2 Replacing the igniter. Say which level becomes an article, often the third, and which levels become sections people browse.
03
Read procedures beside their pages
In the preview, open three procedures next to the PDF: a short one, one that runs across a page break and one with a warning. Check that every step is there in order and that each warning sits above the step it guards.
Where each part of the manual goes.
Every row names something you can find in a printed manual. The model names, codes and quoted lines are invented, as if from the oven manuals of a bakery in San Jose.
| In the PDF manual | In your knowledge base | How to check it |
|---|---|---|
| Numbered sections: '4 Maintenance', '4.3 Burners', '4.3.2 Replacing the igniter' | Sections to browse, with an article for each numbered subsection at the level you chose | List the numbers under one chapter on the PDF's contents page and compare them with that chapter's articles. A gap, such as no 4.3.4, usually means a heading was taken for ordinary text, so name it in your prompt. |
| The header and footer on every page: 'DX-40 Service Manual · Rev D · Page 37 of 212' | Left out of the article text. The manual title and revision become fields on each article | Search the articles for 'Page' and 'Rev D'. A hit in the middle of a paragraph is a footer that slipped in, usually where that paragraph crossed from one page to the next. |
| A procedure whose steps carry on over the page, sometimes under '(continued)' | One unbroken list of numbered steps in a single article | Count the steps in the PDF and in the article. Step 8 should follow step 7 directly, with no repeated title or footer line between them. |
| WARNING, CAUTION and NOTE boxes, often shaded and set beside the text | Callouts placed just before the step they apply to | On a fixed page, a box can sit in the margin or at the foot of the page. Confirm 'Shut off the gas supply and let the oven cool' comes before the step that removes the burner cover, not after the last step. |
| An exploded drawing with numbered callouts, and a parts table listing items 1 to 14 | The drawing in the article that needs it, with the parts table under it as text | Look for the drawing first. If it is missing or its callout numbers are too small to read, supply it as a separate image. Then compare three callouts with the parts table, and search for one part name, such as 'igniter bracket'. |
| A troubleshooting table with Symptom, Possible cause and Remedy columns | An article per symptom, listing the causes to rule out in order | Long tables often repeat their header row at the top of each page. Check that 'Symptom' did not become an article of its own, and that 'see 4.3.2' in a remedy opens that procedure. |
| 'See page 58', in a manual whose front matter is numbered i, ii, iii | A link to the article that covers printed page 58 | Printed page 58 is often a different number in your PDF reader's page count, because the front matter comes first. Open the link and compare it with the printed page, not the reader's count. |
| A revision table, and bars in the margin beside text that changed | A revision field on every article, and a 'Changed in Rev D' note on the articles the table lists | A margin bar is a line, not words, so don't count on it to show what changed once the text is split into articles. Take the sections the revision table names and confirm each of those articles carries the note. |
| Three manuals, one per oven model, that repeat whole chapters | One knowledge base with a model field and a model filter | Choose a value that differs by model, such as a gas pressure or a clearance to the wall. Filter to each model in turn and confirm the article shows that model's figure. |
| The index at the back: 'igniter, replacing, 58' and 'pilot light, see igniter' | Left out. Search across the articles takes its place | Use a dozen index entries as test searches, including one the index sends to another word. Each should find the article that covers it. |
A PDF records where words sat, not what they were.
A PDF is made to print the same way every time. In many manuals, a heading, a step and a warning are only type sizes and positions on a page, so the structure you want has to be named. Settle these on a copy before you upload.
Look for bookmarks first
In Acrobat, the Bookmarks panel lists links to places in the document, and PDFs made by most desktop publishing programs get bookmarks from the table of contents. If your manual has them, they are its outline: use it to name the chapters in scope. If not, work from the contents page.
Two columns and side boxes
Manuals often set text in two columns, with tips in a box to one side. Pick one such page and read the article made from it: sentences should run down the first column before the second, and the tip should stay apart from the steps.
Words split at line ends
Justified text is often hyphenated, so 'thermostat' may print as 'thermo-' at the end of one line and 'stat' on the next. Search the articles for five long terms from the manual. If one fails, look for it in two halves and ask for the halves to be joined.
One revision per model
Makers often reissue manuals as Rev C, Rev D and so on. Keep the revision that matches the equipment you actually run, and leave older copies out of the upload, or the knowledge base will hold two versions of the same procedure.
Whose manual it is
An equipment maker's manual is the maker's publication, not yours. For your own staff, keep the knowledge base behind sign-in. Before anything goes on a public help page, read the manual's terms, or link to the maker's copy instead.
An illustrative starting point
A manual people search instead of scroll.
Numbered sections as articles, procedures as unbroken step lists with their warnings, and the manual's revision and page on every article.
Procedures as numbered steps
Ask for each procedure as one list, with the tools and parts it needs above step 1 and each warning above its step. The app opens in a browser, including on phones, so read one long procedure on a phone before anyone relies on it beside the oven.
The page each article came from
Ask for the manual title, revision and printed page number on every article, so anyone can open the PDF at that page and compare. A torque figure or a gas pressure is worth that second look.
One base for several models
Where manuals repeat a chapter, ask for one shared article when the text matches and separate ones where a value differs. A search on the DX-60 should then leave out the DX-40's settings; try the model filter before you share the address.
Staff-only, with questions if you want them
Put the manuals behind sign-in, with the access you describe for each collection, then open the address in a private window and confirm no article shows. A question box set up to answer from the articles needs a backend too. Ask for the manual page in every answer, and test it on a fault code the manual never mentions.
Together in your app cloud
The pieces behind the possibility.
Choose the models and services that support the experience you want to create.
File storage
A home for your documents and media
Database
Keep data and context for apps and agents
Authentication
Give the right people access
Language models
Reason, write, and understand
A little more context
Good questions.
How is this different from putting the PDF on a shared drive?
A shared drive hands people a 212-page file, and a search for 'igniter' stops at every mention, from the contents page to the index. Here you split it into articles at the numbered subsections, so that search can lead to the replacement procedure with its warnings, its revision and the page it came from, without header and footer lines in the way.
What happens to the header, footer and page numbers?
They repeat on every page, so if they stay in the text they break into a procedure wherever a page ends. Ask for them to be left out, and for what they tell you, the manual title and revision, to become fields on each article. Then search the articles for 'Page' to catch any that stayed.
Can drawings with numbered parts come across?
Check each one rather than assume it. Ask for every drawing to sit in the article it illustrates, with its parts table underneath as text a search can find. If a drawing is missing or its callout numbers are too small to read, supply it as a separate image, and note the printed page that holds it. Then compare a few callouts with the table.
Should each model's manual become its own knowledge base?
Usually not. Manuals for models in one range repeat most chapters and differ in a few values, such as a clearance or a gas pressure. Keep one base, say which model each PDF covers, and give articles a model field. Then filter to each model and compare one value with that model's own manual.
Does this work for an SOP binder as well as a maker's manual?
Yes. An SOP binder saved as one PDF usually starts each SOP on a new page with its number, title, effective date and approver. Ask for one article per SOP with those as fields. Then compare the article count with the binder's contents list, and look for an SOP that appears twice under an old and a new date.
Can a technician type a question about a fault instead of searching?
You can add a question box that uses a language model to answer from the articles. Ask for each answer to name the article and manual page it used, test it with a fault code the manual doesn't list to see whether it says so or guesses, and read the cited page before acting on a reply. Model usage is metered separately. The AI knowledge base guide covers the question box in depth.
What do we do when the maker issues a new revision?
An upload is a snapshot, so the knowledge base keeps showing Rev D until you act. Read the new revision table, bring in the changed chapters on purpose, and compare those articles with the new pages before you publish. The app can email your technicians the list of procedures you updated. Send the first one to yourself and open every link in it.
Which plan does a manual knowledge base need?
Articles anyone may read, on one page, can be a one-page site, which Free publishes. Staff-only sign-in, a question box, email to technicians and edits made in the app all need a backend, which makes it an app with data, and putting it live needs a paid plan. Model and service usage is metered separately. See the pricing page for current plans.
Explore Pricing for plans, included capabilities, and usage details.
Keep exploring.
Let staff ask questions of your manuals ↗
See the outcome and the capabilities behind it.
Track the equipment the manuals cover ↗
An asset register for the machines themselves: where each one is, who is responsible for it and when it was last serviced.
Understand data and context ↗
Give information the right place in your app.
Prepare to publish ↗
Check the experience you will share.
Your ideas, up and running
Your next idea has a home.
Build an app. Run an agent. Make it yours.
Start building