The Fallback Ladder¶
The fallback ladder is the mechanism behind the “degrade, never fail” principle in Design Principles. It is a fixed sequence of generation strategies, ordered from most domain-aware to most reliable, that every column descends until one of them produces a value.
The four levels¶
Level |
Strategy |
Used when |
|---|---|---|
Specialized |
Entity-aware generation with domain logic: unique emails for users, plausible price ranges for products, valid status values for orders. |
The table’s entity type was recognized with confidence. |
Generic |
Column-name and type patterns: a |
The entity type is unrecognized but columns are still legible. |
Simple |
Generation from the column’s declared type alone: a string for text, an integer for integer, a float for numeric. |
Neither entity nor column patterns matched. |
Minimal |
A type-valid placeholder that is guaranteed to construct. |
Everything above declined or raised. |
Each level is strictly less clever and strictly more reliable than the one above it. Descending the ladder trades fidelity for certainty, one rung at a time.
Why a ladder and not a switch¶
A naive design would pick one strategy per table and fail if it did not apply. The ladder instead guarantees a floor: there is always a level that succeeds, because the bottom rung asks almost nothing of the schema. This is what lets the tool promise that an unfamiliar or malformed schema yields some usable output rather than an error.
Failure isolation¶
The ladder operates per generator, and generators are isolated from one another by the Defensive Manager (see Architecture). If the specialized strategy for one table raises an exception, that table drops to the next rung; it does not abort the run or affect any other table. Errors are recorded rather than silently discarded, so a degraded run is visible, not hidden.
The observability lesson¶
Graceful degradation has a failure mode of its own: if a fallback masks a bug in the level above it, the system keeps working while quietly doing the wrong thing. This is not hypothetical for this codebase. An earlier defect caused the specialized level to be skipped entirely; because the fallback levels caught every case, the output still looked fine and the bug went unnoticed. The lesson, now encoded in the test suite, is that a fallback ladder must be paired with observability into which rung actually ran. Degradation you cannot see is indistinguishable from failure you have not noticed yet.