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.

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

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

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

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.

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.

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