Decide which context should remain private and which context should become shared.

Decide early which context is yours and which belongs to the team.

This guide gives you a working method for splitting context into two categories: what stays with you, and what moves into the knowledge your team draws on. Applied consistently, that split does two things. It keeps your own drafts, hunches, and half-finished thinking out of the way of people who need clean answers. And it keeps the shared knowledge base free of anything that has not actually been checked. The rule that makes this work is simple to state and easy to skip: nothing becomes shared knowledge just because it exists. It becomes shared knowledge because someone with the authority to do so approved it.

A private note and a team decision are not the same kind of information.

Every person working on a project produces far more context than the project needs. You draft three versions of an argument before settling on one. You write down a guess about why a number moved, then rule it out an hour later. You keep your own shorthand for how you like to structure a brief, which has nothing to do with how the team should operate. None of that is wrong to create. Very little of it should reach the rest of the team as though it were settled. Most teams only have one shelf for context: everything goes into the shared space, or nothing does. Both extremes cause real damage. Pool every draft and guess into shared knowledge, and people start treating speculation as fact. Keep everything personal by default, and the team keeps re-deriving answers someone already worked out, or repeats a mistake someone already corrected.

Every piece of context has an owner and a stage, and both decide where it belongs.

The first axis is ownership. Is this piece of context useful mainly to you, or does it change how the team should act. A lot of what you produce while working, drafts, side calculations, your own notes on a task, is genuinely personal. It helps you think. No one else needs it to do their job. The second axis is status. Has this been checked, or is it still a proposal. A finding you noticed this morning is not the same as a finding the team has reviewed and decided to act on. Shared space should hold only context that is both team relevant and approved. Context that is team relevant but not yet checked should exist as a visible proposal, clearly labeled as unconfirmed, not folded into the team's working knowledge as if it were settled. Approval itself is a specific, attributable action. Someone with authority over that piece of work reviews the proposal, checks it against what else is known, and confirms it as the team's working answer. Until that happens, the finding stays attached to the person who raised it.

• Personal and unconfirmed: your default working state, drafts, hunches, and notes. Visible only to you.
• Personal and confirmed: a decision about your own work that does not affect anyone else. Stays with you.
• Team relevant and unconfirmed: a proposal. Visible to whoever you share it with, but labeled as not yet approved.
• Team relevant and approved: shared knowledge, available to the team across whichever AI surface they are working in.

Here is how the split plays out on a real project team.

Consider the Northstar team working on a product launch for its client, Meridian Labs. Maya is running a competitive review and notices that three competitors quietly dropped a legacy pricing tier last quarter. She logs this as a proposed finding, not a decision, because she has not yet checked it against Northstar's own numbers. Jordan, who owns pricing calls for this launch, reviews Maya's finding, checks it against internal margin data, and decides to drop the legacy tier for the Meridian Labs rollout specifically. Jordan marks that decision approved. From that point, what Alex and anyone else on the project sees is the approved decision itself: the legacy tier is gone for this launch, and here is why. That decision is now available to the team no matter which AI surface someone is working in when they ask about pricing for Meridian Labs. What stays out of the shared space is everything upstream of it that was never approved: Maya's spreadsheet of competitor screenshots, her early theory about a second pricing change that she later dropped, and the back and forth notes she and Jordan exchanged while working through the numbers. Those stay in Maya's personal space unless she chooses to propose them separately.

A finding is one person's evidence. A decision is the team's agreement about what to do with it. Only the second belongs in shared knowledge.

Most teams blur this line in a few predictable ways.

• Treating the shared workspace as the default home for everything, so drafts sit next to settled decisions with no way to tell them apart.
• Sharing a finding the moment it is written, before anyone has approved what the team should do about it, so the team starts acting on speculation.
• Never returning to personal notes to propose the useful parts, so a good insight stays stuck in one person's private space instead of reaching the team.
• Letting approval fall to whoever is fastest rather than whoever has authority over that decision, which produces confidence without accountability.
• Assuming that once something is shared it is fixed, instead of treating shared knowledge as something that gets corrected deliberately, by a person, the same way it was approved.

Use this checklist before you decide what to share.

• Keep personal: a draft argument or explanation you have not finalized.
• Keep personal: a hunch or guess you have not checked against other data.
• Keep personal: your own task notes, to-do lists, or shorthand for how you work.
• Keep personal: a conversation still in progress with no resolution yet.
• Propose for approval: a finding that changes what the team should do next.
• Propose for approval: a decision other people will rely on to do their own work.
• Propose for approval: a correction to something already in shared knowledge.
• Propose for approval: an outcome from a finished task that closes an open question.

Core keeps the proposal and approval step separate by design.

Core holds the context that accumulates while your team works: findings, corrections, preferences, decisions, and outcomes, captured as you go in whichever AI surface you are using, whether that is ChatGPT, Claude, Cursor, Codex, or Claude Code. New context starts in your personal space by default. Moving it into the knowledge the rest of the team draws on requires a proposal and a human approval step. Core does not add anything to shared company knowledge on its own, and it does not change what the team already knows without someone confirming the change. That means the shared layer other people see when they open their own AI tool only reflects what someone with the right authority has actually signed off on, while everything still in progress stays where it belongs, with the person who is working on it.