Knowledge packs

A knowledge pack is a set of reference documents that agents draw on: a specification template, a style guide, a runbook, worked examples. An administrator adds documents to a pack once and grants the pack to the agents that should use it. Before an agent answers, it searches its granted packs for passages relevant to the request and receives the best ones as numbered references.

Packs come in two kinds. Generic packs hold reusable reference material meant to be shared. Company packs hold your organization's own material, and an agent reaches a company pack only through an explicit grant. How agents work explains how packs teach an agent your formats.

The demo seed holds eleven packs. Seven hold one document each. The other four are a synthetic operations corpus of 55 documents about one invented SAP landscape: company-ams-incident-digests (24 incident digests, 4 problem records and 2 monthly service reviews), company-solution-design-fds (7 functional and technical specifications), company-change-and-downtime-calendar (6 documents: downtime and release calendars, post-downtime reports, a restart checklist and a change board minute) and sap-operations-runbooks (12 runbooks). The first three are company packs. The runbooks are generic and name no company system, incident or plant. The corpus describes no real organization and names no person. Every document in it ends with a line of keywords, so that keyword search finds it by the exact terms an analyst types. A hosted catalog holds these documents only after an administrator re-runs the seed.

Who can do what

• PlatformAdmin adds documents to a pack and deletes them.
• PlatformAdmin can open a document and download its original file. AgentBuilder and Auditor hold the permission to read pack documents, but the document page does not open for them yet.
• Anyone who may see a run sees the passages that were issued to the model for that run, on its run record. That is not access to the document: see How answers cite pack documents.
• A person in the support chat can open, read-only, a document that their own answer cited, from that answer's source page. That is not access to the pack.
• PlatformAdmin, AgentBuilder and Auditor, who maintain and review the packs, read the chat answers rated Not helpful, with their reasons and notes, on the Answer feedback page under Build.

Formats you can add

• Markdown (.md) and plain text (.txt). Stored as written. Agents read the text as written.
• Word (.docx). The original file is kept, and its text is read into Markdown. Headings and lists are kept. Other formatting, such as tables, may come through as plain text.
• PDF (.pdf). The original file is kept, and its text is read page by page. Each page starts with a line such as Page 3, so a passage can say which page it came from.
• Images: PNG (.png), JPEG (.jpg, .jpeg) and WebP (.webp). The original file is kept, and the image becomes a document of its own, shown under its title.

Images inside Word and PDF documents are kept too; Images explains which ones and how answers show them.

Older Word files (.doc), spreadsheets, slides and other image types, such as GIF files, are refused. The file's extension decides the format. If the browser also sends a content type, it has to match the extension: a file named manual.pdf sent as a Word document is refused.

Limits

• 4 MB per file. A larger file is refused before it is read. Split a large document and upload the parts; uploading larger files directly to storage is not available yet.
• 400,000 characters of text per document. A document with more text is refused, never cut short.
• 300 pages per PDF.
• 15 seconds to read a document. A document that takes longer is refused.

Each refusal names the limit it hit, and nothing is stored for a refused document.

Documents that are refused

• Scanned PDFs. A PDF made only of page images has no text to read. It is refused with a message saying so: reading text from images is not supported yet.
• Password-protected PDFs and encrypted Word files. Remove the password, save the file, and upload it again.
• Damaged files. A PDF or Word file that cannot be opened is refused as possibly damaged.
• Documents with no text. An empty file, or one with only blank space, is refused.

In every case the upload shows the reason, and nothing is stored: no document, no file and no passages.

Classification at upload

Before anything is stored, the document's text, its title and its file name are checked together by the data classification policy. For a Word or PDF document, the text checked is the text read from the file, so a credential inside the document is found the same way as in a Markdown file. The strictest decision across the three decides:

• Allow. The document is stored.
• Redact. Each credential is replaced by a placeholder such as [REDACTED:credential], which cannot be reversed. For a Word or PDF document, only the redacted text is kept: the original file is not stored, and no download is offered.
• Block or review required. The document is refused and nothing is stored. There is no reviewer queue.

Data classification explains what each class covers and what every decision does elsewhere in the platform.

Viewing and downloading

Opening a document shows its text, with its kept images in place. For a Word or PDF document, that is the text read from the file, shown as formatted Markdown, with a Download the original button that returns the file exactly as it was uploaded; an image file offers its original the same way. The download and the images go through the same permission check as the page; no storage link is ever exposed. A redacted Word or PDF document shows only its redacted text.

Deleting a document removes its text, its passages, its original file and its images.

Images

Which images are kept. From a Word document: each embedded image stored as PNG, JPEG, GIF or WebP; other types, such as SVG, TIFF or EMF drawings, are not kept and are counted. From a PDF: each image object drawn on a page, in page order. An image file (.png, .jpg, .jpeg or .webp) is kept as a document of its own. Every kept image is re-encoded as a lossless WebP image of at most 1,568 pixels on a side, with its metadata removed, and stored beside its document.

