Direct answer
Choose a customer-safe pack when the buyer needs a public-safe derivative product with private sources, raw filenames and unlicensed attribution removed. Choose a full-source knowledge base only when source identity, provenance, attribution and traceability are approved deliverables and rights allow them.
If rights are unclear, default to the safer route: customer-safe, public-safe or hold until permissions are resolved.
The real problem
Knowledge-pack projects often start with more material than should end up in the final product.
A source set may contain private chats, client notes, paid reports, transcripts, filenames, URLs, author names, internal process prompts, AI research expansions, NotebookLM exports, source labels, working drafts and QA logs.
Some of that material is useful for production. Not all of it is safe or appropriate for buyer delivery.
The route decision exists because a knowledge pack can serve different purposes: a public-safe customer product, a private client handoff, an internal evidence-heavy archive, a licensed attributed knowledge base or a high-risk evidence-arbitrated pack.
Those routes have different rights, attribution and source-visibility requirements. If the route is not chosen first, the pack can accidentally expose material it should not expose.
Derivative use vs traceable source use
A customer-safe pack is mainly for derivative use. It gives the buyer useful concepts, workflows, prompts, caveats and operating guidance without making the original source archive part of the deliverable.
A full-source knowledge base is mainly for traceable source use. It keeps source identity, titles, dates, authors, organisations, URLs, filenames, source IDs or direct traceability where those details are approved and useful.
Both can be valuable. They are not the same product.
Use a customer-safe pack when
A customer-safe pack is usually the default route when the product is intended for public sale, Gumroad distribution or buyer upload into a private AI workspace.
Use this route when source rights are unclear, raw sources are not part of the deliverable, private filenames should not be exposed, attribution is not licensed, the buyer needs workflows rather than source audit trails, and public-safe wording is required.
The customer-safe route does not mean evidence disappears. It means evidence is transformed into a buyer-safe derivative format.
A strong customer-safe pack can still include definitions, workflows, caveats, prompts, evidence-aware wording and do-not-answer boundaries.
Use a full-source knowledge base when
A full-source knowledge base is appropriate when source visibility is part of the approved deliverable.
Use this route when source identity is useful and permitted, attribution is licensed or contractually allowed, source titles or URLs need to be preserved, the pack is internal-only or client-approved, provenance and auditability matter, or direct source traceability is required.
This route should not be used casually for public products. A full-source knowledge base carries more source value, but also more rights and privacy risk.
The route selector decision
Before building, run a route selector and build gate. The route selector should record the build route, evidence-risk tier, attribution mode, required pre-build gates, source budget, snapshot and freshness record, and a proceed, hold, stop or return decision.
Possible routes include customer-safe derivative pack, full-source attribution-preserving knowledge base, customer-safe plus evidence arbitration, full-source plus evidence arbitration, internal-only evidence-heavy pack, or stop/hold.
The key point is simple: do not build the pack before the route is decided.
Attribution modes matter
If attribution rights are unclear, use anonymous or generic source labels and the customer-safe route by default.
If public attribution is approved, some source detail may be preserved. If named-source attribution is licensed, a full-source route may be possible. If the use is internal only, a fuller source map may be appropriate.
The attribution mode should follow the rights, not the desire to make the product look larger.
When evidence arbitration is needed
Either route can require high-risk evidence gates.
Use evidence arbitration when the pack includes current platform, market, pricing, standards or trend-sensitive claims; contested public or commercial claims; legal, financial, health, safety, regulated or jurisdiction-specific material; or claims that could change behaviour or create buyer reliance.
If the claims ledger downgrades a claim, that decision controls the final pack, prompts, sales copy and Custom GPT or Skill behaviour.
Common mistake
The common mistake is assuming that summarised material is automatically safe to sell.
It is not. A buyer-safe derivative should be materially rewritten, bounded, caveated and non-substitutive. It should not expose confidential details, reproduce long passages, imply original source access or hide caveats.
Another mistake is assuming public sources are free to resell. Public availability is not the same as reuse permission.
When to stop or hold
Stop or hold when attribution rights are unclear and the product is public-facing, private filenames would be exposed, raw source archives would be included without rights, direct quotes are used without quotation rights, the pack implies resale or public bot rights that are not granted, or the build route cannot be stated clearly.
Holding is not failure. It is how the process prevents a rights or trust problem from becoming a product problem.
Soft next step
Before building the final pack, write the route decision in plain language: who it is for, what source visibility is allowed, what attribution mode applies, what claims need gates and what must not be included.