Design for Verification

Software that cannot be measured cannot be industrialized.

In the Foundry, systems are designed so that their behavior can be autonomously verified.

This requires a shift:

From prose to metadata.
From implication to explicit constraint.
From intuition to invariants.

Metadata is the New Logic

Natural language is expressive but ambiguous.

A requirement written as prose is noise in a deterministic pipeline.

To become logic, a requirement must be expressed as:

• Machine-readable constraints
  
  

• Structured schemas
  
  

• Explicit state transitions
  
  

• Enumerated invariants
  
  

When constraints are encoded in metadata, the Generator can synthesize deterministically and the Gauge can verify precisely.

State Completeness

Completeness is not the happy path.

It requires:

• Explicit state models
  
  

• Defined reverse transitions
  
  

• Cross-entity invariants
  
  

• Forbidden states
  
  

• Boundary conditions
  
  

If a workflow can enter an undefined state, the Oracle is incomplete.

Design for Verification means designing systems that cannot hide ambiguity.

Deterministic-Capable vs Fitness-Based

Not all requirements are strictly deterministic.

Some define outcomes (performance, ranking, optimization).

The Foundry requires classification:

• Deterministic-capable requirements must be formally specified.
  
  

• Fitness-based requirements must define measurable thresholds and invariants.
  
  

Ambiguity is not allowed to leak between the two.