Knowledge base governance

Knowledge Base Governance

Purpose

Allow useful knowledge to travel between Pi agents without synchronizing raw memory or allowing agents to manufacture shared truth.

Core rule:

Agents may propose. Authorized reviewers promote. History remains inspectable.

States

A backend may use different names, but preserve these meanings:

• proposed — candidate awaiting review;
• validated — accepted by an authorized reviewer;
• corrected — accepted replacement with explicit history;
• rejected — reviewed and not accepted;
• deferred — decision postponed;
• superseded — replaced by a newer version;
• stale — retained but unsafe for current use without warning;
• disputed — unresolved contradiction exists.

Promotion Rules

A shared proposal must include:

• bounded object and scope;
• proposition;
• future use;
• provenance and epistemic status;
• limitations;
• sensitivity/access scope;
• freshness or invalidation conditions;
• conflicts or related prior knowledge;
• requested reviewer.

Consequential inferred, estimated, sensitive, or cross-agent claims require human review. Repetition across agents is not validation.

Correction and Supersession

Never silently rewrite a validated proposition.

A correction should:

1. create a successor;
2. identify what it replaces;
3. preserve the previous wording and provenance;
4. record reviewer, time, reason, and changed scope;
5. mark dependent conclusions for review where relevant.

Contradictions

When evidence conflicts:

• retain both evidence references;
• mark the conflict explicitly;
• do not choose the newest, most popular, or most confident claim automatically;
• identify differences in time, scope, method, and authority;
• request clarification when the conflict affects future action.

Freshness

Freshness is contextual. Record either:

• a time-based review expectation;
• event-based invalidators;
• not_applicable with rationale;
• unknown when no honest rule exists.

Stale knowledge may remain historically useful but must not silently support a current consequential recommendation.

Sharing Boundaries

Use the narrowest applicable scope:

• session;
• agent/profile;
• project;
• bounded object/business;
• selected agents;
• owner-wide;
• public/reusable doctrine.

Never promote secrets, credentials, raw sessions, private client data, logs, or unrelated profile state. Do not assume that owner-wide means every runtime should receive the content in its prompt.

Cross-Agent Retrieval

Return bounded, task-relevant knowledge rather than dumping the complete store. Include compact provenance, validation state, scope, and freshness. Exclude rejected, forbidden, unrelated, and unauthorized material by default.

Reusable Learning

A local lesson that may improve the package itself should be proposed as a cognitive change, not silently added to doctrine. State source context, evidence, fitness environment, removed private details, overfit risk, intended scope, and reviewer decision.

Completion Check

• Promotion authority is explicit.
• Shared knowledge is not raw memory synchronization.
• Corrections preserve history.
• Contradictions remain visible until resolved.
• Freshness is represented honestly.
• Retrieval respects task and access scope.
• Local lessons do not become global doctrine automatically.