Skip to content

Domain Codomain Delimitation

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

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.”

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.

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (4)

Also references 8 related abstractions

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.