Direct answer
Before building a knowledge pack, generate derivative reports that expose the source set from different angles: per-source extraction cards, evidence ledger, claims table, workflow maps, contradictions and boundaries, retrieval tests, concept maps, playbooks, prompt patterns and a final NotebookLM bridge export.
These reports are not the final customer package. They are build intelligence for the Stage 03 knowledge-pack builder.
The real problem
A knowledge pack fails when it moves from raw sources to polished output too quickly.
NotebookLM can summarise a source set, but a summary alone is usually not enough to build a reliable product. A useful knowledge pack needs source roles, evidence strength, reusable workflows, claims boundaries, contradictions, retrieval cues, prompt patterns and caveats.
Without derivative reports, the builder may treat all sources as equally authoritative, lose caveats, turn examples into universal claims, hide contradictions, forget which claims need verification or ship a report that should only have been used internally.
Source, derivative report and final pack
Original sources are the raw or supplied material.
Derivative reports are intermediate outputs generated from those sources to help with extraction, evidence review, workflow mapping, retrieval testing and build handoff.
Final knowledge-pack files are the curated deliverables that the customer or internal team will actually use.
That distinction matters. A derivative report can contain source traces, unresolved contradictions, recheck notes or working claims that should guide the final build but not automatically become part of the customer ZIP.
Recommended report stack
1. Per-source extraction cards
Start with per-source extraction cards for the most important sources. A good card records what one source contributes: scope, authority level, core thesis, key claims, examples, caveats, risks, contradictions and must-preserve items.
Use this when a source is central to the pack or contains workflows that should not be blended into a generic summary.
2. Evidence ledger
The evidence ledger records evidence before it becomes public claims. It should distinguish evidence from claims and capture source reference, evidence type, supported claim, confidence, caveat, freshness risk and final-use notes.
This report stops the final pack from sounding more certain than the source material allows.
3. Claims table
The claims table turns source material into a structured list of claims, principles, examples, contradictions and open questions. It creates an inventory for later review. It does not automatically approve claims.
4. Workflow and decision map
The workflow map extracts the practical operating logic inside the sources: repeatable workflows, decision points, inputs, outputs, triggers, exceptions, risks and handoffs.
A saleable knowledge pack should not only explain ideas. It should help the buyer do useful work.
5. Contradictions and boundaries report
This report records tensions that should not be erased. It should capture factual conflicts, interpretation conflicts, workflow variants, freshness conflicts, overclaim risks, rights concerns and known gaps.
A cleaner synthesis is not always a better synthesis. Some contradictions should travel as useful variants or caveats.
6. Retrieval test set and metadata map
This report creates realistic buyer questions and maps them to expected source sections, exact terms, semantic variants, answer types, caveats and pass/fail criteria.
It helps check whether the final pack will be retrievable, not just readable.
7. Concept, metaphor and relationship maps
Use these when the pack is concept-heavy or needs teaching language. They identify parent concepts, sub-concepts, metaphors, distinctions, anti-examples and dependencies.
8. Final NotebookLM bridge export
This is the final Stage 02 bridge into the build stage. It gives Stage 03 a coherent, source-grounded draft that preserves caveats, evidence boundaries, workflows, prompt recipes and retrieval cues.
It is a handoff source for the builder, not a substitute for the final complete knowledge-pack build.
When to run the full stack
Run the fuller report stack when the pack will be sold, reused, uploaded into AI tools, used in a Custom GPT or Skill setup, or built from numerous or inconsistent sources.
For a smaller low-risk pack, you may not need every report. At minimum, consider evidence, claims, workflows, contradictions and the final bridge export.
When to reduce reports
Do not generate reports mechanically just to create more files. A small source set with one clear purpose may need fewer derivative outputs. The decision should follow the route selector: product purpose, source risk, buyer use, rights posture and evidence complexity.
Common mistake
The common mistake is adding NotebookLM prompt files as NotebookLM sources. The Stage 02 prompt files are instructions. They should be pasted into NotebookLM to generate outputs, not treated as source material.
Another mistake is shipping derivative reports directly to the customer. Derivative reports may be useful, but some contain internal labels, source traces or unresolved decisions. They should be reviewed before any customer-facing package includes them.
Soft next step
Before building the final knowledge pack, list the derivative reports you actually need. Ask what evidence must be preserved, what claims need control, what workflows must be mapped, what contradictions should travel and what questions the final pack must answer reliably.