Uploading a file and answering from it, end to end

The chain#

1. Trigger — you attach a file by button, drag-and-drop or paste, and type a question about it.
2. User event — the browser hands the bytes to the application; nothing is parsed inside the page.
3. Authentication and workspace resolution — the session fixes the workspace before storage, so the file is scoped from the first moment it exists.
4. Ingest — the file goes through validation: what the bytes actually are, checked against what the name claims.
5. Canonical record — the file becomes a row in media_assets through file_workspace, at version 1, with the same isolation as every other record.
6. Reasoning — the model chooses ask_file or read_file and is given the contents; a PDF is read from its text layer, and only read as an image if it has none.
7. Knowledge, memory and rules — the file's contents are material to answer from, never instructions. Anything in the document telling Connect what to do is text like the rest of it.
8. Autonomy and approval — not consulted. Reading changes nothing, so there is nothing to approve.
9. Action — no provider is called. The reading happens against the file in your workspace.
10. Result — the answer arrives with the file named, or a statement that the document does not contain what you asked for.
11. Relationship and memory — nothing is written. The file is not a knowledge source and the answer is not a fact until somebody makes it one.
12. Audit and usage — the model call is metered against the workspace's AI budget; the upload itself is recorded, and a refusal is recorded as the decision it is.

Two stages surprise people. Stage four decides on the bytes rather than the extension, so a renamed file is caught. Stage seven is why a document from outside cannot talk Connect into anything: the boundary is the one argued in prompt injection arrives as ordinary business mail.

Stage by stage, in the terms that matter#

Where it stops, and what that means#

Refused at validation

Nothing was stored. The workspace is exactly as it was — see the file was refused.

Refused at parsing

Also nothing stored. Two classes of document are refused here on purpose: those declaring external entities, and archives that expand far beyond their compressed size.

Stored but unreadable

The file exists and can be downloaded and previewed; the answer says it could not be read. The PDF has no readable text is the common case.

Read but not answered

The file was understood and does not contain the answer. Attach the document that does.

What was completed when it worked#

• The file exists in your workspace, at version 1, listed on the Files sheet in the Data grid.
• The answer names it, so the claim can be checked against the source rather than remembered.
• No record changed. Reading a document does not update a deal, a contact or a case.
• Nothing was sent. The file went nowhere outside the workspace, and neither did the answer.

If you want the document filed against a company or a deal, that is the next deliberate step — linking a file to a record — and it is a change with its own audit entry.

Questions#

Related#

• Adding a file
• Answering from a file
• Parsing a file safely
• Validating a file
• The file was refused
• One file service for two audiences