When Knowledge Becomes a System: A Working Model

The ownership boundary and the source lifecycle now form one practical model of claude-obsidian: a user-owned vault receives preserved evidence, turns selected material into linked knowledge, and records how claims should be treated. This checkpoint connects those ideas rather than repeating them one by one. Its purpose is to give readers a test for any proposed change: who owns the state, what evidence supports it, what is being transformed, and what remains unknown.

A proposed change passes through four questions

Start with the ownership question. If someone asks the system to “add this to the wiki,” the phrase is incomplete until the target vault is known. The product package may contain a skill that can perform the operation, and the host may have loaded that skill, but neither fact identifies the user’s data. The selected vault is the place where the source, pages, ledgers, and user-controlled settings live. Runtime files may support the operation, but they are not a second vault with independent authority.

This first question prevents a category error before evidence is even considered. A correct page written to the wrong checkout is still a wrong result. A retrieval index built for one vault cannot be treated as an index of another. A host link that makes a skill discoverable does not give that skill permission to choose a destination by implication. Ownership is therefore the first condition of a meaningful transformation: the system must know whose state is in scope.

The second question is about the evidence anchor. What material was actually obtained, and can someone inspect it again? Local capture preserves bounded filesystem inputs by computing their byte identity and creating immutable raw copies. The visible inbox remains under user control. If a source has changed, the new bytes should be treated as a new state to capture or review, not as a reason to rewrite an old payload. For media or remote inputs, the system’s knowledge may stop at metadata or an inert plan when no approved extractor or external runner is available.

That distinction matters when a proposed page sounds more specific than the input. A file’s name and hash show that a file was identified and preserved. They do not show that an argument inside a PDF was semantically extracted. A URL plan shows that a destination passed validation and that a runner would be needed; it does not show that the page was fetched. The evidence anchor must match the claim’s actual origin, not the capability the user hoped would run.

The third question is about transformation. What durable value is added when a source becomes a canonical page? Ingest is not a compulsory paraphrase step. It classifies the input, checks relevant existing knowledge, and asks whether the source adds reusable synthesis, navigation, a decision, or a connection. If it does not, retaining the source and its record may be the more accurate result.