44 lines
1.5 KiB
Markdown
44 lines
1.5 KiB
Markdown
# Root Tree Decomposition Checklist
|
|
|
|
## Source integrity
|
|
|
|
- [ ] The tree records the detailed document hash and project revision/snapshot.
|
|
- [ ] Every node has at least one source anchor.
|
|
- [ ] Source anchors actually contain the material implied by the title.
|
|
- [ ] Runtime-dependent claims name evidence or use `NEEDS_EVIDENCE`.
|
|
|
|
## Topic quality
|
|
|
|
- [ ] Topic is a coherent engineering problem space rather than a directory name.
|
|
- [ ] Two Topics do not merely split the same causal chain arbitrarily.
|
|
- [ ] A large Topic is split when its records no longer share useful relations/criteria.
|
|
|
|
## Case
|
|
|
|
- [ ] There is a specific incident, experiment, failure, diagnosis, or verification sequence.
|
|
- [ ] The title can be understood without inventing a historical story.
|
|
- [ ] The conclusion is bounded by actual evidence.
|
|
|
|
## Reference
|
|
|
|
- [ ] The rule is reusable beyond the originating incident.
|
|
- [ ] It is not the Case summary rewritten declaratively.
|
|
- [ ] Scope and exception can be stated from sources.
|
|
|
|
## Open Question
|
|
|
|
- [ ] The answer is not already in the analysis.
|
|
- [ ] Known/unknown/next verification are separable.
|
|
- [ ] Candidate options are included only when sources really considered them.
|
|
|
|
## Decision
|
|
|
|
- [ ] A project choice is explicitly recorded or user-supplied.
|
|
- [ ] `technology is present` is not being treated as rationale.
|
|
- [ ] `NEEDS_DECISION` is used if the direction is only a recommendation.
|
|
|
|
## Duplication
|
|
|
|
- [ ] No two nodes have the same primary purpose.
|
|
- [ ] Relations are used instead of copying one record's entire content into another.
|