Markdown wikis are flat and unstructured: the LLM has to grep, read whole files into context, and manage linking by hand.
Recently, yologdev/yopedia #139 committed to a 3-phase adoption of this exact decomposition (Phase A hybrid raw anchors, Phase B claims sidecar with per-claim source plus lineage, Phase C anchor-verifier lint), tracked at #140 against the schema sketch at this gist. Three independent agent-wiki builders converged on the same three primitives: hybrid raw anchors, a commit-keyed ingest ledger, and post-ingest completeness plus staleness checks.
The interesting fork is where braindb has already gone further. BrainDB lifts provenance into a typed Postgres schema: supports, contradicts, derived_from, with markdown reduced to fragment input and the DB as substrate. Yopedia's bet keeps markdown as the substrate and lifts only the claims layer into a sidecar the agent can read and lint against. Same diagnosis (markdown-is-flat), opposite architectural conclusion (DB-as-substrate vs. claims-sidecar-over-markdown).
Two questions on the seam:
-
With derived_from already in place, what stopped braindb from also storing the in-source span (offset plus quote hash) rather than only the source-entity edge? Cost, recall quality, or something the schema rejected on principle?
-
On the ingest side, is there a per-ingest ledger row separate from the entities table, so a later reader can answer "which run wrote this fact from which version of which source"? Or does that information live implicitly in created_at plus source?
The yopedia adoption is the cleanest public case so far where someone keeps markdown and tries to bolt the verification layer beside it. Worth a comparison against braindb's choice.
Recently, yologdev/yopedia #139 committed to a 3-phase adoption of this exact decomposition (Phase A hybrid raw anchors, Phase B claims sidecar with per-claim source plus lineage, Phase C anchor-verifier lint), tracked at #140 against the schema sketch at this gist. Three independent agent-wiki builders converged on the same three primitives: hybrid raw anchors, a commit-keyed ingest ledger, and post-ingest completeness plus staleness checks.
The interesting fork is where braindb has already gone further. BrainDB lifts provenance into a typed Postgres schema:
supports,contradicts,derived_from, with markdown reduced to fragment input and the DB as substrate. Yopedia's bet keeps markdown as the substrate and lifts only the claims layer into a sidecar the agent can read and lint against. Same diagnosis (markdown-is-flat), opposite architectural conclusion (DB-as-substrate vs. claims-sidecar-over-markdown).Two questions on the seam:
With
derived_fromalready in place, what stopped braindb from also storing the in-source span (offset plus quote hash) rather than only the source-entity edge? Cost, recall quality, or something the schema rejected on principle?On the ingest side, is there a per-ingest ledger row separate from the entities table, so a later reader can answer "which run wrote this fact from which version of which source"? Or does that information live implicitly in
created_atplussource?The yopedia adoption is the cleanest public case so far where someone keeps markdown and tries to bolt the verification layer beside it. Worth a comparison against braindb's choice.