Domain Codomain Delimitation

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

Version

v1 · 2026-08-24 · History

Solution archetype #

357

Problem family

Boundary, Scope, Access & Spillover Failure

Problem subfamily

Frame, Scope & Applicability Misdefinition

Essence

Domain–Codomain Delimitation bounds the valid use of a function-like unit. It asks two practical questions before the unit is relied on: what may validly enter? and what may validly come out? The answer can apply to a software function, public service, clinical protocol, data model, machine-learning system, organizational team, policy pathway, or any process that accepts cases and produces outputs.

The archetype is useful when a named function appears reliable but its scope is ambiguous. People send it unsupported cases, expect outputs it cannot legitimately produce, or treat boundary failures as ordinary exceptions. Delimitation makes the supported input domain, output codomain, unsupported cases, and safe routing visible enough to test, govern, and revise.

Compression statement

When transformation fails because inputs, contexts, or output promises are poorly bounded, delimit the valid input domain and output codomain, specify unsupported cases, and provide safe rejection, conversion, deferral, or escalation paths to preserve validity and prevent unsupported use.

Canonical formula: domain_codomain_delimitation = supported_input_set + promised_output_set + membership_tests + unsupported_case_path + output_conformance_rule + scope_stewardship

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.

Applicability expression5 distinct conditions

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

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

D=(a∧a′)∨(b∧b′)∨c

′ context guard? connective not recorded∅ no catalog witness yet

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

domainNull dereference— The failure where code operates on a reference under the unstated assumption that the object exists, while the reference is in fact absent — so the defect is the missing existence-precondition check, not the absence itself.

How this was matched — 3 requirements, all needed

A system accepts an input outside its valid domain.

All of

• roleA focal system, function, policy, process, model, role, or service has a valid input domain.
• domainA focal input lies outside that valid domain.
• relationThe entity nevertheless accepts or applies itself to the invalid input.

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

primeScope Creep— A perimeter ratchets outward through small additions each judged against a drifting current baseline rather than the original charter, with no owner of the trajectory.

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

a

domainGround-Truth Drift— The model-evaluation failure in which the operational definition of the correct answer drifts on a clock the monitoring apparatus cannot see, so metrics keep scoring against a moved target while the dashboards stay green — invisible because every detector consumes current ground truth as its reference.

AND both parts required

context guardThe monitored model was valid under the original label definition.

suppliesA focal function or model has an operating regime in which it is valid. · The function or model was valid in an earlier operating regime.

or — any one of these establishes this case

b

domainGold-Standard Erosion— Recognize that a model scored against a mutable reference label can show stable metrics while its real validity silently degrades, because the answer key — not the model — has drifted away from the construct it once operationalized.

AND both parts required

context guardThe evaluated model was valid under the original reference standard.

suppliesA focal function or model has an operating regime in which it is valid. · The function or model was valid in an earlier operating regime.

or — any one of these establishes this case

c

domainCovariate-Shift Blind Spot— The deployment failure in which a model's input distribution P(X) drifts outside its training support while P(Y|X) holds — and goes undetected because monitoring watches lagging outcome metrics instead of the immediately-available input signal.

How this was matched — 4 requirements, all needed

A function or model's application or claimed applicability extends beyond the regime where it is valid.

All of

• roleA focal function or model has an operating regime in which it is valid.
• timingThe function or model was valid in an earlier operating regime.
• relationThe function or model's application or claimed applicability extends beyond the valid regime.
• polarityThe function or model is applied or claimed applicable outside the regime where it is valid.

or — any one satisfies this slot

E

Undefined boundary behavior · grounded

Behavior at the domain boundary is undefined. more

domainRules-of-Engagement Ambiguity— Diagnose frontline breakdown under time pressure as a grain mismatch — decision rules written coarser than the environment generates choice points — paid out of a finite discretion budget, relocating the fix from the operator's judgment to the rule, escalation path, and pre-positioned authority.

AND both parts required

context guardThe undecidable choice point lies at the rule's applicability-domain boundary.

suppliesFocal cases occur at the boundary of that domain.