Limits. At most 40 images are kept per document. One image may have at most 8,000,000 pixels, may take at most 5 MB as stored in the document, and needs at least 32 pixels on each side. Across one document, at most 128 MB of image data is read. Images are read after the text, within the same 15 seconds; preparing the kept images has its own 20 seconds. A document is never refused because of an image: an image over a limit is not kept, and is counted. An image file that cannot be kept is refused with the reason.

Nothing is dropped silently. When any image is not kept, the document's text ends with one line such as Images: 2 kept, 1 not kept (type: 1). The reasons are type (not a kept image type), pixels, bytes, size (too small), count (more than 40), pool (the document's image budget is spent), deadline (time ran out) and decode (the image could not be read, or is animated).

Where a figure appears. Each kept image has a marker in the document's text, labelled Figure 1, Figure 2 and so on in document order, with its alt text from Word or its page from a PDF. A label is at most 200 characters: a longer alt text is cut at a word boundary and ends with …. The label and the alt text are searched like any other text. Opening the document shows the images in place. When an answer cites a passage that contains a figure, the run record shows the figure as a thumbnail under that citation; if the document has since been deleted, the thumbnail reads "image no longer available". The model never sees the image: it reads the marker as text, such as [Figure 1: Credit flow].

Classification. Alt text, figure labels and the image line are part of the text that is classified at upload. The pixels are not scanned. On a redacted document no image is kept, and each marker becomes [image not kept: document redacted]. An image file is classified by its title and file name; its pixels are not scanned either.

Not yet. Figures are described only when an administrator asks for it; see Describing images. A scanned PDF is still refused: its page images are not read as text.

Recorded limits.

• A run's owner keeps seeing the figures their run was given for as long as the run's receipt exists, even after the agent loses its grant to that pack, exactly as they keep the citation; new runs cannot retrieve the pack.
• When a PDF's image reading runs out of time, images on pages not yet reached are not counted, because finding them would take the time that ran out.

Describing images

A figure's label and alt text are searchable, but the picture itself is not. Describe images asks a real model to write a short, factual description of each figure, and stores it in the document's text, so the figure becomes searchable text.

Who. A PlatformAdmin, from a pack document's page. On the hosted demo the real model serves only an approved real-model user, so only that user's requests write descriptions.

What it needs. The real model, a FinOps budget that covers the person asking (set one under Spend settings), and the figure-describer agent seeded in the catalog. On the hosted demo the budget on the unassigned pool covers every approved real-model user. Without a budget the request answers that a FinOps budget or spend cap blocked it; on the mock model nothing is written, because only a real model writes descriptions.

How it works. The button walks the document's figures in order, one at a time. Each figure is one governed run of figure-describer, owned by you, with the figure as its image; the run appears in your run history like any other. The description is the paragraph directly after the figure, such as Figure 1 description: A flow of credit checks from order to release., and is at most 1,000 characters. It is classified like any document text: a credential in it is redacted, and a description the policy blocks is not stored. Describing a figure again replaces its description. After each description the document's passages are rebuilt, so search finds it at once.

Cost. Each figure costs about $0.01 once settled; about $0.09 is reserved while the run is in flight. The run record shows the exact cost.

Recorded limits.

• If rebuilding the passages fails after the description was written, the request reports a failure and search does not find the new text yet; the next description of any figure in that document rebuilds every passage from the current text, which closes the gap.
• Two administrators describing the same document at the same moment can lose one description: the last write wins. The button sends one request at a time, so one person never races themselves.

How answers cite pack documents

Each document's text is split into passages of about 1,000 characters. A PDF passage never spans two pages and always starts with its page line, such as Page 3; when a long page is split, each piece repeats that line.

When an agent runs, up to eight passages from its granted packs are given to the model as numbered references, each labelled with its pack and document title. An agent whose grounding mode asks for citations cites those numbers, and for a PDF the passage's page line tells the reader which page to open.

The run record lists, under Sources, which documents and passages were issued as references. Under each one it shows the passage itself: the text that was issued to the model for that run, as plain text, with a figure as its label, such as [Figure 1: Credit flow]. Anyone who may see the run sees it. A passage longer than six lines or 600 characters shows its first six lines until "Show full passage" is opened. If the passage cannot be loaded, the source reads "Passage unavailable for this source."

The roles that may read pack documents (PlatformAdmin, AgentBuilder and Auditor) also see an Open document link on each source of any run they may see. For PlatformAdmin it opens the document with the passage at that position shown above its text, under "Cited passage"; for AgentBuilder and Auditor the link does not open the document yet. That page shows the document as it is now: if its passages have been rebuilt since the run, the passage there can differ from the one the run was given, which the run record still shows. In the support chat, a person can also open a document that their own answer cited, from that answer's source page. Other roles see the passage.

An agent has one of three grounding modes. In open mode it receives the references and is not asked to cite them. In preferred mode it is asked to cite the passage that supports a claim by its marker, such as [1], and the run still completes, with a warning, when no acceptable passage was found or the answer cites none. In required mode the run stops before the model is called when no acceptable passage was found, and an answer that cites none of its references is not accepted. The seeded catalog sets the mode for each agent: ten are seeded as preferred and the rest as open, and the agents guide names them. Re-running the seed returns a seeded agent to its catalog mode.