Disclosure: Software Sausage is our product. Blake McCarn did not sponsor, review, or endorse this article. AI tools helped draft and edit it; the evidence boundaries are stated below.

The graph is not the trust layer

Blake McCarn's Paperless Knowledge Graph is not interesting merely because it lets someone chat with scanned documents. The stronger idea is that retrieval leaves evidence behind and can refuse to answer when that evidence is weak.

This is a source review, not a field test. We reviewed McCarn's case study, inspected the current public repository, and checked related projects. We did not connect the stack to his private archive or reproduce its reported accuracy, scale, speed, or cost.

The pipeline

Paperless source documents
  → baseline OCR → selective enhanced OCR
  → classify → extract → verify → relate
  → graph + vector + keyword indexes
  → quick | deep | timeline | strict query
  → cited answer + claim ledger + trace

McCarn reports more than 800 documents, roughly 7,000 graph nodes, 25,000 relationships, and 6,000 searchable chunks. Those are author-reported results, not Software Sausage measurements.

Five decisions worth carrying into other systems

1. Preserve the source of truth

Paperless remains the document authority. Enhanced OCR runs as a companion layer, so the archive is not held hostage by the AI pipeline.

2. Compare identities, not counts

The freshness check compares exact document ID sets and hashes across Paperless, Neo4j, and vector chunks. Equal counts can still conceal one missing document and one stale replacement.

3. Route by question shape

Entity lookups use the graph. Deeper questions combine vector, keyword, and graph retrieval. Timeline mode keeps dates explicit. Strict mode can refuse weak evidence instead of filling the gap with confident prose.

4. Leave inspectable artifacts

The repository includes evidence-pack, claim-ledger, trust-dimension, trace, and answer-repair paths. A separate model pass may catch inconsistencies, but it is not independent ground truth. The verifier can share the drafter's blind spots.

5. Put model routing outside the app

LiteLLM centralizes model aliases, credentials, limits, and cost visibility. That reduces provider coupling; it does not eliminate the need to test authentication and response behavior end to end.

What the public repository proves

The source contains the advertised evidence helpers, exact-drift audit, API smoke checks, and an evaluation harness for fixed questions. Its published container workflow is green, but it builds images rather than gating publication on those checks.

The Python dependency file is mostly unpinned. The README says MIT, while the repository had no LICENSE file and GitHub detected no license when we reviewed it. Until that is corrected, treat the code as publicly readable rather than reusable MIT material.

Most importantly, no public fixture establishes the accuracy implied by its medical, tax, financial, and legal query modes. Strict refusal and visible citations are useful controls. They do not replace opening the source.

The wider process is consistent

Portable Brain applies the portability boundary to knowledge work: plain Markdown, YAML, and relative links remain useful without a runtime, while source evidence stays separate from synthesized notes. We ran its current test suite locally: 75 tests passed. A full-repository lint also found one executable-bit issue in an optional Paperless integration outside the project's narrower CI lint scope.

McCarn's Herdr write-up separates terminal topology from provider logic: one worktree per implementation, distinct review and test surfaces, and status labels used for routing rather than proof. His LiteLLM operating note makes a similar boundary explicit for model traffic, budgets, and credentials.

The field test we should run

Build a synthetic, non-sensitive Paperless archive with ordinary text, tables, handwriting, duplicate entities, contradictory dates, and one deliberately stale index. Freeze a dozen questions and score source coverage, exact-value accuracy, unsupported claims, refusal behavior, elapsed time, and model cost.

Then remove one document, add another so the total count stays equal, and require the exact freshness check to catch the swap.

That would turn a strong architecture story into a reproducible recipe. Until then, the honest label is community source review.

Read the complete review and follow the proposed verification run at Software Sausage.