How this was matched — 3 requirements, all needed

A system's behavior is undefined for cases at its applicability-domain boundary.

All of

• roleA focal system, function, policy, process, model, role, or service has an applicability domain.
• domainFocal cases occur at the boundary of that domain.
• polarityThe entity's behavior for those boundary cases is undefined.

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

When to Use This Archetype

Use this archetype when invalid or unsupported use is the core failure. A service receives requests it was never designed to handle. A model is applied to populations outside its validation evidence. A policy pathway is expected to produce remedies it cannot authorize. A data pipeline accepts inputs that look well-formed but violate semantic assumptions. A team receives work that belongs elsewhere and quietly absorbs it until quality collapses.

It is especially strong when the boundary must be more than a disclaimer. The input domain and output codomain should affect intake, routing, validation, testing, user expectations, and revision authority. If the only needed action is to add a single field-level check, use an input-validation mechanism instead. If the whole behavioral contract is ambiguous, use Functional Specification.

Structural Problem

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.

Intervention Logic

The intervention starts by naming the functional unit under scope. Then it defines the input domain: the supported values, requests, cases, users, states, evidence, preconditions, and contexts. It also defines the output codomain: the allowed result categories, decision types, formats, remedies, confidence levels, or promises.

The boundary becomes operational through membership criteria, examples, counterexamples, validation or review mechanisms, and unsupported-case paths. Out-of-domain cases should not disappear into silent failure. They should be rejected, converted, deferred, referred, escalated, appealed, or handled by a safe fallback according to the risk and domain. Finally, stewardship keeps the boundary from drifting as cases, technologies, laws, users, or downstream dependencies change.

Key Components

Domain–Codomain Delimitation bounds the valid use of a function-like unit by making its input and output scopes operational, and its first components fix the object and its two sides. The Functional Unit Under Scope identifies what is being bounded — an API, model, service, policy pathway, role, or workflow — so the boundary attaches to a specific thing rather than to a general mission statement. The Input Domain declares what may validly enter: cases, data, users, states, evidence, preconditions, and contexts the unit is designed and authorized to handle. The Output Codomain declares the corresponding output side: the result classes, decision types, formats, remedies, and guarantees the unit may legitimately produce. Together these three components convert a vague reputation for reliability into a checkable claim about which uses are supported.

The remaining components turn that claim into something that can be enforced, traversed safely at the edge, and revised as the world changes. Membership Criteria translate the boundary into usable rules, predicates, examples, and counterexamples, so the test is teachable rather than tacit. The Unsupported Case Boundary separates invalid, ambiguous, high-risk, or elsewhere-owned cases from ordinary work, and the Safe Rejection or Deferral Path defines where those cases go — rejected, converted, deferred, referred, or escalated — so that out-of-scope inputs do not vanish into silent failure or informal discretion. The Output Conformance Rule bounds what the unit is permitted to emit, preventing outputs from exceeding allowed formats, categories, authority, or promise levels. Scope Stewardship assigns ongoing responsibility for reviewing boundary violations, versioning changes, and communicating them to dependents, since boundaries decay quickly when cases, technologies, laws, users, or downstream relationships drift without an owner.

Component	Description
Functional Unit Under Scope ↗	identifies the process, model, service, policy, role, API, or workflow being bounded. Without this, the boundary becomes an unfocused scope statement.
Input Domain ↗	defines what may validly enter: cases, data, users, states, requests, evidence, preconditions, or contexts.
Output Codomain ↗	defines what may validly come out: result classes, response formats, decisions, remedies, deliverables, guarantees, or state changes.
Membership Criteria ↗	translate the boundary into usable rules, thresholds, predicates, examples, and counterexamples.
Unsupported Case Boundary ↗	distinguishes invalid, ambiguous, high-risk, unimplemented, or elsewhere-owned cases from ordinary work.
Safe Rejection or Deferral Path ↗	defines where unsupported cases go and what users or systems can expect next.
Output Conformance Rule ↗	prevents outputs from exceeding allowed formats, categories, authority, or promise levels.
Scope Stewardship ↗	assigns responsibility for reviewing boundary violations, revising scope, versioning changes, and communicating them.

