|
| 1 | +# Claim Dependency Note |
| 2 | + |
| 3 | +Open Problem Lab should make load-bearing dependencies visible. |
| 4 | + |
| 5 | +A claim is rarely standalone. It often depends on a dataset, measurement definition, source interpretation, operational assumption, prior claim, or review status. If those dependencies are hidden, later contributors can accidentally build a confident chain on a weak link. |
| 6 | + |
| 7 | +## When to use |
| 8 | + |
| 9 | +Use a claim dependency note when a contribution adds or updates a claim that depends on earlier artifacts or assumptions. |
| 10 | + |
| 11 | +This is especially important when the claim is quantitative, field-relevant, safety-sensitive, or used to prioritize future work. |
| 12 | + |
| 13 | +## Template |
| 14 | + |
| 15 | +```markdown |
| 16 | +## Claim dependency note |
| 17 | + |
| 18 | +**Claim:** Link to the claim or artifact. |
| 19 | + |
| 20 | +**Depends on:** Bullet list of sources, datasets, prior claims, definitions, assumptions, or review artifacts. |
| 21 | + |
| 22 | +**Weakest dependency:** The one dependency most likely to change the conclusion. |
| 23 | + |
| 24 | +**If dependency fails:** What status should change? accepted | bounded | disputed | archived | field-pending | replication-pending. |
| 25 | + |
| 26 | +**Dependency owner:** Who or what should update this dependency? maintainer | reviewer | agent | generated index | external source. |
| 27 | + |
| 28 | +**Recheck trigger:** Date, source update, replication result, field report, or reviewer concern that should trigger reinspection. |
| 29 | +``` |
| 30 | + |
| 31 | +## Examples of dependencies |
| 32 | + |
| 33 | +- A metric depends on a dataset version and a filtering rule. |
| 34 | +- A field claim depends on an implementation channel existing in the target region. |
| 35 | +- A policy claim depends on a regulation that may change. |
| 36 | +- A prioritization claim depends on burden estimates and cost assumptions. |
| 37 | +- A review conclusion depends on a domain expert accepting a scope boundary. |
| 38 | + |
| 39 | +## Reviewer guidance |
| 40 | + |
| 41 | +Reviewers should ask for a dependency note when a claim appears to be used as a load-bearing premise for other work. |
| 42 | + |
| 43 | +The goal is not to map every citation. The goal is to expose the few dependencies that would change the claim if they moved. |
| 44 | + |
| 45 | +## Agent guidance |
| 46 | + |
| 47 | +Agents should identify the weakest dependency before extending a claim. |
| 48 | + |
| 49 | +If an agent cannot identify the weakest dependency, it should mark the claim as not ready for load-bearing use. |
| 50 | + |
| 51 | +## Acceptance test |
| 52 | + |
| 53 | +A dependency note is useful when a future contributor can answer: |
| 54 | + |
| 55 | +1. What does this claim rely on? |
| 56 | +2. Which dependency is weakest? |
| 57 | +3. What happens if that dependency fails? |
| 58 | +4. When should it be checked again? |
| 59 | + |
| 60 | +If those answers are missing, the repo is hiding uncertainty inside links. |
0 commit comments