Attaching files

What you'll walk away with: the difference between attaching and pasting, seen on your own file.

You need: both tabs, one document with a table in it that you could forward outside the firm, and about 20 minutes. The autopsy runs in your browser and never uploads.

The last lesson's inventory left one line for today: an attached file reaches the model as what an extractor pulled out of it. And you know the window is rebuilt on every send — whatever you load rides in it again and again. So the next question is what a file actually hands over when you attach one. Every demo so far was a simulation. This one is a real measurement — its footnote says MEASURED — run live in your browser.

What a file carries

Press Run the autopsy and watch the Word file unzip into its 17 files. It is the same memo you met in the press-send lesson — Q1 revenue grew 14% on paving volume. — weighed instead of read. One 37-character sentence, saved two ways. Saved as Markdown — a plain-text format, nothing but the characters — it is 37 bytes, and every byte is the sentence. As a Word file it is 36,607 bytes that unzip into a pile of XML — styles, themes, namespaces — with the sentence about a tenth of a percent of it. Click word/document.xml in the tree to see that in place: hundreds of characters of namespace declarations before the highlighted run that is the entire memo.

Be precise about what that ratio measures, because it is not a window measurement. When you attach a file, the app does not shovel those 36,607 bytes at the model; it runs an extractor first and sends along what the extractor keeps. The ratio measures how much of the file is not your sentence — and everything that isn't the sentence is something you are trusting an extractor to handle for you, sight unseen, with fidelity that varies by product and by file.

A Word file also carries more than formatting. Open docProps/core.xml in the file tree and you are reading the document's property fields: creator, last-modified-by, revision count, timestamps. In the bundled sample some are filled in and some are empty. To find out what yours say, drop one of your own files — any .docx — into the box marked TRY IT ON YOUR OWN FILE. It never leaves your browser, and the fields it shows you are the fields that would have travelled with that file. The extractor is usually after your text, not your file's properties — but the whole file left your machine, and what a provider's tooling can read from it is no longer yours to limit.

Paste for control

So the working rule: paste when you want control, attach when you need the file. Pasting is the only way to see exactly what you hand it — nothing added, nothing dropped, no extractor deciding for you, no property fields riding along. Attaching hands the app an extraction decision, which is sometimes the right trade — structure, length, a format worth keeping — and when you take it, check what came through: ask for the two sentences that matter, quoted, before you build on the summary.

The reference entry, Loading the window, adds two moves: convert to Markdown anything you will reuse, and, in finance terms, hand over the trial balance itself, not the deck it was printed in.

Do this in ChatGPT and Claude

Pick the document: a few pages, with at least one table in it, and nothing you would not forward outside the firm — the file and its property fields both leave your machine. Then predict, before anything is sent: which will quote it more faithfully, the attached file or its pasted text?

In a fresh chat in each tab, attach the document — the attach button sits beside the message box, a paperclip or a plus; menus move, so if it is not there, look for the nearest thing — and send:

Quote the two sentences in this file that matter most, word for word, and tell me roughly how long the document is.

Read the reply against the file, not against your memory of it, and mark any quote whose words do not match. Then, in the same chat, ask for the table's first row, word for word, and read that against the file too. The length it gives is a rough cross-check, not a count — a completion over whatever arrived.

Then open another fresh chat in each tab and paste the document's text into the message instead — open it, select all, copy — and send the same request, then the same follow-up. Now you can read exactly what went in, in the box, before you send it — and if your own copy dropped the table, you can see that too. That is the whole rule. Compare the two replies against your prediction, and be careful about what one comparison can show: a different choice of sentences is not a cut, since two sends can pick differently from identical input. A cut is a quote whose words do not match the file, or something plainly in the document — the table's first row — that the attached reply cannot produce and the pasted one can. Neither would have shown in a summary. If both quote cleanly, you have learned that this extractor kept the sentences you checked — which holds for this file and this product, not the next one.

One thing to carry forward: a project's files ride in the same way — through the app's own reader, into the window of every chat inside it — so lesson 11's acceptance test is the one you just ran.

---

Check your understanding: why can pasting be safer than attaching, and when is attaching the right trade?

Check yourself first — then open one good answer+−

Pasting is the only way to see exactly what you hand over — nothing added, nothing dropped, no extractor deciding for you, no property fields riding along. Attaching hands the app an extraction decision; that is the right trade when the structure, the length, or the format is worth keeping — and when you take it, you check what came through before you build on it.

Your answer should have hit control on one side and structure on the other, with a check either way.

Use this rule every time you hand it a document. Next: Managing chats — the chat list is history, not memory.