Common Mechanisms

Common mechanisms implement the archetype but should not be confused with it. An Input Validation Gate checks whether an incoming case belongs in the input domain. An Output Schema bounds the structure of responses. Output Validation checks whether produced outputs remain inside the declared codomain before they are released, relied on, or sent downstream. A Type Signature expresses accepted inputs and returned outputs in technical systems. Eligibility Criteria and Service Scope Statements publish institutional boundaries for policies, services, and programs.

Clinical and model-governance contexts use more specialized mechanisms. Clinical Indication Criteria define conditions, contraindications, and escalation paths. A Model Applicability Card states intended use, excluded use, population boundaries, and output claims. A Contract Test Suite verifies that implementations respect the declared boundary. An Unsupported Case Triage Workflow routes out-of-scope or ambiguous cases instead of letting them fail silently. A Scope Change Review turns recurring exceptions and boundary violations into governance signals.

11 documented mechanisms across 6 implementation forms.

The grouping reflects forms represented among the mechanisms currently documented for this archetype; an absent form is not necessarily an impossible implementation.

Assessment, Review & Assurance · 1 mechanism

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

Control, Automation & Runtime · 2 mechanisms

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

Decision, Gate & Allocation · 1 mechanism

• Unsupported Case Triage Workflow — Sorts the cases that fall outside the boundary — rejecting the clearly invalid, referring the elsewhere-owned, escalating the high-risk, and giving contested cases an appeal — so out-of-scope never means silently dropped.

Experiment, Test & Rehearsal · 1 mechanism

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

Representation, Specification & Plan · 3 mechanisms

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

Rule, Policy & Commitment · 3 mechanisms

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

Parameter / Tuning Dimensions

The main tuning dimension is boundary strictness. Strict boundaries reduce invalid use but increase false rejection and escalation burden. Softer boundaries permit adaptation but risk scope creep and unsupported processing.

Other parameters include the granularity of the input domain, the breadth of the output codomain, the threshold for escalation, the level of automation in boundary enforcement, the cost of false acceptance versus false rejection, the visibility of rejection reasons, the ease of appeal, the cadence of boundary review, and the versioning burden imposed on downstream systems.

Invariants to Preserve

The input membership boundary must remain clear enough that users and maintainers can distinguish in-domain, out-of-domain, and borderline cases. The output promise boundary must remain honest: the unit should not produce or imply outputs outside its declared codomain or authority.

Unsupported cases must remain safe. They should not be hidden in defaults, ignored by automation, or handled through unaccountable discretion. Boundary changes must remain observable and versioned when others rely on the old scope. In high-stakes settings, the boundary must remain contestable enough to avoid unfair exclusion.

Target Outcomes

A successful domain–codomain delimitation reduces invalid invocations, unsupported promises, integration failures, and late exception surprises. It improves users’ ability to know what a function can and cannot do. It gives implementers testable criteria. It helps stewards detect drift and recurring edge cases. It also reduces hidden accountability gaps by forcing out-of-scope cases into explicit routing rather than informal improvisation.

Tradeoffs

The pattern trades openness for validity. Stronger boundaries improve safety, consistency, and interoperability, but they may exclude legitimate edge cases or slow service. More detailed codomains reduce overpromising, but they can frustrate users seeking broader outputs. More visible rejection and appeal paths improve fairness, but they add operational overhead. More automation reduces burden but risks brittle or unfair boundary enforcement.

Failure Modes

A common failure mode is boundary theater: a document says what is supported, but intake, interface, training, testing, and triage do not enforce or reflect it. Another is semantic failure behind formal validation, where a request has the right shape but violates population, context, evidence, or authority assumptions. Silent out-of-domain processing occurs when unsupported inputs pass through defaults or informal judgment. Codomain overclaiming happens when technically valid outputs are interpreted as stronger guarantees or decisions than intended. Unfair exclusion occurs when a boundary denies service, opportunity, or recognition without legitimate criteria or appeal.

