Closure Preserving Operation¶
Design operations so their outputs remain inside the intended domain, preserving invariants and preventing escape into invalid states.
The Diagnostic Story¶
Symptom: Occasionally a transformation produces an output that no downstream actor knows how to handle — a record in an impossible state, a decision that exceeds authority, or a result that crashes the next step. The operation itself allowed it; the domain boundary was only enforced informally, by expert judgment after the fact. Edge cases improvise ad hoc outputs or silently coerce invalid results into apparently valid ones.
Pivot: Constrain, wrap, validate, or redefine the operation so its outputs remain inside the target domain — or, when they cannot, are rejected, repaired, rolled back, or deferred cleanly rather than propagated as if valid.
Resolution: Downstream actors can trust that received outputs are already valid because the operation guarantees it, not because someone checked manually. Invalid transformations surface as explicit failures at their source instead of becoming hidden defects carried forward.
Reach for this when you hear…¶
[software engineering] “The function accepts a negative duration and silently returns zero — somewhere downstream that breaks inventory and nobody knows why.”
[policy administration] “The form lets an applicant choose an option they are not eligible for, and we only catch it three steps later after half the workflow has run.”
[manufacturing process] “The machine can produce a part outside tolerance if the operator picks the wrong fixture — the measurement step is the only catch and it is downstream.”
When This Archetype Applies¶
No catalog groundingNone of the structural conditions is currently represented by an accepted prime or domain-specific abstraction.
Diagnostic problem
A process, transformation, policy, or operation can produce states outside the permitted, valid, safe, or meaningful domain.
What this problem means
The structural problem is domain escape. A process begins in a valid region but is allowed to produce something outside that region. The escape may be technical, such as a malformed data record; operational, such as a machine state outside tolerance; institutional, such as a decision outside authority; or semantic, such as a formally well-shaped output that no longer means what downstream users think it means.
The deeper tension is that operations transform things. Transformation creates value by changing state, but that same change can cross a boundary into invalidity. A closure-preserving design does not stop transformation. It narrows and governs it so the operation’s result remains usable, safe, authorized, and meaningful.
Common symptoms include invalid records discovered downstream, automation that produces unofficial categories, manual workarounds around failed validation, exceptions that become normal, and systems that crash or improvise when an edge case appears.
Show the applicability expression
Applicability expression2 distinct conditions
groundedpartly groundedopen
2 conditions, all required.
2Required in every casenumbered 1–2
These hold no matter which pattern applies.
Carrier-escaping transformation · open
A transformation admits valid inputs whose outputs fall outside the valid carrier.
The source archetype describes the situation as follows: Valid inputs can still lead to invalid outputs after transformation. The normalized requirement above isolates the load-bearing portion used in this condition set.
Underspecified closure contract · open
The permitted carrier, designated operation, and failure response are jointly under-specified so a valid input can escape the carrier without a typed failure.
This condition preserves a load-bearing part of the diagnostic problem that was not captured by a source-condition atom. It remains explicit because omitting it would weaken the sufficient condition set.
Other requirements and context (4)
Why these sit outside the expression
Supporting context — it may accompany or help interpret the situation, but it is not a load-bearing condition in a sufficient diagnostic set.
Deployment constraint — it constrains how the intervention must be deployed, not the situation that calls for it.
Supporting contextDownstream systems assume that received outputs are already valid.
It is especially useful when downstream users assume the output is already valid. In this archetype, the relevant contextual consideration is: Downstream systems assume that received outputs are already valid. It helps interpret the situation or strengthens the practical case for examining the archetype.
Supporting contextThe valid domain is known but only informally enforced.
A process, transformation, policy, or operation can produce states outside the permitted, valid, safe, or meaningful domain. In this archetype, the relevant contextual consideration is: The valid domain is known but only informally enforced. It helps interpret the situation or strengthens the practical case for examining the archetype.
Deployment constraintInvalid results must not be silently coerced into apparently valid results.
Use this archetype when a system can take apparently acceptable inputs and still produce an unsafe, invalid, unauthorized, malformed, or meaningless output. In this archetype, the relevant deployment constraint is: Invalid results must not be silently coerced into apparently valid results. It identifies a boundary that responsible implementation must respect.
Supporting contextExternal pressure rewards producing an answer even when no valid in-domain answer exists.
A process, transformation, policy, or operation can produce states outside the permitted, valid, safe, or meaningful domain. In this archetype, the relevant contextual consideration is: External pressure rewards producing an answer even when no valid in-domain answer exists. It helps interpret the situation or strengthens the practical case for examining the archetype.
Coverage
0 of 2 conditions grounded · 2 open.
Mechanisms / Implementations¶
- Type Systems: A type system implements closure by preventing operations from accepting or producing values outside declared categories.
- Input/Output Contracts: An input/output contract states valid inputs, valid outputs, postconditions, and failure responses.
- Transaction Constraints: Preserve closure across multi-step changes.
- Validation Schemas: A validation schema checks whether data, forms, messages, or records have the required shape and fields.
- Safety Envelopes: A safety envelope constrains outputs to a safe operating region.
- Domain-Specific Languages: A domain-specific language can make invalid operations hard to express.
- Policy Guardrails: Implement closure in institutional domains.
- Postcondition Assertions and Rollback: Postcondition assertions check after execution that the promised result holds.
- Domain-Specific Language: Designs a purpose-built notation in which invalid operations simply cannot be written, so domain escape is prevented at authoring time rather than caught by a later check.
- Input/Output Contract: Declares, at the boundary between a producer and its consumers, exactly which inputs are valid, which outputs are promised, and what happens on failure — so every party relies on the same domain guarantee.
- Policy Guardrail: Routes, refuses, or demands evidence for decisions that might violate a rule, right, or separation-of-duties requirement, with scoped exceptions and a named owner.
- Postcondition Assertion: Checks, immediately after an operation runs, that its actual result satisfies the promised property — and fails fast rather than letting a result that fails the check propagate.
- Safety Envelope: Constrains an operation's outputs to a certified safe operating region, clamping a computed value back to the nearest boundary — or refusing it pending an authorized override — rather than letting it exit the envelope.
- Transaction Constraint: Permits a multi-step change to commit only if the final state satisfies declared constraints, so a partial or inconsistent transition is never made visible — it is all-or-nothing.
- Transactional Rollback: When a transition fails part-way or its result fails a check, restores the system to the last known-valid state and records the undo — so a partial, invalid change is never left committed.
- Type System: Encodes the valid domain as declared types so an operation can neither accept nor produce a value outside its category — and rejects the program before it runs if it would.
- Validation Schema
Related Abstractions¶
Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.
Built directly on (3)
- Boundedness: Values remain within limits.
- Closure: Ensures operations remain within a set.
- Constraint: Limits possibilities to guide outcomes.
Also references 7 related abstractions
- Boundary: Defines system limits.
- Data Integrity: Accuracy and consistency preserved.
- Fail-Safe: Default to safe state on failure.
- Function (Mapping): Relates inputs to outputs.
- Invariance: Properties unchanged under transformation.
- Set and Membership: Groups and categorizes elements.
- Transaction: All-or-nothing operations.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Type-Safe Operation · implementation variant · recognized
A closure-preserving operation implemented through declared value categories, type signatures, and type checks.
Transactional State Closure · implementation variant · recognized
A closure-preserving operation that permits a multi-step change to commit only if the final state remains valid.
Policy-Space Closure · governance variant · recognized
A closure-preserving operation that keeps decisions, permissions, or interventions within an authorized policy space.
Editorial Notes¶
Problem Classification¶
Classification: Correctness, Conformance & Formal Validity Failure → Generator, Basis & Operation Structure
Problem kernel: an operation leaves the permitted carrier set
Rationale: The transformation is treated as valid even though it can produce states outside the domain on which the operation is supposed to close.
Independent corroboration: The earliest necessary condition in the frozen evidence is: A process, transformation, policy, or operation can produce states outside the permitted, valid, safe, or meaningful domain. That is a generator basis and operation structure problem because Claimed primitives or operations lack the independence, completeness, closure, identity, or inverse structure needed to generate and manipulate valid states.
Review outcome: Independent reviewer agreement; high confidence.