Buckets exist at one of four scopes: workspace (company-wide defaults that apply across all projects), project (standards shared across a product line or set of repositories), repo (conventions specific to one repository), or user (private notes for the signed-in person where supported). The resolver prefers the most specific relevant scope when multiple buckets could apply. If your workspace has a general "Incident response" bucket but your critical infrastructure repo needs to diverge, you can create a repo-scoped bucket with the same name that overrides the workspace version for that repository. The specificity rule means readers get the right answers without duplicating articles across every scope. Override is the exception, not the default — use it when a repo really has an exception to the company standard, not because the article title sounds useful.
The decision to split a bucket or keep articles together hinges on whether your readers have fundamentally different needs. If engineers and customer success both read the same article about onboarding but find themselves skipping to different sections every time, that is a sign to split. If one bucket covers both "SQL query patterns" and "Transaction isolation levels" and half your readers would want to abolish one article while the other half need it, the topics have drifted far enough to deserve separate buckets. The clean test is simple: I know which bucket to look in within five seconds. If you find yourself wondering whether an article belongs in "Infrastructure" or "Deployment", the bucket structure is unclear and probably too granular.
Merging buckets is less costly than it feels. Two buckets that are so cross-referenced that every article in one cites at least one in the other should probably be one bucket. When no one on the team can agree which bucket a new article belongs in, the taxonomy is too fine-grained. When the smaller bucket keeps shrinking as articles get reorganized, it is a candidate for merger. Articles keep their identity even after a merge — they do not lose metadata or citations — so consolidation is largely invisible to readers who already know the article they need.
Bucket names show up in the Knowledge sidebar and in citations across your knowledge base. Avoid clever or abbreviated names. The test is whether someone unfamiliar with your team can guess the bucket from the article topic. "Security" is clearer than "Lockdown". "API contracts" is clearer than "Interfaces". Names that hint at inside jokes or historical reasons will confuse new teammates.
Most workspaces start with three to five buckets and grow as the team finds reasons to split. Do not pre-design the perfect taxonomy on day one. You create buckets using the "New bucket" dialog in the /knowledge interface, or implicitly when you import a source and assign it to an inferred bucket. As your knowledge base grows, watch for the patterns that emerge — when you are reaching for a bucket and it does not exist, when you are reading across multiple buckets too often, when a single bucket is becoming unwieldy — and act on those signals. Good bucket design is responsive, not prophetic.