Reviewing knowledge

Everything a machine writes into Project Knowledge arrives as a candidate and waits. This page is the human side of that queue: the project's Knowledge tab, and what an owner can do there.

The Knowledge tab

Every entry with its state, kind, title, body, provenance, and timestamps, filterable by state and paginated.

Each row also shows how many independent issuers support it. A state label on its own says "trust this" without saying why; the count says what the trust rests on. A candidate at zero reads as "nothing has confirmed this yet" rather than as an unexplained label. That number is computed the same way the promotion transaction computes it, so what you see is what promotion acts on.

Confirming a candidate

The confirm control appears only on candidate rows, and only for an owner. The other states are not waiting on a decision.

Confirming records your support, promotes the entry, and writes the ledger row in one transaction. The dialog says plainly that the action cannot be undone and is recorded - the audit row marks it as an owner override, so the ledger later shows the entry was promoted because a person decided, not because signals accumulated.

An owner's confirmation promotes on its own; see How knowledge earns trust for why that is an exception to K rather than a hole in it.

If confirming appears to do nothing, check whether the entry has a contradiction on it. An unexpired contradiction blocks promotion on every path, including an owner's, and there is no UI to clear one. It expires with the window - 30 days by default.

Where candidates come from

Two sources, and neither can produce anything but a candidate.

• learn, called by an agent.
• Automatic extraction. When a thread reaches closed or answered, its conversation becomes eligible for distillation, and a periodic sweep drafts candidates from it.

Both write paths run the project's redaction denylist first. Spans matching a configured secret or PII pattern are removed, not masked - masking would still record the shape and position of the secret and would imply the redaction was lossless. The denylist is applied on extraction and on learn, because a person pasting a lesson can paste a secret along with it.

The proposal queue

/knowledge/proposals holds what the reflection proposer drafted. When an error signature recurs - across 2 or more distinct agents, or 3 or more times, inside a 7-day window - it is turned into a proposal.

A proposal is an argument, not an edit to rubber-stamp, and it is shown as one:

• the evidence it was drawn from,
• a hypothesis,
• the disconfirming condition that would show it is wrong,
• and the concrete change it suggests.

Errors with no usable signature are dropped rather than pooled, so "no detail" never accumulates into a false pattern.

Nothing here is ever applied automatically. The dashboard queue is the only surface a proposal has; none of it is sent to an agent.

Approving registers a candidate, not a trusted entry

The button reads Adopt as candidate, the confirmation spells out that it is not trusted, and the resulting status badge says Adopted (candidate).

This is deliberate, and it is the difference between two clicks that look identical:

• Confirming on the Knowledge tab is an owner reading one specific entry and judging it. That promotes.
• Approving in the proposal queue is a click on one of a pile of machine-generated drafts. If that minted trusted entries, "I reviewed the queue" would in practice become automatic approval, and a single pass through it would be a K=1 bypass of the whole trust model.

Same person, same button shape, different density of judgement - so different results. An adopted proposal still has to earn promotion the normal way.

Playbook versions and rollback

Changes to a project's playbook are kept as an append-only version history.

Rolling back does not overwrite anything: it writes a new version whose content equals an older one. The control shows which version you are going back to, a diff of current against target, and whether the target actually differs at all, then asks you to confirm. The served body is always the newest version's content, falling back to the project's stored RELAYROOM.md before anything has been versioned.

Purging knowledge from a thread

Deleting a thread does not remove the knowledge distilled from it. That knowledge is a separate copy. /knowledge/settings has an owner-only action to remove it explicitly.

The confirmation states two numbers, because a purge does two different things:

Collapsing those into one figure would mislead the person confirming an irreversible action. The preview runs the same function in dry-run mode, so the numbers in the confirmation are exactly what the purge will do.

The thread picker lists only threads that actually produced knowledge, chosen by subject rather than a pasted id.

Expiry

An entry can carry an expiry. recall stops returning it the moment it passes, and a sweep then moves it to retired and writes an audit row, so the state on disk matches what agents are being told.

Garbage-collecting old candidates is a separate question that needs a retention policy, and there is no default for one yet, so nothing sweeps them today.