Domain Codomain Delimitation

Define valid inputs and valid outputs so a function or process does not receive, produce, or promise out-of-scope values.

Solution archetype #

357

Problem family

Boundary, Scope, Access & Spillover Failure

Problem subfamily

Frame, Scope & Applicability Misdefinition

The Diagnostic Story

Symptom: Different teams disagree about whether a case is in scope, and the process moves forward anyway — because nobody wrote down exactly what inputs this function can validly handle. Users treat an advisory output as a binding decision, and integrations break when a new input category appears that the system was never designed for. Exceptions escalate after harm or delay because the boundary was implicit until something crossed it.

Pivot: Before the function is used, integrated, promised, or governed, define the valid input space, the valid output space, and what happens to cases outside both. Make membership tests explicit, specify how unsupported cases are handled, and assign someone to steward the boundary when conditions change.

Resolution: Invalid invocations are caught at the boundary rather than after rework. Output promises match what the function actually supports, and scope changes require explicit, accountable decisions rather than quiet drift. Interfaces and workflows become cleaner because the boundary is observable and versioned.

Reach for this when you hear…

[ML platform] “The model was trained on adults but the intake form accepts any age — we're generating predictions for pediatric cases the model has never seen and calling them confidence scores.”

[legal services] “The intake team keeps sending us contract disputes that fall outside our practice scope, and we're only finding out after we've done three hours of analysis.”

[operations] “The exception queue is overflowing with cases the automated system admitted but can't actually process — we need a gate at the front, not a crash at the back.”

When This Archetype Applies

Complete catalog groundingAt least one sufficient condition set is fully represented by existing primes or domain-specific abstractions.

Diagnostic problem

A function, policy, process, model, role, or service is applied to inputs it cannot validly handle, or is expected to produce outputs outside its intended range, because the input domain and output codomain are implicit, disputed, or stale.

What this problem means

The structural problem is a mismatch between a function-like unit and the cases or promises attached to it. The unit may have a name, owner, interface, workflow, or policy label, but its valid operating set is not explicit. As a result, out-of-domain inputs enter ordinary processing and out-of-codomain outputs are produced, inferred, or promised.

This creates several recurring symptoms: users disagree about what belongs in scope; downstream systems assume unsupported outputs; exception handling happens late and informally; validation checks superficial shape but not real applicability; and scope changes accumulate without stewardship. The deeper tension is that the system needs enough boundary precision to preserve validity while retaining humane and adaptive handling for legitimate edge cases.

Show the applicability expression

Applicability expression5 distinct conditions

any oneAccepted invalid inputsorExpected unsupported outputsorExpanding domain scopeorOut-of-regime applicationorUndefined boundary behavior

Algebraic(A∨B∨C∨D∨E)

groundedpartly groundedopen

5 conditions, all required.

5At least one of theselettered A–E

Any single one of these completes the pattern.

A

Accepted invalid inputs · grounded

Invalid inputs are accepted. more

or — any one satisfies this slot

B

Expected unsupported outputs · open

Outputs outside the supported codomain are expected. more

or — any one satisfies this slot

C

Expanding domain scope · grounded

Scope creeps beyond the originally bounded domain. more

or — any one satisfies this slot

D

Out-of-regime application · grounded · any one of 3

Applicability drifts beyond the regime where the function or model was valid. more

or — any one satisfies this slot

E

Undefined boundary behavior · grounded

Behavior at the domain boundary is undefined. more

Coverage

4 of 5 conditions grounded · 1 open.

None of the 1 open conditions sit in the shared core — each falls inside one alternative branch, so grounding any one of them closes only that branch.

Read the methodology · Download the trigger-logic data

Mechanisms / Implementations

• Clinical Indication Criteria: Defines which patients, conditions, and timing an intervention is valid for — and the contraindications and preconditions that place a case outside it — so a treatment isn't given where it was never indicated.
• Contract Test Suite: Renders the declared boundary as executable cases and counterexamples that fail the build whenever an implementation accepts an out-of-domain input or emits an out-of-codomain output.
• Eligibility Criteria: Codifies, as a published rule set, exactly who or what qualifies as a valid input to a policy, service, or program — turning a fuzzy 'who is this for' into a decidable membership test.
• Input Validation Gate: A runtime checkpoint at the boundary that tests each incoming case against the input domain, normalizes what it safely can, and refuses or defers the rest before ordinary processing begins.
• Model Applicability Card: A short published document that states what a model is validated for — its intended use, input populations, excluded uses, and the assumptions that must hold — so it isn't trusted outside the conditions it was built and tested under.
• Output Schema: Declares the fields, formats, and value categories a function or service is allowed to emit, so nothing outside its codomain can be returned in a well-formed response.
• Output Validation: A runtime check on each produced result that confirms it lies inside the declared codomain before release — and blocks, qualifies, or reroutes anything that doesn't rather than letting it reach downstream reliance.
• Scope Change Review: A recurring review that gathers accumulated boundary violations and edge cases, decides deliberately whether the domain or codomain should change, and versions and announces any revision.
• Service Scope Statement: A published statement of what a service does and does not deliver — the requests it handles, the outcomes it promises, what falls outside it, and where out-of-scope requests should go instead.
• Type Signature: Names a function and declares, in the type system itself, exactly what kinds of value it accepts and what kind it returns — so a compiler rejects out-of-domain calls before the code ever runs.

▸ Show 1 more

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 (4)

• Boundary: Defines system limits.
• Closure: Ensures operations remain within a set.
• Function (Mapping): Relates inputs to outputs.
• Set and Membership: Groups and categorizes elements.

Also references 8 related abstractions

• Accountability: Responsibility for actions.
• Boundedness: Values remain within limits.
• Constraint: Limits possibilities to guide outcomes.
• Data Integrity: Accuracy and consistency preserved.
• Fail-Safe: Default to safe state on failure.
• Interoperability: Systems function together.
• Observability: Infer internal state externally.
• Versioning: Tracks incremental changes over time.

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Strict Input Domain Boundary · subtype · recognized

A domain–codomain delimitation variant that sharply rejects or escalates inputs outside an explicitly admitted input set.

Output Promise Boundary · subtype · recognized

A variant that defines what outputs, results, recommendations, decisions, or service states the function is allowed to produce or promise.

Eligibility Scope Delimitation · domain variant · recognized

Defines who or what is eligible for a service, benefit, intervention, rule, or pathway, and what happens to ineligible or uncertain cases.

Model Applicability Boundary · domain variant · recognized

Defines the inputs, populations, conditions, and output claims for which a model, analysis, simulation, or forecast is valid enough to use.

Type Signature Delimitation · implementation variant · recognized

Uses type declarations, parameter shapes, return types, or schema signatures to bound allowable inputs and outputs.

Editorial Notes

Problem Classification

Classification: Boundary, Scope, Access & Spillover Failure → Frame, Scope & Applicability Misdefinition

Problem kernel: implicit domain and codomain extend a function beyond validity

Rationale: Inputs outside the supported set and outputs beyond the legitimate range are treated as part of the same applicable interface.

Independent corroboration: The earliest necessary condition in the frozen evidence is: A function, policy, process, model, role, or service is applied to inputs it cannot validly handle, or is expected to produce outputs outside its intended range, because the input domain and output codomain are implicit, disputed, or stale. That is a frame scope and applicability misdefinition problem because A problem, project, model, role, or impact perimeter omits consequential elements, expands without control, or is applied beyond the domain in which its claims and responsibilities remain valid.

Review outcome: Independent reviewer agreement; high confidence.