Context:
Identified during work on #7
PR: #8
Description:
Kivaar's threat model (kivaar#38, docs/threat-model/model.json) carries four collections that #7's "Required document support" never lists, and that PR #8 therefore did not implement:
| Collection |
Shape |
What it does |
criticality |
level, definition, examples[] |
Calibration table defining what each priority level means, with worked examples |
focus_paths |
path, why, threat_links[] |
Points a reviewer at the code paths that most deserve scrutiny |
quality_checks |
check, status, note |
The model's self-assessment of its own completeness |
top_abuse_path_links |
threat IDs (5-10) |
The headline abuse paths, called out ahead of the full list |
Kivaar's local implementation also enforces policy on these — criticality must define all four priority levels with at least two examples each, and top_abuse_path_links must hold between five and ten entries.
Rationale:
Deferred from #7 by agreement. All four describe how a project reviews a threat model rather than what the threat model is, which is why they read as consumer presentation and process rather than shared schema. Absorbing them would put one consumer's review methodology into a contract every consumer has to satisfy.
The counter-argument is real though, and this issue exists to settle it rather than assume:
criticality has the strongest case. priority is a schema-owned vocabulary, and a document that uses it without defining what its levels mean is less reviewable. This is arguably schema, not process.top_abuse_path_links is derivable — priority: critical already marks the headline threats — so it may be redundant rather than missing.focus_paths and quality_checks have no schema rule that would key off them.
Impact if not done:
This is the only gap between PR #8 and a zero-content-loss Kivaar migration. Kivaar would need to drop these four sections or keep them in an unvalidated sidecar, which #7's acceptance criteria explicitly wanted to avoid.
Acceptance Criteria:
Context:
Identified during work on #7
PR: #8
Description:
Kivaar's threat model (kivaar#38,
docs/threat-model/model.json) carries four collections that #7's "Required document support" never lists, and that PR #8 therefore did not implement:criticalitylevel,definition,examples[]focus_pathspath,why,threat_links[]quality_checkscheck,status,notetop_abuse_path_linksKivaar's local implementation also enforces policy on these —
criticalitymust define all four priority levels with at least two examples each, andtop_abuse_path_linksmust hold between five and ten entries.Rationale:
Deferred from #7 by agreement. All four describe how a project reviews a threat model rather than what the threat model is, which is why they read as consumer presentation and process rather than shared schema. Absorbing them would put one consumer's review methodology into a contract every consumer has to satisfy.
The counter-argument is real though, and this issue exists to settle it rather than assume:
criticalityhas the strongest case.priorityis a schema-owned vocabulary, and a document that uses it without defining what its levels mean is less reviewable. This is arguably schema, not process.top_abuse_path_linksis derivable —priority: criticalalready marks the headline threats — so it may be redundant rather than missing.focus_pathsandquality_checkshave no schema rule that would key off them.Impact if not done:
This is the only gap between PR #8 and a zero-content-loss Kivaar migration. Kivaar would need to drop these four sections or keep them in an unvalidated sidecar, which #7's acceptance criteria explicitly wanted to avoid.
Acceptance Criteria:
docs/schema-threat-model.md("Which vocabularies are schema-owned")coverageswitches for the established pattern