Knowledge

Knowledge is reference material: documents that already have the answers, made available to agents so they can use the detail when it is relevant.

It is the answer to “this is written down somewhere else already”. An API contract, a data dictionary, a partner’s integration guide, a compliance standard, the spreadsheet that defines your product’s tiers.

Why it is not instructions

Instructions are rules that apply every time. Knowledge is detail that applies when it comes up.

The practical test is length and shape. “Money is always integer minor units” is a rule, and belongs in instructions. A forty-page payment provider integration guide is not a rule, and putting it in instructions would attach it to every piece of work whether or not it is about payments.

Content in the wrong one is the most common way to be surprised by an agent’s output. Instructions, Knowledge, Policies and Specs covers the full four-way split.

Where it lives

Knowledge exists at the organization, the team and the project, and narrows as it comes down.

Put a document at the level where it is relevant. An industry standard your whole company works to belongs at the organization. A partner integration only one team deals with belongs to that team. A schema specific to one codebase belongs to the project.

Putting everything at the organization is the tempting mistake. It does not break anything, but it makes the pool of reference material larger and less specific for every project you have.

What to add

The good candidates share a property: they are things a competent new engineer would be handed and told to read before touching something.

• Specifications and contracts you have to conform to.
• Domain reference: glossaries, code lists, taxonomies.
• Third-party documentation for services you integrate with.
• Existing internal documents that would otherwise be retyped into a spec.

The poor candidates are things that change faster than you will remember to update them, and anything that is really a rule wearing a document’s clothes.

Who can manage it

Members can add, edit and delete knowledge, alongside admins and owners. Viewers can read it.

This is a deliberate split from policies, which members can read but not change. Reference material is part of doing the work; governance is not. It also means the person who discovers that a document was missing can add it, rather than filing a request with an administrator.

Keeping it honest

Stale reference material is worse than none, because it is confidently specific.

Knowledge does not expire on its own and nothing warns you it has aged. When you replace a provider, retire a standard, or change a schema, the old document is still sitting there being read.