Skip to content

Preimage Set Characterization

Given an output condition, identify and bound the complete set of inputs that could produce it before acting as if the output has a unique source.

Summary

Given an output condition, identify and bound the complete set of inputs that could produce it before acting as if the output has a unique source.

This archetype treats an output as a doorway back to a set of possible inputs. It is especially useful when a label, alert, status, score, projection, rule result, or decision outcome is compact, but the set of inputs that could produce it is not compact, not unique, or not fully known.

Disposition Rationale

The target accepted prime preimage had zero direct, related, variant, and alias coverage in the queue. Existing accepted archetypes cover valid input/output scope, functional contracts, relation mapping, retrieval, causal explanation, and mapping reconciliation, but none directly covers the inverse-set task of defining all inputs that map to a specified output condition. This draft therefore creates a bounded full archetype rather than a component-only record.

Core Pattern

A preimage is not a hunch about the likely source of an output. It is a membership set: every input in the declared domain that maps to the output condition belongs, and every input that does not map there is excluded. The archetype forces the user to state the mapping, the output condition, the input domain, the membership test, the construction method, and the completeness claim.

When to Use

Use this when a system needs to reason from output to input: diagnosing an alert, auditing a classifier, querying all records satisfying a rule, checking eligibility, reverse-mapping a projection, or documenting which cases a policy decision covers. The critical sign is that a downstream action depends on knowing the set of inputs compatible with an output, not merely on observing the output itself.

Component Logic

The mapping under review and output condition come first. Then the input domain boundary prevents accidental expansion or exclusion. The membership rule makes inclusion testable. Candidate enumeration constructs the set. Collision and multiplicity checks prevent false uniqueness. Completeness evidence distinguishes exhaustive preimage from partial discovery. Boundary cases and action policy keep the result usable without overclaim.

Mechanism Logic

Mechanisms such as inverse lookup queries, constraint solvers, predicate filters, collision matrices, witness sets, and completeness audits instantiate the archetype. They are not the archetype itself. The archetype is the disciplined inverse-characterization pattern that tells those mechanisms what they must preserve.

Boundary Notes

This is not Domain–Codomain Delimitation: that archetype defines the valid spaces of a function, while this one asks which inputs in the domain land at a particular output. It is not Index-Based Retrieval: an index may speed up finding the set, but retrieval does not by itself define the membership rule or completeness claim. It is not Causal Mechanism Mapping: preimage membership shows compatibility with an output, not proof that an input actually caused it.

Invariants

Keep the mapping fixed, the output condition explicit, the input domain visible, the membership rule reviewable, the multiplicity honest, and the completeness claim bounded. The most important invariant is not to collapse a many-to-one output into a single assumed input.

Examples

In mathematics, the preimage of a value changes when the input domain changes. In data governance, all records satisfying a predicate form a preimage of the true condition under the rule. In incident response, one alert may have multiple compatible system states. In model auditing, a class label may hide many feature profiles. In dashboards, one status light may collapse several operational realities.

Non-Examples

A generic relation map, a ranked search result, a causal proof, an API type signature, or a nearest-neighbor query is not this archetype unless the central object is the set of inputs mapping to a specified output condition.

Common Mechanisms

  • Collision Analysis Matrix
  • Constraint-Solver Backsolve
  • Coverage Completeness Audit
  • Fiber Cardinality Count
  • Inverse Lookup Query
  • Output-to-Input Traceback Map
  • Predicate Satisfaction Filter
  • Preimage Table
  • Sensitivity-to-Mapping-Change Review
  • Witness and Counterexample Set

Compression statement

When a mapping, model, rule, projection, or process produces an output that must be explained, queried, governed, or acted on, define the output condition, domain of inputs, membership test, enumeration method, multiplicity, and completeness evidence so the resulting preimage is not confused with a single cause, a sample of examples, or a reversible inverse.

Canonical formula: preimage(output_condition) = { input in declared_domain | mapping_under_review(input) satisfies output_condition } + completeness_evidence + multiplicity_note + downstream_use_policy

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

Built directly on (7)

  • Bijectivity: A correspondence that is exactly one-to-one and onto — no collisions, no gaps — so it is reversible and the two collections have equal size and information content.
  • Function (Mapping): Relates inputs to outputs.
  • Injectivity: A distinctness-preserving mapping in which distinct inputs never collide on one output.
  • Predicate: A testable yes-or-no property of an object, returning a truth value.
  • Preimage: The set of all inputs that map to a given output under some mapping.
  • Projection: Map a richer object onto a lower-dimensional target along a chosen direction, discarding the rest.
  • Set and Membership: Groups and categorizes elements.

Also references 19 related abstractions

  • Abstraction: Focus on core elements.
  • Boundary: Defines system limits.
  • Calibration: Aligning a system's output to a trusted reference by measuring deviation, adjusting to reduce it, and monitoring for drift.
  • Causality: Cause-effect relationships.
  • Classification: Sorting entities into discrete categories by explicit rules, turning unbounded variation into a finite, reusable map for downstream reasoning and action.
  • Completeness: No gaps in structure.
  • Constraint: Limits possibilities to guide outcomes.
  • Counterfactuals: Alternate hypothetical scenarios.
  • Embedding: A structure-preserving injection of one system faithfully into a richer one.
  • Equivalence Relation: Groups elements into equivalence classes.

Variants

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

Diagnostic Preimage Tracing · domain variant · recognized

A variant focused on identifying all possible input states, conditions, or causes that could have produced an observed output.

  • Distinct from parent: The parent covers preimage characterization generally; this variant centers diagnostic ambiguity and evidence-based narrowing.
  • Use when: An observed effect, alert, state, or symptom could have arisen from multiple upstream inputs; A team is tempted to infer one cause from one outcome; Diagnosis or remediation depends on preserving multiple plausible input explanations until evidence narrows them.
  • Typical domains: medicine, operations, software incident response, forensic analysis, policy evaluation
  • Common mechanisms: output to input traceback map, witness and counterexample set, sensitivity to mapping change review

Predicate Preimage Query · implementation variant · recognized

A variant where the target output is a Boolean or categorical predicate and the intervention builds the set of all inputs satisfying it.

  • Distinct from parent: The parent includes arbitrary mappings and output values; this variant focuses on predicate-defined membership sets.
  • Use when: The output condition is expressed as true/false, eligible/ineligible, included/excluded, or label membership; A rule, query, or filter needs to return all satisfying cases rather than a ranked subset; Auditability depends on knowing why a case is inside or outside the satisfying set.
  • Typical domains: database querying, eligibility policy, compliance screening, classification audit
  • Common mechanisms: predicate satisfaction filter, inverse lookup query, preimage table

Projection-Collision Preimage Audit · risk or failure variant · candidate

A variant focused on auditing how many rich source states collapse to the same simplified output after projection or representation loss.

  • Distinct from parent: The parent covers preimage characterization generally; this variant emphasizes many-to-one collapse under a lossy representational view.
  • Use when: A simplified display, aggregate, label, score, or category hides multiple distinct source states; Stakeholders read a projected output as if it were uniquely reversible; Intervention requires knowing what differences were lost before acting on the output.
  • Typical domains: dashboard design, model explanation, geospatial mapping, statistics, classification
  • Common mechanisms: collision analysis matrix, fiber cardinality count, sensitivity to mapping change review

Near names: Inverse-Image Characterization, Output-to-Input Traceback, Solution-Set Characterization, Fiber Analysis, Reverse Lookup Set.