Where to put documents so AI can actually use them

The question of where to upload a document seems administrative. It is actually strategic. Where a document lives determines when AI can access it, which sessions it appears in, and whether it creates noise in contexts where it is not relevant.

Most teams default to one of two approaches: upload everything to one place, or figure out where things go later. Both produce the same outcome — documents that are either missing when needed or present when they are irrelevant, and AI that has to work with the wrong context mix as a result.

The problem with uploading everything to one place

When all documents are uploaded at the org level, every session has access to every document. A session working on a specific client campaign has access to the brand guidelines, the standard pricing document, the internal process guide, the research report from the last client, and the transcript from last quarter's stakeholder interview.

The AI has to decide what is relevant for the current task from this full set. For clearly distinct document types, it usually decides correctly. For related documents — two research reports, a stakeholder interview, and a campaign brief — the decision is harder. Context that is genuinely irrelevant can still surface in output when it was available in the document pool.

The more documents exist at the org level, the worse this gets. Org-level scope is designed for documents that are always relevant. When it contains documents that are only sometimes relevant, it becomes noise.

The problem with upload-everything-to-project

When teams default to uploading everything at the project level, the problem runs the other way. Brand guidelines uploaded to project A are not available in project B. A stakeholder interview conducted for one campaign is not available for a second campaign that would benefit from the same context. The org-level brand knowledge has to be uploaded again for each project, or it is simply absent from that project's context.

This produces inconsistency across projects. Each project is operating with its own isolated document set. There is no shared foundation. Documents that should inform every piece of work have to be manually added to every project, and they frequently are not.

The distinction that resolves both problems

Org scope is for brand constants — documents whose content should inform every session across the organization. Project scope is for campaign or initiative-specific material whose content belongs only in sessions within that project.

The decision rule is straightforward: if a document would be useful context for any AI session the organization runs, it belongs at org scope. If it would be useful for some sessions and misleading or irrelevant for others, it belongs at project scope.

Documents that belong at org scope: brand guidelines, voice and tone guides, the structured brand brief, approved claims and messaging hierarchy, competitive positioning documents that reflect current strategy, company facts and product specifications.

Documents that belong at project scope: research conducted for this specific campaign, interview transcripts from conversations specific to this project's audience, concept development documents, drafts and feedback specific to this campaign's content.

Documents that can go either way: a stakeholder interview that surfaces broadly applicable brand knowledge belongs at org scope; a stakeholder interview conducted to ground a specific campaign's messaging belongs at project scope. A competitive analysis used to develop current positioning belongs at org scope; a competitive analysis conducted to inform one campaign's angle belongs at project scope.

How the platform handles scoped access

Copper Sun's platform maintains the distinction at the architectural level. Org-scoped documents are available as context in every session across the organization. Project-scoped documents are available only within the project where they were uploaded.

When AI retrieves context for a session, it draws from both layers — org-level documents as the persistent background and project-level documents as the campaign-specific layer on top. The scope is not something users have to manage session by session; it is determined at upload time and applied automatically from that point forward.

This means the setup decision — org or project? — is made once per document, at upload. Getting that decision right produces sessions where the AI has exactly the context that is relevant: brand constants always present, campaign-specific material available when in the relevant project and absent when not.

Frequently Asked Questions

What happens if a document is uploaded at the wrong scope?

Documents can be moved. If a document uploaded at the project level turns out to be broadly useful and belongs at org scope, it can be reuploaded at the org level. If a document at org scope is generating noise in sessions where it is not relevant, it can be scoped to the specific project where it matters. The scope decision is not permanent.

Can the same document be available at both org and project scope?

A document exists at one scope — either org-level or project-level, not both simultaneously. If a document is useful at both levels — for example, a stakeholder interview that contains both broadly applicable brand insights and campaign-specific research — the appropriate approach is to process it at org level for the broadly applicable content and note the campaign-specific content in the project's own context. In practice, most documents are clearly one or the other.

How does AI decide which documents to retrieve for a given session?

The platform uses vector similarity to match document content to the current session's topic and questions. Documents uploaded at the relevant scope are candidates; documents outside that scope are not. Within the candidate set, the platform retrieves chunks that are most relevant to what the session is working on, with a relevance threshold to avoid surfacing loosely related content. The intent is that AI receives the context that is actually useful, not everything that is technically available.

Is there a limit on how many documents can be uploaded at org scope?

There is no hard document count limit, but practical limits apply. The more documents exist at org scope, the broader the candidate pool for any given session, and the more important it is that each document genuinely belongs there. The right question is not "how many documents can I upload?" but "does this document improve AI context for most sessions, or does it only matter for specific projects?" Use org scope for the first category and project scope for the second.