system-tolerates-evolution-at-all-boundaries
OUT derived (depth 1)
The system handles format and schema evolution gracefully at every external boundary: derive output parsers support two format versions with automatic fallback, belief import silently skips unknown metadata fields, and storage tolerates missing tables from older database schemas via exception handling
Summary
The system can absorb changes to its data formats and database schema without breaking, because each external boundary has its own tolerance mechanism. This matters because it means upgrades and version mismatches won't cause hard failures, though the reliance on silent exception swallowing rather than proper migrations means problems could go unnoticed.
Justifications
SL — Three forward-compatibility mechanisms established; gated on full boundary audit (issue #121)
Antecedents (all must be IN):
- derive-parse-supports-two-formats — `parse_proposals` tries the new format first (v0.10+: `### DERIVE id`), falls back to old format (v0.9: `### DERIVE: \`id\``) only when no new-format matches are found
- import-beliefs-parser-is-forward-compatible — Unknown `- ` metadata lines in belief markdown are silently skipped via a `pass` branch, making the parser forward-compatible with new export format fields.
- storage-handles-schema-evolution-via-try-except — Missing tables from older database versions (`repos`, `network_meta`) are handled by swallowing exceptions during `load()` rather than formal migrations — a backward-compatibility substitute that silently degrades.
Unless (any of these IN defeats this justification):
- issue-121-evolution-tolerance-audit — Issue #121: Audit evolution tolerance at all system boundaries — not all boundaries have documented forward-compatibility mechanisms
Dependents
These beliefs depend on this one:
- format-resilience-spans-all-external-interfaces — The system tolerates format variation at every external interface — derive output parsers support version fallback, import parsers silently skip unknown fields, storage handles schema evolution — and extends this resilience to LLM response parsing, where the list-negative parser uses regex extraction to recover structured data from prose-laden responses.
- self-correction-is-evolution-tolerant-and-sustainable — The system's structurally and resource sustainable self-correction — operating on unfragile architecture with accurate bounded budgets — is additionally evolution-tolerant: parser fallbacks, forward-compatible import parsing, and schema migration tolerance at every boundary ensure self-correction mechanisms remain effective as external data formats change.
- system-boundaries-are-evolution-tolerant-and-reference-safe — The system handles boundary interactions safely along two independent dimensions: format and schema evolution is tolerated gracefully (derive parser fallbacks, forward-compatible metadata lines, SQLite schema migration via try/except), while reference validation prevents invalid IDs from crossing any boundary (import normalization drops unknown refs, nogoods skip missing nodes, LLM hallucination filtering discards phantom IDs)
- 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.