derive-validate-before-apply
IN premise
`apply_proposals` trusts its input unconditionally; callers must run `validate_proposals` first or risk database errors from missing antecedents or duplicate IDs.
Summary
The proposal application function doesn't check whether the data it receives is valid — it assumes someone else already did that. If you skip the validation step before calling it, you can end up with database errors because the proposals might reference beliefs that don't exist yet or try to create ones that already do. This means every code path that applies proposals needs to call validation first, and that invariant is the caller's responsibility to maintain.
Dependents
These beliefs depend on this one:
- derive-apply-is-isolated-and-caller-validated — The derive apply stage achieves defense-in-depth: callers must run validation before apply (trust boundary), and even if invalid proposals reach apply, each proposal is wrapped in independent error handling so one failure cannot corrupt the batch.
Details
| Source | entries/2026/04/24/reasons_lib-derive.md |