Section 48: Invariants Across System Boundaries¶

TECHSPEC-48 — Section 48 · Version 0.1 · Status: Initial Draft

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Purpose¶

A program often relies on values that cross function, module, process, database, or network boundaries.

Guarantees established inside one boundary must not be assumed to remain valid after crossing another.

2. Boundary Categories¶

Relevant boundaries include: - Function calls. - Module interfaces. - Serialization and deserialization. - Filesystem reads and writes. - Database reads and writes. - Network requests and responses. - Process and operating-system interfaces. - Foreign-function interfaces. - User and external-service input.

3. Revalidation¶

When data crosses a trust or representation boundary, the receiving side must validate the properties it relies on.

Validation must identify: - The exact property established. - The value or data version validated. - The validation method. - The assumptions made. - The point at which the evidence may become invalid.

A value validated as structurally well-formed is not automatically authorized or safe for every use.

4. Invariant Preservation¶

An invariant must be preserved by every operation that can modify the relevant value.

At boundaries: - Deserialization must establish required type constraints and invariants. - Database mapping must handle missing, null, and invalid data explicitly. - Network responses must be treated as untrusted until validated. - External mutation must invalidate stale assumptions. - Shared state must be protected against concurrent modification.

5. Time-of-Check to Time-of-Use¶

A property checked at one time may change before it is used.

The language and libraries should provide mechanisms to: - Bind validation to an immutable value. - Use version or revision checks. - Perform checks and operations atomically where supported. - Revalidate immediately before sensitive operations. - Record when atomicity cannot be guaranteed.

6. Boundary Contracts¶

Boundary functions must declare input constraints, output guarantees, effects, permissions, and failures.

The caller may rely only on guarantees that the boundary actually establishes.

7. Verification Evidence¶

Reports must distinguish: - Validation performed before crossing. - Validation performed after crossing. - Invariants preserved by local code. - External guarantees supplied by another system. - Assumptions that cannot be independently confirmed. - Evidence invalidated by later mutation or external change.

8. Design Goal¶

No invariant should be treated as permanent merely because it was true earlier or in another part of the system. Guarantees must be re-established wherever the language's rules require them.

Source and related sections¶

Source file: TECHSPEC-48.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.