Neighbor Distinctions

Domain–Codomain Delimitation is narrower than Functional Specification. Functional Specification defines the expected behavior of a unit across transformation rules, edge cases, and tests; this archetype focuses specifically on valid input and output scope.

It differs from System Scope Definition, which bounds an entire system, mission, or product. It differs from Closure-Preserving Operation, which preserves valid state under operations after the operation is already defined. It differs from Relation Constraint Enforcement, which governs valid relationships among entities. It differs from Input Validation and Output Validation, which are mechanisms for enforcing boundaries, not the intervention of defining and stewarding the boundary.

Cross-Domain Examples

In software, an API defines accepted request schemas, authentication states, supported versions, response bodies, and error codes. In public services, a benefits program defines eligible households, required evidence, covered remedies, denial reasons, referrals, and appeals. In clinical care, a treatment protocol defines indications, contraindications, required measurements, allowed orders, and escalation for uncertain cases. In machine learning, a model is authorized only for a validated population and output claim. In organizational design, a team states which requests it accepts and which deliverables it can produce.

Non-Examples

A field-level form check is not this archetype if the service scope is already clear. A general product mission statement is not this archetype because it does not delimit a function-like input-output relation. A foreign-key constraint is relation constraint enforcement, not domain/codomain delimitation. A full behavioral contract for every transformation rule and acceptance test is more likely Functional Specification. A disclaimer that says “use at your own risk” is not enough unless it changes input admission, output promises, unsupported-case routing, and stewardship.

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.

• Distinct from parent: The parent may also delimit output promises; this variant concentrates on admission to the input side of the mapping.
• Use when: Invalid inputs can create safety, integrity, legal, or downstream processing failures; The system can cheaply test whether an input is inside the valid domain before acting; False acceptance is more dangerous than false rejection or human review.
• Typical domains: software interfaces, clinical protocols, public service intake, data pipelines
• Common mechanisms: Input Validation Gate, Type Signature

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.

• Distinct from parent: The parent covers both input and output scope; this variant concentrates on the promises made on the output side.
• Use when: Users or downstream systems overinterpret what the process can deliver; The system sometimes returns unsupported categories, confidence levels, guarantees, or remedies; Accountability depends on distinguishing promised outputs from aspirational, advisory, or impossible outputs.
• Typical domains: public services, machine learning, customer support, reporting systems
• Common mechanisms: Output Schema, Service-Level Catalog

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.

• Distinct from parent: The parent is domain-general; this variant highlights membership, rights, due process, and routing concerns in eligibility decisions.
• Use when: A policy, program, workflow, or service must decide which cases are inside its remit; Ambiguous eligibility creates inconsistent treatment, queue leakage, or unsupported promises; Fairness and accountability require explicit inclusion, exclusion, and appeal paths.
• Typical domains: public benefits, healthcare, education, legal services
• Common mechanisms: Eligibility Criteria, Intake Triage Form

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.

• Distinct from parent: The parent can delimit any process; this variant adds model-specific validity, training, sampling, and uncertainty concerns.
• Use when: A model is being applied beyond its training data, assumptions, measurement conditions, or validation evidence; Users need to know when model outputs should be accepted, caveated, rejected, or escalated; Decision risk depends on model validity boundaries rather than only on model accuracy.
• Typical domains: machine learning, forecasting, simulation, risk assessment
• Common mechanisms: Model Card Applicability Section, Out-of-Distribution Detector

Type Signature Delimitation · implementation variant · recognized

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

• Distinct from parent: The parent is the intervention; the type signature is a common way to implement it in technical systems.
• Use when: The function or interface is technical enough for type-like boundary declarations; Callers need a compact contract for admissible inputs and returned outputs; Compile-time, runtime, or contract tests can enforce boundary adherence.
• Typical domains: software engineering, data engineering, formal methods
• Common mechanisms: Type Signature, Contract Test Suite

Near names: Input–Output Scope Definition, Applicability Boundary, Valid Range Specification, Supported Use Boundary, Type Contract, Eligibility Boundary.

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.