The Boundary Test: What Belongs Inside the Model?

The constraint stack and Palabrita's scope-reduction arc point to a practical judgment: a local model should own a responsibility only when its errors, output shape, and timing can be contained without breaking the product. This checkpoint connects those ideas into a boundary test. It helps the reader decide what belongs in deterministic product logic, what can be delegated to bounded generation, and what a system must control when one model is expected to serve many tasks.

The test is not a preference for small models or for minimal features. It is a way to match responsibility with the layer that can actually guarantee its important properties.

A responsibility has a risk profile

Start with the consequence of being wrong. In Palabrita, a word with the wrong length is not merely a less elegant answer. It is an invalid puzzle. A word in the wrong language or a repeated word undermines the game's rules. Those properties are hard product obligations: the application needs them to be true before the user can play, and it can check them more reliably in curated data and deterministic code than in free-form generation.

A hint has a different risk profile. It should be relevant, short, and not reveal the answer, but some variation in wording is acceptable. A weak hint can be rejected, retried, or replaced by a generic one without making the puzzle structurally impossible. The task has a creative center and a tolerable quality range. That makes it a better candidate for a local model, provided the product still validates the result and has a fallback.

This distinction can be expressed through five questions. Is the output required to be exactly correct, or merely useful? Can the requirement be checked directly after generation, or must it be satisfied while the model is producing tokens? How complex is the output schema, and how many fields must agree with one another? Does the slowest accepted path fit the interaction deadline? Finally, if the model fails repeatedly, does a degraded result preserve the product's purpose?

The answers matter together. A soft creative task with one small output and a functional fallback can tolerate more uncertainty than a multi-field response containing several hard constraints. A task may be technically simple yet operationally unsuitable if it requires a long batch before the user can continue. A task may be creative but still too important to leave to a model if there is no acceptable degraded behavior.

The questions also reveal why output complexity matters even when every individual field looks easy. If a response contains a word, a category, a numerical difficulty, and several hints, the application must validate each field and the relationships among them. A correct word paired with a contradictory difficulty value is not the same as a correct word by itself. A translated key may be recoverable, but a wrong-language value can require a different response. Each additional obligation creates another way for an otherwise fluent answer to become unusable. Palabrita's later schema reduction worked because it removed relationships that the product did not need, not because shorter JSON is inherently better.

The test should be applied to the worst reasonable path, not to a demonstration response. Imagine the model returns a plausible answer on the first try. That establishes possibility.