Domain Codomain Delimitation¶
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.
| 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.
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.
Variants and Near Names¶
Recognized variants include Strict Input Domain Boundary, Output Promise Boundary, Eligibility Scope Delimitation, Model Applicability Boundary, and Type Signature Delimitation. Near names include input-output scope definition, applicability boundary, valid range specification, supported use boundary, type contract, and eligibility boundary.
The draft collapses input validation, output validation, type signatures, service scope statements, and partial-function fallback into mechanisms or subpatterns unless they carry the broader intervention logic. Model applicability and eligibility boundaries are retained as promotion-watch variants because they may deserve future standalone treatment in model-governance or procedural-fairness contexts.
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.