SA Knowledge Base
Eight years of writing has produced a corpus that has outgrown the way it is published. 208 articles, eleven scored assessments and two books in progress all describe one connected body of knowledge, and the only way in is currently a reverse-chronological list. This is the fix, in progress: one queryable graph over everything, so an architect — or an agent — can ask a question rather than browse for it. The graph below is live; the natural-language query layer on top of it is not built yet.
What goes in it
- 208 engineering deep-divesThe blog, 2018 to now. Internals, trade-offs, and production failure modes.
- 11 radar assessmentsThe Architecture Radar — scored decisions with the evidence attached.
- 2 books in progressHLS-SA and SA-AI, chaptered and cross-referenced.
- Reference architecturesThe diagrams and decision records that recur across engagements.
The graph, as it stands today
This is real and built from the corpus on every push — not a mockup. It currently carries the deterministic layer only: relationships I wrote by hand as links, tags and scorecards, recovered exactly. No model has inferred anything here, which is why every edge can name the document it came from.
Loading the graph…
Document Technology Topic Assessment
Click any node to re-centre on it; click the centre node again to open it. The data is graph.json, built by the pipeline described here and committed by CI — so what you are looking at is a file, not a service.
Why a graph rather than a search box
The blog already has search, and search is the wrong shape for this problem. The questions worth asking are relational: what did I conclude about Iceberg catalogs, and which assessments depend on that conclusion? — where does the medallion critique in the techniques assessment connect to the data-mesh field notes? Keyword search returns documents. What you actually want is the path between them.
Which is the same argument I made about code knowledge graphs, and it holds here for the same reason: the structure already exists — cross-links, shared entities, scored axes, publication dates — and flattening it into a text index throws it away.
graph LR A["blog/*.html
208 articles"] --> AD["Adapters
normalise to one doc shape"] C["scorecards.json
11 assessments"] --> AD AD --> T1["Tier 1 deterministic
links · tags · scorecards"] T1 --> M["Merge + typecheck
retract dead claims"] M --> G[("graph.json
283 nodes · 1302 edges")] G --> V["Sigma.js
neighbourhood view"] G --> D["Public download
CC BY 4.0"] T2["Tier 2 extraction
NER or LLM over prose"] -.->|"not built"| M G -.->|"not built"| Q["Natural-language query"] G -.->|"not built"| MCP["MCP endpoint for agents"]
Solid lines run on every push; dotted lines are honest about what does not exist yet. Everything left of graph.json happens in CI, and everything right of it is a static file being read — which is why there is no service here to operate.
Design commitments
Three things I will hold to, because they are the ones usually traded away first:
- Every edge cites its source. Each relationship records the document it came from, which tier produced it and when. A claim that cannot be traced back to a document is worse than no claim, because it launders an assertion into something that looks authoritative and cannot be checked.
- The graph is machine-readable and public. The same discipline as scorecards.json — if you want to argue with the structure, take the data.
- Dated claims stay dated. A 2019 conclusion about BigQuery is period-accurate, not current, and the graph has to carry that distinction or it will confidently serve stale architecture advice.
The architecture behind it — and why a corpus this size calls for a build-time graph shipped as a static file rather than a GraphRAG platform — is written up in Build-Time Knowledge Graphs.
Status, plainly: the graph above is live and rebuilt on every push, but it is the deterministic layer only — links, tags and scorecards. The extraction tier (entity and relation extraction over prose) and natural-language query are not built yet, and this page will say so until they are. The radar methodology and the machine-readable scorecards exist partly so the graph has something structured to ingest.
In the meantime
The corpus is navigable by hand: Start here groups 25 articles by the question you arrived with, Topics clusters everything into 16 themes, and the Architecture Radar carries the scored decisions. For agents, llms.txt and llms-full.txt already expose the full corpus, and every article serves markdown at its own URL with an Accept: text/markdown header.