Ingesting a Knowledge source, end to end

The chain, stage by stage#

1. Trigger — you add a source: the button, a drag, or a paste. The same file service serves both audiences, so this path is identical for the Owner and for a customer.
2. User event — the upload is a person's action. Nothing crawls your systems and nothing is ingested because it happened to arrive in an inbox.
3. Authentication and workspace resolution — the file lands in the resolved workspace's own storage, already scoped and under row-level security, rather than in a shared pool that is filtered afterwards.
4. Ingest — the format decides how it is read: PDF (its text layer where there is one, otherwise the model reads the document), DOCX, XLSX, CSV and TSV, PPTX, TXT, Markdown, JSON, and PNG, JPEG or WebP images.
5. Canonical record — the source is stored with its provenance, so 'where did this claim come from' has an answer that names a file and a person.
6. Reasoning — extraction pulls out the statements worth holding as facts. A fact is one grounded statement; the document behind it stays available for anything extraction did not capture.
7. Knowledge, memory and rules — supplied text is treated as data. Instructions written inside a document are content to be read, not directions to be followed.
8. Autonomy and approval — none. Adding a source changes what answers can be grounded in; it does not change what Connect may send without asking.
9. Action — no provider is called and nothing leaves the workspace. Ingestion is entirely inward.
10. Result — the source is listed on Knowledge with its status. If it was refused, the refusal says so rather than leaving a file that looks present and answers nothing.
11. Relationship, timeline and memory — nothing is written to a person's record. A document is not an event, and it does not belong on anybody's timeline.
12. Audit, usage and Needs You — the addition is recorded with its author, and anything that needs a person to look at it appears in Needs You.

What is refused, and why that is the right answer#

Two structural hazards are refused outright rather than parsed carefully. A document containing DOCTYPE or ENTITY declarations is refused, because those are the mechanism behind entity-expansion attacks on XML-backed formats. So is a compressed file that expands out of proportion to its size — a zip bomb — because unpacking one is how a parser becomes a denial of service.

These refusals are not heuristic guesses about content. They are structural, which is what makes them safe to apply strictly: an ordinary business document does not need either construct, so refusing both costs nothing real.

A third category is refused by nothing and disappoints anyway: a scanned page with no text layer. The file is genuinely there, and where the model reads the document directly it can still be used, but a low-quality scan of a fax of a price list is a poor source no matter what reads it. Retyping the ten lines that matter as facts beats uploading forty pages of grey.

There is no vector database here#

This is worth saying plainly because the surrounding industry assumes otherwise. Grounding in Connect is retrieval over the Knowledge a workspace supplied. Nothing is embedded into a separate vector store, nothing is trained on your material, and no model weights change because you uploaded a document.

Two consequences follow, and both are practical rather than philosophical. First, a source is usable as soon as it has been read — there is no index to warm and no delay to wait out. Second, what you supply is exactly what can be used: material that is vague, contradictory or spread over forty pages does not get smoothed over by clever retrieval.

Getting a source that works#

1. Add the document, then read the source list rather than assuming.

   Result A refusal is visible here. A file that never appears is a different problem from one that appears and answers badly.

2. Ask the retrieval test a question the document should answer.

   Result You see whether the right passage is selected before a customer does, which is the whole reason that screen exists.

3. Add a short fact for anything critical and buried.

   Result A direct statement survives a tight retrieval budget; one sentence inside a long appendix often does not.

4. Remove the previous version of anything you have just replaced.

   Result Two versions of a price list in the bank is the single most common cause of an answer that quotes the wrong thing.

Questions#

Related#

• Knowledge sources
• Extracting text from a source
• How Knowledge is prepared for retrieval
• Adding a Knowledge source, end to end
• Parsing a file safely
• Instructions hidden in content
• Retrieving Knowledge for one reply
• Grounding an answer without pretending to have a vector database