Knowledge check Choose an answer to see why it is right or wrong.
JavaScript is off, so every explanation is shown at once.
01 Why does a product spec, a standard, or a piece of learn content project into one canonical model (Cogitave's Core is the worked example) as a typed node instead of living in its own store?
Because the canonical model is a single graph - docs, the IDP, governance, compliance evidence, and infra are all projections of it, so a human's UI and an agent's MCP client query the exact same model instead of separately drifting copies. Correct. The architecture spec states this as the thesis: never separate stores, always projections of one graph. Because storing every file in one repository is cheaper than paying for several repositories. Incorrect. Cost of storage is not the reason given anywhere in the spec; the reason is a single queryable model, not a single repo. Because the Model Context Protocol requires all content to live inside one server process. Incorrect. MCP is the query surface the canonical model exposes; it does not mandate a single-process content store, and nothing in the MCP interface makes that claim. 02 A new standard lands and later shows up in docs_fetch and docs_search results. What actually made that happen?
Its source blob was hashed and parsed into a typed node with a stable UID and a content-addressed contentHash, linked into the closed edge set, and the catalog/graph/search materializations were rebuilt as pure functions of the graph and published behind a new content root. Correct. That is the ACQUIRE-to-PUBLISH pipeline plus the identity scheme described in the architecture spec. The Markdown file was copied as-is into a separate database that the MCP server queries directly. Incorrect. There is no separate database; the catalog, graph store, and search index are derived, rebuildable materializations of the one graph, not a second store. Someone re-typed its title and summary into a spreadsheet that feeds the search box. Incorrect. There is no manual re-entry step; the pipeline is what turns the blob into a node, automatically and reproducibly. 03 The knowledge-propagation standard says a canonical SLO ladder must never be retyped as prose in a second document. What is the rule, and why?
One owner document holds the value; every other artifact cites it (an xref, a relative link, or an include) rather than restating it, because a plain-prose restatement carries no edge and is invisible to every graph walk - exactly the failure class that let an ADR carry the wrong SLO ladder. Correct. This is the cite-not-restate rule: 'the ADR decides, the standard carries the number, everything else points.' Numbers may be freely retyped as long as they were correct at the moment they were written. Incorrect, and the standard says so directly: an unmarked restatement is a defect even while its value is still correct, because correctness today is not propagation tomorrow. Numbers must be retyped in every document, because an agent cannot follow a link to another file. Incorrect. An agent follows an xref or resolves a resource URI over MCP exactly as readily as it reads inline prose; that is the whole point of a queryable graph. 04 The knowledge-propagation standard states that its own fact-drift scanner's first CI run is expected to fail. What does that mean?
No Core server runs yet, so the registry and scanner operate on the mirror as plain files; the audits that motivated this design found real unrepaired restatement drift, and that first failure is the gate proving itself, not a defect in it. Correct. This is the standard's own Day-0 honesty note - stated up front rather than hidden. The scanner itself is broken and should not be trusted until someone fixes it. Incorrect. The scanner is deterministic and read-only by design; the expected failure is about real drift it correctly finds, not a bug in the tool. Cogitave Core is already deployed in production and is actively catching live drift there. Incorrect, and it overstates status. Core is a specification and architecture today; the registry and scanner run over files on the mirror, not against a live running graph.