Stub Files: Before and After Nutshell

The difference Nutshell AI makes is most visible in the SharePoint stub - the small file Squirrel leaves in SharePoint after moving the original document to Azure Blob storage. This article walks through what the stub looks like with and without Nutshell, and why that difference matters for search and Copilot discoverability.

Without Nutshell

When Squirrel archives a document without Nutshell enabled, the stub carries:

• The original filename
• The originating SharePoint site
• A Restore link that triggers the normal Squirrel rehydration flow
• Preserved file metadata (author, dates, sensitivity label)

What it does not carry:

• Any of the original document's content

SharePoint Search and Microsoft Copilot rely on document content to answer queries. With no content in the stub, they have nothing to index - the archived document effectively drops out of your organisation's discoverable knowledge base. Users searching for something in the document will get no result until they know to look in the archive and restore first.

With Nutshell

When Nutshell is enabled, the same stub additionally carries an embedded summary of the original document's contents. That summary is what SharePoint Search and Copilot index - it looks like ordinary text to Microsoft's indexing services, so it is treated like any other document body.

Result:

• A search for phrases the document discusses returns the stub as a hit.
• Copilot answers questions about the document using the summary as its source, and can link users to the stub (from which they can restore the full original if they need it).
• End users see the archived document in the same search results as live documents, differentiated only by whether or not they need to click Restore to work with the original.

What the summary looks like

The summary is 200–500 words of plain-language prose describing what the document is about, its structure, key points, and (where applicable) conclusions or recommendations. Length and depth are controlled by the configured mode; style and fidelity by temperature.

Sample summaries show real output from the same source document at each mode.

The archive companion copy

A second copy of the summary is stored alongside the archived document in Azure Blob Storage. This companion copy is useful for:

• Rebuilding stubs if the SharePoint index is ever regenerated
• Audit trails - the summary that was written back to SharePoint is preserved even if the stub is later deleted or replaced
• Bulk export or offline discovery workflows that read directly from your Azure Blob storage

Both the stub summary and the companion copy remain in your own Azure subscription. Nothing about Nutshell requires customer data to leave your tenant.

How the summary is laid out

The AI writes in markdown - sub-headings, bullet lists, the odd bold phrase - and the stub renders it as formatting rather than showing the punctuation. Where a summary used to run its bullets together into one paragraph with stray asterisks in the text, it now reads as a structured note. A Detailed summary of a long document is assembled from several passes, and those parts are numbered, so it is clear the summary continues rather than repeating itself.

The structure the AI wrote survives to the stub. A summary of a specification or a manual often comes back as a list of steps or clauses, and that is usually the right shape for it. Nutshell no longer flattens that into a single run of prose on the way through, and no longer strips lines it takes for commentary - a line naming a certification standard or a calibration seal reads as commentary to a machine and is a material fact to a reader. What the model produced is what the stub shows, minus the opening pleasantry and the closing offer of further help.

If someone moves the stub first

A summary is written into the stub a little after the file is archived, so a user can move or re-file the stub in between. Nutshell follows it: the summary is written where the document now lives, and the archive record is corrected to the new path. You do not have to put the file back for the summary to arrive, and re-filing a freshly archived folder does not cost you its summaries.

A stub that has been deleted rather than moved is a different case - there is nothing to write into, so the file is retired from the summarisation queue rather than retried indefinitely. The archived data itself is unaffected and is handled as an orphaned file.

Restore behaviour is unchanged

Adding Nutshell to a stub does not change what happens when a user clicks Restore. The stub still triggers Squirrel's normal restore flow, which returns the full original document from Azure Blob storage. The summary is a discoverability aid; the restore path is the same as it has always been.

See also

• How Nutshell works - where the stub-write step sits in the pipeline.
• Summarisation modes - controls the depth of what the summary captures.
• Redaction - how sensitive fields are stripped before the summary is written to the stub.

Need help? support@smikar.com.