0025 — Knowledge is company-wide; projects control access to evidence

Decided. A claim in the knowledge layer has no permission column. Every claim is visible to everyone at Flow. Projects stay the only thing that controls access, and what they control is the raw material — conversations, files, decisions — not the conclusions drawn from it.

Whether a project feeds the knowledge layer is settled when the project is made. project.contributes_to_knowledge starts as true, scratchpads are always excluded, and a legal hold forces it to false. That is the whole of it.

Promotion is a separate thing. It decides how much a claim is trusted, not who can see it. See 0027.

Alternatives

Give each claim the permissions of the project it came from. The obvious safe default.

Rejected because it produces a knowledge base that cannot answer anything across teams. It would rebuild the walls this service exists to see over. A claim drawn from four different projects also has no sensible set of permissions to inherit.

Make contributing opt-in. This feels safer.

Rejected because the knowledge base then stays empty. Defaults decide what happens, and an opt-in company knowledge base is a company knowledge base nobody has.

Use practices as access boundaries — marketing sees marketing, engineering sees engineering.

Rejected because it rebuilds the same wall one level up, and the connection between two practices is often the valuable one.

Why

• The scratchpad already asks the right question. Moving a conversation out of your private scratchpad and into a shared project is an act of sharing people already understand. Reusing that moment as the consent means there is no new control to explain.
• A conclusion is not the evidence for it. "Friday deployments correlate with rollbacks" is a conclusion. The conversation it came from is not. Publishing the first while protecting the second is the whole point of the pointer model in 0024.
• Practices classify, they do not authorize. They exist for routing reviews, filtering search, and scoping reports.

Consequences

• Citations are the only place project permissions touch intelligence. A citation records which project it came from. Someone with access to that project sees the quote. Everyone else sees a pointer — the practice, how recent it is, who to ask — and never the text.
• Search has two paths. Searching claims needs no membership lookup and can be cached across users. Searching raw text is filtered by project inside the SQL, never filtered after ranking. Filtering afterwards leaks the existence of things you cannot see through the result count. Keep answering 404 rather than 403, so an id cannot be used to probe for what exists.
• Claim text has to contain no personal data by construction. That is what keeps it off the PII topics under 0005.
• Deletion reaches the whole company. An approved redaction in workspace publishes an event, and intelligence withdraws or challenges every claim citing that source. This path needs a test, because it is the one that matters and the one nobody exercises by accident.
• Turning contributes_to_knowledge off stops future derivation. Taking back what was already derived is a deletion-style action, not a flag change. Turning it back on is the same command with true: intelligence observes again from that event.

Source: docs/decisions/0025-company-scoped-knowledge.md↗.