Code RoomSound properties over semantic sets
FrontierPrep Room Coding #4981

Sound properties over semantic sets

CodingAlgorithms & data structuresSenior–Staff~90 min

You need a sound statement about a deployed transformer. Sound in the one sided sense: if your procedure says the property holds then it holds, and returning inconclusive is an acceptable output. The model is large enough that a complete solver over the network is not on offer, and this question does not want you to pretend otherwise.

The property is not a metric ball. It is stated over a set of inputs described semantically, for instance every prompt carrying a particular tool schema and requesting a particular class of action, and it forbids an output predicate over token sequences. That is where the difficulty moves. A metric ball has a definition independent of any learned component. Your input set does not, and if you define it with an encoder or a classifier then your soundness is relative to that component, which nobody verified.

Off the table: a complete solver call over the full network, an empirical test suite presented as verification, and verifying a distilled surrogate then asserting the result transfers without bounding the transfer gap. You may verify a component in isolation, and then you owe the interface contract that lets a component guarantee compose into a statement about the system.

Hand in the class of property your procedure can address and, in the same detail, the class it cannot. Hand in the procedure itself, including where the relaxation enters and how looseness accumulates with depth, since bounds going vacuous is the usual outcome and naming the depth at which it happens is part of the answer. Hand in an account of the specification's own trust: what your statement is worth when the input set is defined by an unverified model, and what a reviewer should conclude when the procedure returns inconclusive on nearly everything it is asked. Ties break toward a procedure returning a narrow sound statement often, over one returning a broad statement rarely.

What a strong answer looks like

State your approach and its time/space complexity out loud before you optimize. Handle the edge cases (empty input, duplicates, overflow), and say why you chose this over the brute force. Green tests are the floor, not the grade.

0:00 of about 90 min
InputExpectedGot