Skip to content

Structure-Preserving Map Specification

A specification artifact — instantiates Structure-Preserving Embedding Design

Writes the embedding down as an explicit injection rule plus a preservation contract, so what must still be true after mapping is fixed before anything is moved.

The thing that makes this mechanism itself and not its siblings is that it declares, it does not do. A Structure-Preserving Map Specification states two things formally: the injection rule that sends each source element to a host image, and the preservation contract — the relations and operations that rule must respect, written as commuting conditions (if a ∘ b holds in the source, f(a) ∘ f(b) must hold in the host). It is the object everything else is measured against — the table enumerates it, the tests check against it, the recovery map inverts it — yet it computes nothing on its own. Its discipline is negative as much as positive: a contract that stays silent about an operation has quietly given that operation permission to break.

Example

A team is moving a role hierarchy into a new identity-and-access platform. The source isn't just a list of roles; it's a partial orderManager inherits everything Analyst can do, Admin inherits Manager. Before anyone touches the platform, they write the spec. The injection rule: each source role maps to exactly one host role, distinct roles stay distinct. The preservation contract: the inheritance order must survive — if role A inherits B in the source, A must inherit B in the host (an order-preserving, or monotone, map). And crucially, an explicit out-of-scope clause: the display order of roles in the admin UI is free to change.

The payoff comes later. When an engineer proposes folding two rarely-used roles into one "to simplify the migration," the contract is what answers: the merge would erase an inheritance edge the spec promised to keep, so it's a contract change, not a convenience — and it has to be decided as one, in the open, rather than discovered when someone loses access.

How it works

  • Name the structure, not just the objects. Enumerate the source relations and operations that carry meaning — order, composition, identity — because those, not the elements, are what can silently break.
  • State the injection rule as a total, well-defined assignment from source to host, and say whether it must be injective (distinct sources stay distinct) or may collapse.
  • Write the contract as commuting conditions — which source relations and operations must have host counterparts that agree — rather than a vague promise of fidelity.
  • Declare the drop-list explicitly. What the map is permitted to lose is written down, so silence is never mistaken for a guarantee.

Tuning parameters

  • Injectivity requirement — whether distinct source elements must map to distinct host images. Requiring it forbids collisions but can be infeasible in a coarser host.
  • Contract strictness — full isomorphism (everything preserved and invertible) versus homomorphism (operations preserved, not necessarily reversible) versus a named subset. Stricter is more faithful and harder to satisfy.
  • Granularity of preserved relations — which relations are in-contract. Each one added raises fidelity and the cost of compliance.
  • Drop-list completeness — how much you commit, up front, to not preserving. A fuller drop-list prevents false expectations but forces hard admissions early.

When it helps, and when it misleads

Its strength is that it turns "we mapped it faithfully" from a feeling into a checkable promise, and it gives the table-builders, testers, and reconstructors a shared clause to argue over instead of arguing past each other. The named anchor is exact: a homomorphism is precisely a map that respects the operations, and an isomorphism adds invertibility on top.[1]

Its central failure is the specification written after the mapping is built — reverse-engineered from the implementation so it can only ever describe what was done, never flag a violation. It also fails silently when the contract omits a relation that turned out to matter: the map is "correct" against a contract that forgot the thing that broke. The discipline that guards against both is to author the contract before the injection, derived from the source's meaning, and to have someone other than the implementer own it.

How it implements the components

This mechanism realizes the declaration side of the archetype — it fixes the map and the promise, and leaves execution and checking to others:

  • injection_rule — its core content: the explicit, total assignment of source elements to host images.
  • preservation_contract — the clauses stating which relations and operations the injection must keep, and which it may drop.

It does not inventory the source in full or log what is lost — that is the Schema Mapping Table; it does not model the host space or its metric — that is the Vector Embedding Model; and whether the contract actually holds is checked by Round-Trip Validation Test and the Invariant Preservation Test Suite, not asserted here.

  • Instantiates: Structure-Preserving Embedding Design — this specification is the reference object the rest of the appraisal implements and tests against.
  • Sibling mechanisms: Schema Mapping Table · Round-Trip Validation Test · Vector Embedding Model · Ontology Alignment Map · Serialization with Reconstruction Schema · Invariant Preservation Test Suite · Adapter or Wrapper Layer · Coordinate Chart Mapping · Graph Embedding · Embedding Collision Probe · Nearest-Neighbor Audit

Notes

The specification is an input, not a proof — it says what must hold, never that it does. Keeping the declaration separate from its verification is exactly what lets a team tighten the contract, or renegotiate a drop-list clause, without re-running every test that depends on it.

References

[1] A homomorphism is a map between two systems that preserves their operations — the defining notion of a structure-preserving map. An isomorphism is a homomorphism that is also invertible, so no structure is lost in either direction; the contract's strictness dial is essentially a choice of where on that spectrum to sit.