Which promised documents never got sent

It is the Monday after quarter close. Priya runs client services at a forty person agency. On her left screen is a shared Drive folder, Clients / 2026 / Q3, 340 files, sorted by last modified. On her right screen is Gmail, her sent mail, filtered to the eleven accounts she covers. Daniel, her ops lead, has asked a question that sounds like it should take ten minutes: over the last two months, what did we tell clients we would send them, and what actually went out.

She knows two of the answers already, because two clients wrote in to ask. It is the rest that worries her. Somewhere in eight weeks of threads are sentences like "I'll get the revised scope over to you Friday" and "sending the updated deck tonight", typed at the end of a paragraph about something else, on a Thursday, by someone who fully meant it. Some of those files are sitting in Drive right now, finished, named, never attached to anything. Priya has no list of them. She has two screens and a memory.

What Drive shows, and where it stops

Drive is an accurate record of files. It knows every file's owner, its creation and modification times, its full revision history, and exactly who it has been shared with, including external addresses. Advanced search will narrow by owner, type, folder and modified date. The activity panel on a shared drive shows a per file trail: created, edited, renamed, moved, shared, commented. On the Business and Enterprise tiers, an admin can pull a Drive audit log covering view, download and share events, including which external account did what.

That is more than most teams ever use, and every fact in it is a fact about a file that exists.

There is no column for a file that was supposed to exist. Acme_SOW_v3_FINAL_clean.docx was shared with ops@acme.com on 14 July: true, verifiable, and silent on whether that document is the thing Priya called "the revised scope" on 9 July. Drive also cannot distinguish sharing from delivering. A file dropped into a folder the client already has access to is technically shared and practically invisible, because nobody told them it was there.

What Gmail shows, and where it stops

Gmail search is genuinely strong, and most people underuse it. in:sent to:acme.com has:attachment after:2026/06/01 returns every message Priya sent that client with a file on it, in about fifteen seconds. has:drive catches the ones where she pasted a Drive link instead. filename:pdf narrows further. With the right admin role, Vault searches across the whole organisation's mail rather than one mailbox.

It stops in two places.

The first is that Gmail indexes text, not intent. There is no operator for "a sentence in which I committed to sending something". You can approximate it, ("I'll send" OR "will send over" OR "getting you"), and you will get hundreds of hits, most of them about calendar invites, introductions and things forwarded to legal. You are writing poetry into a search box and grading the results by hand.

The second is worse. The answer Priya wants is an absence. Search finds messages that exist. The document she promised and never sent has no message. There is no query for a hole, only for its edges.

Why the gap is structural

The two halves of this question are different kinds of evidence, and that is the whole problem.

A report is a query over rows. Google can report on anything that is a field, and both products do that well. The commitment side of this question has no field. Before any join is possible, something has to read the language and manufacture the missing row: this person, promised this thing, to that person, by roughly that date. That is not a reporting operation, and it is not a feature Drive or Gmail are missing. A file manager and a mail client that quietly inferred obligations from your prose would be a worse file manager and a worse mail client.

It also explains why the tools people reach for next do not close it. Automation platforms like Zapier and Make are excellent, and they are trigger based: something happens, then steps run. That shape moves a record forward from the moment of the trigger, so it can help with the next promise you make and cannot say anything about the sixty days that already happened. BI tools like Power BI with Copilot or Looker's conversational analytics are also strong, and they read databases and modelled sources. A sentence someone typed into an email body is not in the model. It is not a question they answer badly, it is outside the data they can see. The gap sits between those two categories, not inside either one.

What the join actually requires

The only clean key across both sides is the person. An email address appears in Gmail's To and Cc fields and again in Drive's sharing list, and it is exact on both. Everything else has to be resolved by meaning: "the revised scope" against Acme_SOW_v3_FINAL_clean.docx, inside a window running from the promised date to now.

So the join is one hard key and two soft ones: recipient, plus a time window, plus a description matched to a filename by what it means rather than by what it spells.

Then come the judgement calls, which are the reason this cannot be pure matching:

Is it actually a promise? "I'll send the deck Monday" is a commitment. "Happy to send the deck if that's useful" is an offer. "Sarah will send the deck" is somebody else's problem. Only reading tells them apart.

What counts as sent? An attachment counts. A Drive link pasted in a reply counts. A direct Drive share that fired a notification probably counts. A file quietly saved into a shared folder with no message at all is the interesting case, and a team has to decide for itself whether that is delivery or just storage.

Was it cancelled? "Ignore the scope, we're re-cutting it after Thursday's call" ends the obligation. That sentence is four messages further down the thread and it will never appear in any file record.

How you would answer it with Skopx

Skopx connects to Gmail and Drive alongside nearly 1,000 other tools and databases, and reads them with your own permissions. Connecting Drive and Gmail takes a minute each, and then the question gets asked in chat rather than assembled by hand.

The sentence Priya would actually type:

Go through my sent mail from the last 60 days and find every place I told a client I would send them a document. For each one, check whether an attachment or a Drive link with a matching name went to that person afterwards, and whether the file exists in Drive at all. Show me the ones that never went out, with the date I promised, who is waiting, the exact line I wrote, and the file if we have it.

The answer comes back as a list with citations: each row links to the message where the promise was made and to the file, or to its absence. The citations carry more weight than usual here, because the finding is an accusation about your own follow through, and the first thing anyone will want to see is the sentence.

When that question comes back every Monday, the next sentence is "make me a console for this", and Skopx builds one from the description. That is what internal apps are: a working console assembled from a sentence, reading live from Gmail and Drive rather than from a copy.

Standing over this question, it shows one row per open promise: recipient, promised on, days open, what was promised, and the quoted line. Each row carries its delivery state, sent with an attachment, sent as a Drive link, file exists in Drive but never went to them, or no file found anywhere. Filter by client or by whoever made the promise. One action per row, a follow up drafted with the file attached, behind a confirmation that shows you the recipient and the exact file before anything leaves.

The console holds no data of its own. Every time it opens it re-reads both sides and re-derives the list, so a promise fulfilled on Tuesday is simply gone on Wednesday, without anyone marking it done.

Honest limits

It reads language, so it gets language wrong. Conditional promises, jokes and commitments made by other people in threads you were copied on will land in the list. Treat it as a review queue, not a verdict.

It only sees what you connect and what your account is allowed to see. A promise made from a colleague's own mailbox, in a Slack DM, or on a call, is not in the evidence and will not appear.

Delivery by any other route reads as unsent. A file uploaded to the client's portal, handed over on a shared screen, or dropped in Slack, all look identical to never sending it.

Implicit deadlines are inferred. "Early next week" becomes a date, and that date is a guess made by a model reading your sentence.

It stores nothing, runs on nothing, and tells nobody. No overnight job, no alert when a promise passes ten days, no shareable link, no saved status. You open it and read it. The only thing that leaves the building is a message you clicked send on, after being shown what it was.

And it cannot tell you which of these mattered. A forgotten one page summary and a forgotten renewal scope sit in the same list at the same weight. Reading that list is still a person's job. Finding it no longer has to be.