Local Knowledge Graphs Need Source-Provenance Accountability, Not Note Counts Alone
Local knowledge graphs often advertise the number of notes or links they contain. Counts are useful, but they do not show whether a note preserves source identity, whether updates are idempotent, whether derived metadata is distinguishable from human-authored text, or whether graph edges can be traced back to analysis evidence. This workspace-grounded conceptual synthesis studies FileGraph through its README, type definitions, source-aware ingest route, service layer, analyzer, metadata parser, package manifest, and a prior AlexandrAI architecture map, then compares the design with provenance, markdown, catalog, and runtime-schema sources. The contribution is a source-provenance accountability ledger with seven stages: origin identity, note body, metadata header, source hash, analysis state, resolved graph edge, and derived artifact. The inspected workspace already has a strong provenance spine: origin records, comment-wrapped metadata, source indexes, queued analysis, graph rebuilds, and catalog/taxonomy artifacts. The conclusion is that local knowledge graphs should publish provenance state, not only note counts.
Introduction
FileGraph is a local-first markdown notes workbench that stores notes, graph-aware metadata, and derived graph artifacts in a vault. Its README describes direct note edits, source-aware upserts, graph rebuilds, retrieval context, and local analyzer enrichment [[cite:fgReadme]].
The question is how to make such a graph accountable. A graph can contain many notes and edges while still losing source identity, revision context, analysis status, or the boundary between human-authored markdown and derived metadata. This paper argues for source-provenance accountability.
Method
The study mode is workspace-grounded conceptual synthesis. I inspected FileGraph's local sources and fetched a prior AlexandrAI architecture map as untrusted context, then verified its relevant claims against current files [[cite:fgPrior,fgService]]. External sources were used to frame provenance, markdown, catalog, and runtime validation boundaries [[cite:w3cProv,commonmark,dcat,zodDocs]].
The analysis coded every evidence object by what it can prove: the ingest route proves request shape, types prove metadata fields, the service proves idempotent source indexing and artifact rebuilds, the analyzer proves candidate restrictions and fallback behavior, and the metadata parser proves where derived JSON begins and ends.
Results
The first result is that FileGraph preserves source identity as structured metadata. NoteOrigin records kind, external id, optional space key, source URL, and revision; the ingest route validates these fields; the service uses a source index to update an existing note rather than creating a duplicate when the origin key matches [[cite:fgTypes,fgIngestRoute,fgService]].
The second result is that derived graph state is explicitly separated from note text. Markdown files carry a FILEGRAPH_META_V1 comment-wrapped JSON header, analysis jobs move through queued/running/ready/error states, relation proposals are resolved only to known note ids, and graph/search/catalog/taxonomy artifacts are regenerated as derived files [[cite:fgMetadata,fgAnalyzer,fgService]].
Discussion
The useful maturity claim is not that FileGraph has notes, links, or a canvas. It is that each visible graph edge has a path back to a note body, source origin, metadata version, analysis state, candidate set, and artifact rebuild. That is why origin, source hash, analysis status, relation reason, and generated catalog matter more than raw graph size.
This aligns with generic provenance and catalog standards but stays local and practical. PROV provides a vocabulary for derivation; DCAT treats catalog metadata as a publication surface; CommonMark establishes the markdown-body boundary; Zod supports runtime validation at ingest. FileGraph integrates those concerns without requiring a remote database [[cite:w3cProv,dcat,commonmark,zodDocs]].
Limitations
This paper did not run FileGraph tests, ingest a new corpus, or benchmark large-vault performance. It reports source-level design evidence and a conceptual model.
A stronger future study should ingest a controlled set of source revisions, compare duplicate prevention and edge stability, and measure how often fallback analysis produces lower-quality relation evidence.
Conclusion
Local knowledge graphs need source-provenance accountability, not note counts alone. FileGraph already exposes the right evidence objects: origin records, source hashes, metadata headers, queued analysis, candidate-constrained relations, graph artifacts, catalog files, and taxonomy files. The next maturity step is to show the weakest provenance stage for every displayed note and edge.