Preimage Table¶
Reference artifact — instantiates Preimage Set Characterization
Publishes the finished output-to-input sets as a static reference so downstream users read the preimage off the page instead of re-deriving it, with usage caveats printed alongside.
A Preimage Table is the published artifact, not the act of computing. It records, output by output, the set of inputs that map there — one row per output value, its enumerated preimage in the cell — so that anyone facing that output later can look up the answer rather than recompute it. Where the other mechanisms are procedures that run, the table is the durable thing they leave behind: a shareable, versioned document consumers read directly. Its defining discipline is that it is a frozen snapshot — accurate as of when it was built, under the mapping it was built for — and so it carries its usage caveats on the page, because a stale or misread table is how a preimage computed once quietly becomes a wrong answer trusted forever.
Example¶
An analytical chemistry lab publishes a Preimage Table for a mass spectrometer: each row is a measured molecular mass (an output), and the cell lists every molecular formula consistent with it within the instrument's tolerance (the preimage). A mass of 180.063 Da resolves to a short list — glucose, fructose, galactose, and a handful of other isomers — all sharing that mass. A chemist who measures 180.063 reads the row and sees, immediately, that the mass alone does not single out glucose; it names a set.
The table's value is exactly that it hands over the set, packaged for reuse, so the reader is not tempted to treat one measured mass as one compound. Printed with it is the guardrail: "valid for tolerance ±0.005 Da; formulas above 200 Da are not exhaustively enumerated; confirm isomers by a second method." That caption is what keeps the convenience of a lookup table from hardening into a false identification.
How it works¶
- Choose the key. Fix which output values index the rows and at what resolution, so each row addresses a well-defined output condition.
- Fill the cells. Populate each row with the enumerated inputs for that output — the members handed over by whatever mechanism did the deriving or retrieving.
- Annotate each entry. Mark multiplicity, coverage caveats, and the mapping version each row assumes, so a reader sees the set's status, not just its contents.
- Print the guardrail and freeze. Attach the usage caveats to the artifact itself and stamp it with a build date and version, because from publication on it is a snapshot, not a live query.
Tuning parameters¶
- Key resolution — how finely output values are split into rows. Fine resolution gives precise, short preimages but a huge table; coarse resolution is compact but pools distinct outputs into one over-broad row.
- Entry completeness policy — whether cells list the full preimage, a capped sample, or "see live query for the rest." Full cells are authoritative but can be enormous; capped cells are readable but must say so or they mislead.
- Refresh cadence — how often the table is rebuilt against the current mapping. Frequent rebuilds keep it honest but cost effort; a stale table silently answers today's question with yesterday's mapping.
- Caveat prominence — how loudly the usage guardrail is printed. Prominent caveats resist misuse but clutter; buried ones are ignored exactly when they matter.
When it helps, and when it misleads¶
Its strength is reuse and shared truth: once the preimage of each output is computed and published, a whole organization reads the same set from the same artifact — a lookup table in the classic sense[n1] — instead of re-deriving it inconsistently, and the packaging itself discourages collapsing a set-valued row into a single input.
Its failure mode is staleness and misread scope: a table is only correct for the mapping and moment it was built, and a reader who trusts it after the mapping changed, or who ignores the tolerance and completeness caveats, is trusting a snapshot as if it were live truth. The classic misuse is treating an old or capped table as authoritative and exhaustive — reading "these are the formulas" when the honest claim was "these were the formulas under last quarter's calibration, up to 200 Da." The guarding discipline is to stamp every table with its build date, mapping version, and coverage limits, print the guardrail where the reader cannot miss it, and route any high-stakes lookup back to a live derivation rather than a shelf copy.
How it implements the components¶
candidate_input_enumeration— each row's cell holds the enumerated preimage for that output, packaged for direct reading.downstream_use_guardrail— the printed caveats (tolerance, coverage, mapping version, freshness) that govern how the published set may and may not be used.
It does not implement preimage_membership_rule or completeness_evidence — deriving the entries and certifying they omit nothing are the jobs of Predicate Satisfaction Filter and Constraint-Solver Backsolve; the table publishes results it is given rather than establishing them. It differs from Inverse Lookup Query, its nearest twin, in that the query is a live probe returning a fresh answer while the table is a static snapshot read off the page.
Related¶
- Instantiates: Preimage Set Characterization — the table is the durable, shareable form the characterization takes once computed.
- Consumes: Constraint-Solver Backsolve and Inverse Lookup Query supply the enumerated entries the table publishes.
- Sibling mechanisms: Inverse Lookup Query · Constraint-Solver Backsolve · Predicate Satisfaction Filter · Output-to-Input Traceback Map · Collision Analysis Matrix · Fiber Cardinality Count · Sensitivity-to-Mapping-Change Review · Witness and Counterexample Set
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Preimage Table operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it publishes the finished output-to-input sets as a static reference so downstream users read the preimage off the page instead of re-deriving it, with usage caveats printed alongside.
Independent corroboration: The frozen evidence defines Preimage Table as 'Publishes the finished output-to-input sets as a static reference so downstream users read the preimage off the page instead of re-deriving it, with usage caveats printed alongside', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Mathematics
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Tables of inverse images directly operationalize the mathematical notion of a preimage under a mapping.
Related originating lineages:
- Computer Science & Software Engineering — The computer_science tradition materially shaped Preimage Table through its own practice of algorithms, data structures, formal interfaces, and software-system practice.
Review resolution: Both blind reviewers agree that mathematics is the primary origin. Explicit reconciliation resolves reported ambiguity, alternate origin disagreement, origin mode disagreement, encyclopedia synthesis disagreement. Formative alternate lineages are retained as computer_science; later breadth of use is recorded separately as domain_reach=multi_domain, while origin_mode=cross_disciplinary_synthesis describes the relationship among origin lineages.
Attribution caveat: The exact encyclopedia label appears to synthesize established practices; the primary domain identifies the strongest formative lineage, while the alternates record material ingredients rather than downstream uses.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] A rainbow table is a precomputed table that maps hash outputs back to the inputs that produce them, used to reverse password hashes quickly. It is a literal preimage table — and a standing reminder that such a table is only as good as the input space it was built over and the mapping version it assumes. ↩