derive-apply-is-isolated-and-caller-validated
IN derived (depth 1)
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.
Summary
The system for applying derived proposals has two layers of protection. Callers are expected to validate proposals before submitting them, catching problems like missing references or duplicate IDs upfront, and even if something slips through, each proposal is applied independently so a single bad one won't take down the rest of the batch.
Justifications
SL — Validation-before-apply establishes the trust contract; per-proposal isolation provides the safety net when the contract is violated
Antecedents (all must be IN):
- derive-validate-before-apply — `apply_proposals` trusts its input unconditionally; callers must run `validate_proposals` first or risk database errors from missing antecedents or duplicate IDs.
- derive-apply-isolates-per-proposal-errors — `apply_proposals` wraps each `api.add_node()` call in try/except and accumulates `(proposal, error_string)` tuples, so one malformed proposal does not abort the batch.
Dependents
These beliefs depend on this one:
- derive-pipeline-is-reproducible-and-defense-in-depth — The derive pipeline achieves both reproducibility (deterministic sampling with fixed seeds and accurate budget allocation) and defense-in-depth at the application stage (validation-before-apply trust boundary with per-proposal error isolation), ensuring pipeline runs are repeatable and any surviving bad proposal cannot corrupt sibling proposals.