Knowledge base curation

Knowledge Base Curation

Purpose

Enable an agent to decide what deserves durable knowledge status. Storage follows understanding.

Core rule:

Understand the object before selecting knowledge. Admission is a judgment, not extraction.

First Gate: Understand the Object

Before proposing entries:

1. Bound the object or problem space.
2. Identify the people and agents who interpret or act on it.
3. Inspect relevant artifacts without assuming they explain themselves.
4. Ask the user or operator what those artifacts mean in practice.
5. Identify vocabulary, normal flow, judgment points, exceptions, tensions, and consequences.
6. Produce a correction-ready readback using templates/object-readback.md relative to the package root.
7. Invite correction.

Do not define canonical content until the user/operator has validated or materially corrected at least one readback.

Useful questions:

• What do you look at first?
• What would worry you?
• What would another agent misunderstand?
• When does this source mislead?
• What future decision does this support?
• Which exceptions matter more than the normal case?
• What must an agent never assume here?

Separate Four Layers

For every artifact or conversation, distinguish:

1. Raw material — what was provided or observed.
2. Literal content — what it explicitly says.
3. User/operator interpretation — what it means in practice.
4. Candidate knowledge — a compressed proposition that may improve future judgment.

Never silently collapse these layers.

Admission Test

A candidate must be reviewed on all dimensions:

Dimension	Question
Object	What bounded thing is this about?
Future utility	Which future judgment, action, question, or handoff will it improve?
Durability	Will it matter beyond the current session?
Provenance	Where did it come from, and can that source be inspected?
Epistemic status	Is it user-provided, observed, estimated, inferred, hypothetical, or a decision?
Scope	Which object, project, agents, people, market, or time period does it apply to?
Authority	Who may validate or correct it?
Freshness	What event or passage of time could weaken it?
Sensitivity	Is it shareable, restricted, local, secret, or forbidden?
Conflict	Does it contradict current or historical knowledge?
Compression	Is it reusable understanding rather than copied raw material?
Cost of error	What happens if another agent relies on it incorrectly?

Use the detailed rubric in references/admission-guide.md.

Admission Outcomes

Select one:

• discard
• session_context
• agent_local_memory
• evidence_only
• shared_proposal
• clarification_required
• restricted_proposal

Only shared_proposal or restricted_proposal proceeds to governance. Proposal does not mean truth.

Epistemic Labels

Prefer explicit labels:

• user_provided
• first_party_observed
• public_observed
• provider_observed
• provider_estimated
• inferred
• scenario
• decision

Do not turn confidence into provenance. A confident inference remains an inference.

Proposal Shape

Use templates/knowledge-proposal.md. At minimum record:

• proposition;
• bounded object and scope;
• future use;
• epistemic label;
• source/evidence references;
• limitations and conflicts;
• sensitivity;
• freshness or invalidation conditions;
• proposed validator;
• admission rationale.

What Usually Does Not Belong

• raw transcripts or session dumps;
• credentials, tokens, auth stores, or secrets;
• unreviewed model summaries presented as truth;
• temporary debugging state;
• duplicated documentation with no added interpretation;
• popularity, confidence, or repetition mistaken for validity;
• private context made shared merely because another agent might find it useful;
• claims with no bounded object or future use;
• application-specific fields generalized from one pilot without evidence.

Backend Gate

Choose or initialize storage only after:

• the object and future use are validated;
• at least one candidate has passed admission as a proposal;
• sharing and sensitivity boundaries are known;
• validation authority is identified;
• an existing source of truth is not the better answer.

The optional initializer creates a minimal Git/Markdown workspace. It is not required and must not be run without approval of its target and boundary.

Completion Check

• At least one readback was validated or materially corrected.
• Raw material and interpretation remain distinct.
• Every candidate has an explicit admission outcome.
• Shared proposals carry provenance, scope, sensitivity, and authority.
• Rejected candidates are not smuggled into canonical summaries.
• Backend choice did not precede understanding.