Tests as Constraints: The Inversion of Verification

Jared Foy April 2026

---

The Observation

The cross-style validation produced a DO runtime from a prose seed, then wrote 15 verification tests to confirm the contracts. This followed the established derivation direction: constraints → prose → runtime → tests.

But React's own test suite already contains ~75 contract tests — tests that assert the architectural invariants, not the implementation details. These tests are the most precise expression of React's constraints that exists. They are more precise than documentation (which admits ambiguity) and more precise than source code (which mixes essential constraints with contingent engineering).

If the tests are the most precise statement of the constraints, then the tests are the seed.

The Method

The derivation chain can be entered at the test level:

React's contract tests (the constraints, stated as pass conditions)
  → a resolver consumes the tests as specification
    → the resolver produces the minimum runtime that satisfies all pass conditions
      → the resulting runtime is conformant by construction

The tests do not describe how to build the runtime. They describe what the runtime must do. The resolver determines how. This is the same relationship between the prose seed and the resolver — but the specification medium is executable assertions rather than natural language paragraphs.

Why This Is Stronger

When the seed is prose, a skeptic can argue that the prose is ambiguous and the resolver interpreted it favorably. When the seed is a test suite, there is no ambiguity. The test either passes or it doesn't. The constraint is falsifiable at the byte level.

The 75 contract tests extracted from React's codebase are:

• Authored by React's engineers, not by the author of this work
• Battle-tested against React's own implementation over years of production use
• Precise — each test asserts a specific input/output or ordering relationship
• Independently verifiable — anyone can run them

A runtime that passes React's own contract tests satisfies React's own constraints. The author's interpretation is removed from the loop. The tests are the authority.

The Constraint Categories

The 75 contract tests cluster around the ten essential contracts:

Contract	Test Count	What The Tests Assert
C4: State triggers render	~16	Bail-out on same state, restart on new state, update ordering
C5: Reconciliation	~7	Child node patching, type-change replacement, keyed identity
C6: Two-phase commit	~20	Render phase interruptible, commit phase atomic, effect ordering
C7: Render purity	~15	Memoization correctness, bail-out optimization, strict mode double-invoke
C8: Separated effects	~35	Effect runs after commit, cleanup before re-run, cleanup on unmount, dependency tracking
C9: Hook ordering	~7	Mismatched hook count detected, stable slot association
C10: Concurrency	~25	Priority ordering, interrupted work reuse, no stale state after yield

The distribution confirms the constraint analysis: React's engineers test the same constraints the seed identified, with the same relative emphasis.

What This Proves About the Method

The derivation thesis claims: constraints stated with sufficient precision produce conformant implementations.

If the constraints are stated as executable tests, "sufficient precision" is maximized. There is zero ambiguity. The resolver either produces code that passes or it doesn't.

This is the final form of the derivation: the specification and the verification are the same artifact. The test suite is both the seed and the proof. The constraint is the test. The property is the pass. The implementation is what the resolver builds between them.

Implication

Any software system whose behavior can be expressed as a test suite can be re-derived from that test suite by a resolver. The test suite is the most portable, most precise, most durable encoding of the system's constraints — because it is executable, falsifiable, and independent of any particular implementation.

The prose seed is the human-readable encoding. The test suite is the machine-verifiable encoding. Both are seeds. Both produce conformant implementations. The prose seed is consumed by a resolver that understands language. The test suite is consumed by a resolver that understands pass/fail. The form is the same. The medium differs.