principle-boundary-discipline

Boundary Discipline

Place validation, type narrowing, and error handling at system boundaries. Trust internal code unconditionally. Business logic lives in pure functions. The shell is thin and mechanical.

Why: Scattered validation is noisy, redundant, and gives a false sense of safety. Keep logic out of framework wiring so it can be tested without the framework.

The pattern:

• At boundaries (CLI args, config files, external APIs, network protocols): validate, return errors, handle defensively.
• Inside the system: typed data, error propagation, no re-validation. Trust the types.
• Across the boundary. Expose domain concepts, not the boundary's private representation. Keep general-purpose mechanism inside and special-purpose policy at the edge.

Applications:

Validation and error handling:

• Validate config at parse time (the boundary), not inside business logic
• Parse raw data into domain types at the boundary
• Do not re-export transport, storage, framework, or wire types through the public surface
• No redundant nil checks deep in call chains if the boundary already validated

Code organization:

• Business logic in pure functions with no framework dependencies
• In review, flag imports that point outward. A domain or policy module that imports a framework, driver, ORM, IO library, generated schema type, or adapter module, type-only imports included, should receive that value as plain data from its caller instead.
• Parse functions: pure transforms from raw bytes to typed state
• Prompt construction: structured state in, string out
• Scoring and assessment: pure transforms from state to results

The tests:

• "Is this data crossing a system boundary right now?" If not, validation is redundant.
• "Can this be a pure function that the shell just calls?" If yes, extract it.