Direct answer
A source-preserving master export is a Markdown file that consolidates useful supplied material without flattening it into a shallow summary. It preserves source inventory, prompts, workflows, decisions, caveats, contradictions, limits, clean working versions, version notes and recommended next steps.
It is not the final customer product. It is a controlled source layer for later extraction, NotebookLM analysis, knowledge-pack building and QA.
The real problem
Raw source material often contains value that a simple summary would destroy.
A chat thread may include final outputs, but also the reasoning decisions, corrections, rejected options and caveats that explain why the output is trustworthy. A prompt file may include several versions, but the older version may only be useful as context. A research note may contain a useful claim, but also a warning that the claim needs verification.
If all of that is compressed into “key takeaways”, the downstream AI system may lose the boundaries that matter.
A source-preserving export keeps the usable context intact.
What it should preserve
A good source-preserving master export may include source inventory, file roles, important prompts, clean working versions, workflows, decisions, unresolved questions, contradictions, caveats, version notes, exclusions, buyer-question relevance and recommended next steps.
The aim is not to make the file short. The aim is to make it organised enough for the next stage to use.
Source-preserving vs summarised
A summary reduces material into a smaller explanation.
A source-preserving export organises material while keeping important distinctions visible.
Summaries are useful when the goal is quick orientation. Source-preserving exports are better when the goal is building a reusable knowledge product.
For knowledge packs, preserving structure is often more important than reducing length.
When to create one
Create a source-preserving master export when the source set includes multiple chats, prompts, drafts, research notes, transcripts, revisions or internal decisions.
It is especially useful when the pack will later go through NotebookLM derivative reports, evidence review, claims governance, customer-safe transformation or product packaging.
How to structure it
Start with a source inventory. Then group material by role: original sources, prompts, decisions, workflows, examples, claims, caveats, contradictions and final working versions.
Use headings that make retrieval easy. Preserve exact wording where it is important, but avoid dumping irrelevant material.
If a source is too large or too important to flatten, keep it separate or create a dedicated extraction card later.
What to avoid
Do not mix original source material with AI-generated expansion without labels. Do not hide contradictions because they make the file less neat. Do not remove caveats because they interrupt the flow. Do not rename or rewrite source identities in ways that break traceability unless the route specifically requires anonymisation.
A clean export should make the next stage safer, not merely prettier.
Example
A project may contain a long chat history where the final pack structure was developed through many iterations. A source-preserving export can capture the final decisions, the rejected alternatives, the core workflows, the caveats and the naming conventions so later stages do not have to reconstruct them from raw conversation logs.
When this does not apply
For a small, clean, low-risk source file, a separate master export may be unnecessary. But when context, rights, versioning, contradictions or workflow structure matter, a source-preserving export is a better foundation than a generic summary.
Soft next step
Before creating derivative reports, ask whether a future builder could understand the source set from the current files alone. If not, create a source-preserving master export first.