Skip to content

Container View

The container view is the second level of the C4 model. It shows the running parts of the Knowledge Operating System and how work moves between them. Each part has one job.

flowchart TB
    operator["Operator and local agents"]

    subgraph KOS["Knowledge Operating System"]
      router["Routing surface\nclassify and place incoming work"]
      promo["Promotion service\nreview, source refs, metadata"]
      registry["Registry\nsource manifest and promotion log"]
      validator["Validation check\nblocks unqualified promotion"]
      index["Retrieval service\ntwo separate indexes plus boundary checks"]
      evalsvc["Evaluation service\nthree stages and improvement loop"]
      store["Decision-support store\ncompiled packages and relationships"]
    end

    working[("Working store")]
    curated[("Curated store")]
    raw[("Raw session store")]
    private[("Private store")]

    operator --> router
    router --> working
    router --> curated
    router -->|selective| raw
    router -->|excluded| private
    working --> promo
    curated --> promo
    promo --> validator
    validator -->|pass| registry
    validator -->|fail| promo
    registry --> index
    registry --> store
    index --> evalsvc
    evalsvc -.review-gated improvement.-> router
    index --> operator
    store --> operator

Containers

  • Routing surface. Applies the intake router. Classifies each item as capture, working, evergreen, promoted, private, or archive, and places it in the owning store.
  • Promotion service. Prepares raw or working material for promotion. Attaches source references, a sensitivity label, and required metadata.
  • Validation check. A gate that a promotion must pass. It confirms source references, metadata, and boundary rules before anything becomes indexed knowledge.
  • Registry. The source manifest and the promotion log. The manifest records authority class and retrieval eligibility. The log records the reason, reviewer, and validation status.
  • Retrieval service. One operator workflow over two physically separate indexes. It runs health, update, verify, and search while preserving source ownership in each result.
  • Evaluation service. Runs synthetic and adversarial cases, schema-validated response scoring, and bounded pilot checks, then feeds a review-gated improvement loop back to the routing and guidance surfaces.
  • Decision-support store. Compiles validated knowledge into a package network with typed relationships, evidence objects, and claim candidates.

Why Two Separate Indexes

The retrieval service keeps the working corpus and the curated corpus in separate physical indexes. Search can include both, but results always name their corpus and authority class. This keeps source ownership visible and prevents a business-execution document from silently answering a curated-knowledge question.