The industry's own diagnosis is that threat modeling is a fairly subjective process producing static, siloed, context-poor documents. This site publishes two things instead: models built as machine-readable graph data, and — its actual differentiator — the audit that says which parts of a threat model turned out to be wrong.
Eleven linked threat models, live at ThreatModCon 2025 · one threat model validated line-by-line against its code the next day · seven white papers · why this site is not a neutral vantage point →
Everyone publishes threat models. Almost nobody publishes the audit that says which parts of theirs turned out to be wrong. These two pages are why this site exists.
"One model answers what could go wrong here. Eleven linked models answer what does this line of code put at risk." A published vault — Customer through Compute, 51 nodes, 179 threats — not a diagram of the idea.
The vault, embedded →16 March 2026: a threat model of a real flow. 17 March: every finding checked against the code. Two confirmed real, one confirmed already safe, two confirmed missing, two marked as proposals with nothing built yet — and all four kinds published.
The claim and the check →The industry's diagnosis, in the founder's words: threat modeling is "a fairly subjective process" producing "static documents" that are "siloed", "fragmented" and "context-poor". The answer here is not another methodology.
A semantic knowledge graph, not a Word document — so overlaying STRIDE, MITRE ATT&CK and the OWASP Top 10 on one system becomes a query rather than a workshop.
Threat models as graph data →A threat model was written on 16 March 2026. On 17 March, a validation pass checked every finding against the backend code and marked each one confirmed, missing, or proposed-only.
The validation pair →Security is a market for lemons — vendors know far more than buyers. A published threat model, dated and checkable, is the correction: the same regulatory logic as financial statements and ingredient labels.
The disclosure position →Bottom-up, file by file. A .security.json schema per file with a risk_decision field. STRIDE tables with NOT MITIGATED rows kept in. Two modes, never averaged into one number.
Written in a burst — five of the seven inside four days at the end of May 2025 — building from a diagnosis to a mechanism to a scaling case to a policy position.
Five named failure modes of today's practice, and the graph mechanism that answers them.
Read the summary →Security's market for lemons, and the case for publication as a regulatory requirement.
Read the summary →Multi-view, multi-graph modelling; organic file-based evolution; ontologies as linked layers.
Read the summary →Two supply-chain papers, the bridge to business impact, and the services paper — labelled positioning, not method.
All papers →Most of the practice material is a security review of the founder's own live product. It names unmitigated weaknesses. The rule this site publishes under: publish the method always, publish findings only once they are closed or harmless by design, hold anything still open — the disclosure boundary, in full.
The graph tooling is real but young. The ThreatModCon vault is live; the continuous-modelling pipeline the papers describe is a vision with partial implementation. Every page marks the boundary between what is built and what is argued.
And there is an obvious conflict of interest, worth naming rather than discovered later: this site is published by the estate whose own product it threat-models. The participant disclosure, in full →