input-validation-is-comprehensive-at-all-boundaries
OUT derived (depth 2)
Input validation is enforced at every system boundary through complementary mechanisms: typed exceptions (ValueError for duplicates, PermissionError for access violations) enforce API-level preconditions at the call boundary, while defense-in-depth reference validation (import normalization dropping unknown refs, nogood filtering skipping invalid nodes, hallucinated ID rejection) catches invalid node references at every data-acceptance boundary.
Summary
The system was thought to catch bad input at every entry point through two layers — type-checked errors for obvious misuse like duplicate IDs, and quiet filtering for invalid references that slip through from imports or LLM output. This claim is currently unsupported, meaning at least one of those layers may have gaps, so invalid data could be entering the system without being caught.
Justifications
SL — API-level validation (depth-1) gates the call boundary; reference validation (depth-1) gates all data boundaries — no invalid input survives to reach the TMS engine regardless of entry point.
Antecedents (all must be IN):
- api-enforces-typed-preconditions — API functions enforce preconditions at the system boundary with typed exceptions: duplicate node IDs raise ValueError, missing justification arguments raise ValueError, and unauthorized single-node access raises PermissionError — establishing a consistent error contract at every entry point.
- reference-validation-is-defense-in-depth — Every system boundary that accepts node ID references validates them against the actual network: import normalization drops unknown antecedent/outlist refs, nogood recording skips invalid node IDs, and LLM-returned negative-list IDs are filtered against existing nodes.
Dependents
These beliefs depend on this one:
- pg-data-integrity-achieves-defense-in-depth — PgApi's data integrity achieves defense-in-depth through both application-level enforcement (write-time referential validation and outlist-aware dependent queries spanning antecedent and outlist references) and comprehensive input validation at all system boundaries, but full defense-in-depth requires database-level foreign key constraints to provide a second independent enforcement layer
- system-boundaries-are-validating-and-evolution-tolerant — All system boundaries simultaneously enforce strict input validation (typed exceptions, referential integrity checks, hallucination filtering) and tolerate evolution gracefully (dual format parsers, forward-compatible metadata, schema-tolerant loading) — boundaries are both strict about current invariants and adaptive to future changes.