The starting point sets the ceiling on what can ever be known.
Where verification begins is usually decided by default, and treated afterwards as a matter of tooling and taste. It is neither. It is an architectural choice, and no amount of effort downstream raises the ceiling it sets.
What is foreclosed, and why it cannot be added later
When verification begins at the test file, everything downstream is bounded by what someone thought to write. That is not a criticism of the people writing; it is a property of the starting point.
There is no denominator, because there is no set to count against: the tests are both the numerator and the universe. There is no drift detection, because there is no baseline that outlives the tests themselves; a change is noticed only where a test happened to touch it. And there is no evidence beyond an outcome, because nothing recorded what the outcome was about.
These are not missing features that a sufficiently good test framework would eventually ship. They are unreachable from that starting point. Each of them requires a set of facts that exists independently of the tests, and the test file is not that.
Beginning at the contract makes them reachable, not automatic
A contract read as a source of facts rather than as documentation gives you an object that exists whether or not anyone wrote a test: entities, identities, correlations, lifecycles, preconditions. Counting against it, comparing it to its former self, and anchoring a record in it are then ordinary operations rather than new capabilities.
Reachable is the honest word. Nothing here happens because a contract exists; it happens because something read it out.
The objection
Most services do not have an accurate contract. You are prescribing a discipline that presupposes the one artifact most teams do not maintain, and calling the presupposition an architecture.
This is the strongest thing that can be said against the argument, and two thirds of the answer is mechanism rather than rebuttal.
Derivation makes the contract load-bearing. A document nothing depends on rots silently, because nothing fails when it lies. A document a compiler reads on every run cannot. The moment it disagrees with the system, something stops compiling. The contract stops being documentation and becomes the thing under verification.
An inaccurate contract produces named gaps, not silent wrong answers. What cannot be modelled is reported as a representation gap; ambiguity is refused by name rather than resolved by guess. The failure is visible, and it is visible before a scenario runs.
And if there is no published contract, this argument does not apply to you. It is not a discipline that can be adopted around the absence. That is a real exclusion, and it is stated plainly on the boundaries page rather than softened here.
Two things this argument does not claim
The claim is scoped, and the scope is not "verification". Beginning at the test is correct for verifying things whose contract is the code: unit tests, property tests over pure functions. This is an argument about verifying systems through their published interfaces, and stating that boundary costs it its most sweeping sentence.
And it remains an argument. SODL has not yet been validated on a deployment outside this project's own repository. This page reasons; it does not prove its own thesis by existing.