Skip to content

Knowledge Operating System

A local-first architecture for turning valuable learning, experience, and captured knowledge into reviewed context for agents. It separates raw notes, working notes, curated knowledge, and private material, so agents retrieve useful material without treating every note as equally safe or settled.

This is the flagship of the pattern language. The reusable patterns in this site compose into one operated system: capture, candidate review, curation, relationship mapping, retrieval, evaluation, and human checking. The point is not to make every note searchable. The point is to make valuable past work usable for new problems, strategies, opportunities, and decisions while keeping raw and private material out of default retrieval.

For leaders

The problem in one sentence. Agents lose reliability when raw notes, working notes, curated knowledge, and private material all look equally searchable.

What the pattern changes. Captured material enters as a candidate, then moves through curation, approval, relationship mapping, indexing, retrieval, and evaluation before agents rely on it as context.

The failure it prevents. Private or unreviewed material entering an agent's answer as if it were reviewed knowledge.

What to ask your team. When an agent uses stored knowledge, can we see which material was reviewed, where it came from, and what still needs a human check?

The System In Six Steps

The whole system reads left to right: capture the material, classify it as a candidate, curate it with sources, promote it only after approval, connect it to related artifacts, retrieve it with authority labels, and evaluate whether the loop is useful enough for real work. Human review sits across the flow. It is what turns a candidate into approved knowledge, and what keeps retrieved context from becoming accepted truth by default.

flowchart LR
    capture["Capture<br/>material arrives"] --> candidate["Candidate<br/>classify and label"]
    candidate --> curate["Curate<br/>sources and boundaries"]
    curate --> promote["Promote<br/>approval and receipt"]
    promote --> connect["Connect<br/>related artifacts"]
    connect --> retrieve["Retrieve<br/>with authority labels"]
    retrieve --> evaluate["Evaluate<br/>score and improve"]

Why It Exists

The intended use is practical agent context. A person should be able to ask an agent for help with a new problem, strategy, opportunity, or decision and see whether the answer rests on captured material, curated knowledge, connected evidence, or something that still needs review.

Most knowledge systems fail at this because they treat search as the system. They index too much, so raw notes appear next to reviewed knowledge. They promote by hand, so provenance gets thin. They keep facts, assumptions, recommendations, and decisions in the same pile, so the agent cannot show how strongly a claim is held. They skip candidate review, so useful material either never becomes reusable or becomes searchable before anyone has checked it. They do not test retrieval, so quality drifts after the first clean demo.

The Knowledge Operating System, or KOS, treats knowledge as an operated workflow. It decides where material belongs before it is trusted, keeps candidate review separate from promotion, records receipts for approval decisions, preserves retrieval boundaries, connects evidence to claims, and uses evaluations to improve the loop.

The Six Layers

  1. Candidate intake. Treat captured material as a candidate first. The router names its source, sensitivity, lifecycle zone, owner, and retrieval eligibility.
  2. Source boundaries. Keep working knowledge, curated knowledge, runtime material, raw evidence, and private material in separate lanes. Private and raw material are excluded by rule, not by memory.
  3. Curation and approval. Move material from candidate to reviewed only when source references, metadata, sensitivity, reviewer intent, and an approval receipt are present.
  4. Governed retrieval. Search working and curated knowledge through one operator workflow while preserving corpus labels and authority class, so an answer can show where it came from.
  5. Relationship layer. Compile reviewed knowledge into packages, typed relationships, evidence objects, and claim candidates. This turns search results into usable decision support.
  6. Evaluation loop. Test retrieval and response quality with cases, scoring, and review-gated improvements.

System Context

The context view shows the public shape of the system. Names are generic. No private host, path, or store name appears.

flowchart TB
    user["Person making a decision"]
    agents["Local agents"]
    subgraph KOS["Knowledge Operating System"]
      route["Intake router"]
      review["Candidate review"]
      promote["Curation and promotion"]
      retrieve["Governed retrieval"]
      rels["Relationship layer"]
      evals["Evaluation loop"]
      decision["Decision support"]
    end
    working[("Working knowledge")]
    curated[("Curated knowledge")]
    raw[("Raw evidence")]
    private[("Private material")]

    user --> route
    agents --> route
    route --> working
    route --> curated
    route -->|selective only| raw
    route -->|excluded| private
    working --> review
    curated --> review
    review --> promote
    promote --> retrieve
    promote --> rels
    retrieve --> decision
    rels --> decision
    decision --> user
    evals --> retrieve
    evals -.improvement proposals.-> route

What This Section Contains

  • Pathway routing: routes work to the right level of intelligence, context, and review.
  • Safe lane: adds intake, fanout, and review for unclear or higher-risk work.
  • Knowledge ingestion workflow: moves captured material into reviewed knowledge before default retrieval.