You state a column's type when a table is built — when does that refuse a bad value, and when is it only a hint?

## Two designs wearing the same syntax Stating a column's type when you build a table looks like one thing and is two. In both cases you name a type, in both cases the resulting column starts out in that representation, and in both cases the code reads as though you have made a promise. What differs is whether anything is enforcing it. - **The declaration as a contract.** The design validates at construction: a value that does not conform is refused right there, and the column's representation is not something later operations are free to re-decide. The statement means what it appears to mean, and a bad value stops at your line. - **The declaration as a starting hint.** The design honours the type at construction — you really do get the representation you asked for — and then treats it as the initial state of a value that subsequent operations recompute. The next step that returns a new column decides that column's representation from its own inputs and rules. The guarantee lasts exactly until the first operation. Neither is a bug. They are different positions on the same tradeoff: enforcement costs checks at every boundary and refuses data that a more permissive design would have absorbed. ## Why the difference is the whole subject The stated type is the cheapest correctness control available, and its value is exactly the length of time it holds. Under the contract design, one statement at construction protects every downstream step, because the design will not quietly hand you a column of something else. Under the hint design, the same statement protects only the construction itself — after which the pipeline is back to representations chosen by data. That is why a candidate who says "we declare our types, so this cannot happen" is only right half the time, and why the honest answer to any question about type safety in this subject begins with *which design are we in*. | | Declaration as contract | Declaration as hint | |---|---|---| | At construction | non-conforming value refused | value converted or accepted | | After the first operation | still the declared type | recomputed from the operation's inputs | | Where a bad value is discovered | at the line that built the table | wherever someone notices a wrong figure | | What one declaration protects | the pipeline downstream of it | that construction only | | What it costs | checks at the boundary, refused data | nothing, and it protects nothing | ## How to find out which you are in This is a ten-minute experiment and the answer is worth a great deal more than ten minutes: 1. **Build a tiny table stating a type, and hand it a value that does not conform.** Note whether you get a refusal, a converted value, or a column that has quietly become something that holds anything at all. All three happen, and only the first two leave the column usable in the way you intended. 2. **Build a conforming table, run the smallest operation that produces a new column, and look at the new column's representation.** If it matches the declaration, the design is carrying it forward. If it does not, you are in the hint regime and you now know the exact distance your statement travels. 3. **Repeat step two across a construction boundary**, that is, build a new table from the previous step's output. This is the case people never test and it is the one that bites, because a boundary inside your own pipeline looks like nothing at all in the code. ## What the statement is worth in each regime In the contract regime, state the type once at each place a table is built from outside data, and you are done — the design will tell you when reality disagrees with you. In the hint regime, the statement is still worth making, for two reasons that survive the lack of enforcement. First, it fixes the starting representation, and a great many failures in this subject are decided at that first moment and never recovered. Second, it documents intent for the next reader, at the line where the decision was made. What it will not do is protect you three steps later, and a team that believes it does will not put a check anywhere else. ## What an interviewer is listening for The strong answer refuses the premise that there is one behaviour. It names both regimes, says the code looks identical, and offers the experiment rather than an assertion. The weaker answer states one design's behaviour confidently — usually whichever one the candidate's main tool has — and never mentions that the other exists. The very weakest answer is that stating a type makes the column safe, which is a sentence that is true, false, or half-true depending on a property of the tool the candidate has not checked.