Legacy Feature Wrapper¶
Artifact — instantiates Exaptive Function Redeployment
A thin adapter built around an existing feature so a new consumer can use it through a clean interface — without modifying, or inheriting the hidden assumptions of, the original.
Some features are too valuable to replace and too fragile to touch. Legacy Feature Wrapper is the concrete artifact that redeploys such a feature by isolation rather than modification: it leaves the original completely unchanged and interposes a thin adapter that presents the new consumer with the clean interface it expects, while quietly absorbing the old feature's inherited quirks and adding the guards it never had. Where Adaptation Delta Mapping decides what to change in the feature, the wrapper's whole point is what it lets you not touch. It is the strangler-and-adapter lineage of reuse — buy the new function now, at the price of a standing layer, without a rewrite.
Example¶
A bank is launching real-time payments — money moving in seconds, at any hour. But the actual act of settling a payment lives where it has lived for thirty years: a nightly batch routine on the mainframe, written in COBOL, built on the bedrock assumption that settlement happens once a day, in bulk, after close. Rewriting it is a multi-year, bet-the-bank project. Instead, engineers build a Legacy Feature Wrapper: a small adapter service that exposes a clean REST endpoint to the new payments app, translates each real-time request into the exact record format the batch routine expects, and adds the guards the old routine never needed — idempotency keys so a retried payment can't settle twice, rate limiting so a burst can't swamp the mainframe, validation the batch job always assumed some upstream step had done.
The COBOL is not touched; the nightly batch still runs for everything else exactly as before. The new function rides on the old feature through a thin, honest layer — and because every real-time call now passes through one adapter, that adapter is also the single place to watch, throttle, and eventually strangle the old routine if it is ever replaced.
How it works¶
- Pin the original's real interface. Document what the feature actually expects and assumes — not what it's documented to do — because those undocumented assumptions are what will otherwise leak.
- Translate at the boundary. The adapter maps the new consumer's calls into the old feature's expected form and back, so neither side has to know about the other's shape.
- Add the guards the original lacked. Rate limits, idempotency, authentication, schema validation — the protections the old feature assumed away because its original caller provided them, now enforced at the wrapper.
- Leave the original untouched. The old feature keeps serving its old function unchanged; the wrapper is the only new thing, which is what makes the redeployment reversible.
Tuning parameters¶
- Wrapper thickness — a thin pass-through versus a thick translation-and-policy layer. Thicker hides more mismatch but adds latency and its own surface to maintain.
- Guard set — which protections the original lacked you enforce at the boundary. More guards make the new use safer but move behavior and blame into the wrapper.
- Fidelity versus cleanliness — expose the old feature's true semantics or a tidied abstraction. A cleaner contract is easier to consume but leaks harder under stress, when the underlying reality reasserts itself.
- Coupling direction — whether the wrapper shields the new consumer from changes in the old feature, shields the old feature from new load, or both.
- Lifespan — a permanent adapter versus scaffolding for an eventual replacement. Framing it as strangler scaffolding keeps it from silently becoming forever.
When it helps, and when it misleads¶
Its strength is the fastest safe path to redeployment: the original is untouched, so its old function is fully protected, and every new call funnels through one choke point where governance, throttling, and observability can live.
Its characteristic failure is the leaky abstraction. Under load or at the edges, the old feature's inherited constraints seep through the clean interface and surprise the new consumer with behavior the contract seemed to rule out.[n1] And a wrapper meant as temporary has a way of becoming permanent, load-bearing debt that everyone forgets is holding up production. The classic misuse is wrapping to hide a mismatch that actually needs the feature changed or replaced — papering over a structural problem instead of fixing it, so the paper is what fails when the assumptions finally break. The discipline that keeps it honest is to be explicit about what the wrapper cannot hide, and to pair it with a replacement gate so compounding leaks trigger a real decision rather than a thicker adapter.
How it implements the components¶
Legacy Feature Wrapper fills exactly one component — it is that component, made concrete:
interface_wrapper_or_adapter_layer— the adapter itself: the translation-and-guard layer between the new consumer and the unmodified original, presenting a clean interface while absorbing inherited quirks.
It does not decide which parts of the feature to change — that is Adaptation Delta Mapping, and the wrapper's premise is changing nothing. It does not judge whether the old and new uses truly coexist (Dual-Function Compatibility Test) or decide when wrapping should give way to a purpose-built build (Purpose-Built Replacement Gate).
Related¶
- Instantiates: Exaptive Function Redeployment — this artifact is how a feature is redeployed without being modified, protecting its original function.
- Consumes: Dual-Function Compatibility Test tells the wrapper which mitigable conflicts to isolate; Origin-Context Constraint Review supplies the inherited quirks it must guard against.
- Sibling mechanisms: Adaptation Delta Mapping · Dual-Function Compatibility Test · Feature Refunctioning Audit · Affordance Discovery Workshop · Bounded Co-option Trial · Origin-Context Constraint Review · Lineage-Preserving Documentation · Negative Transfer Red Team · Purpose-Built Replacement Gate · Repurposed-Feature Monitoring Dashboard · User Appropriation Review
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: Legacy Feature Wrapper operates as a persistent arrangement of components, resources, interfaces, or technical topology because it a thin adapter built around an existing feature so a new consumer can use it through a clean interface — without modifying, or inheriting the hidden assumptions of, the original
Independent corroboration: The frozen evidence defines Legacy Feature Wrapper as 'A thin adapter built around an existing feature so a new consumer can use it through a clean interface — without modifying, or inheriting the hidden assumptions of, the original', so its operative form is Structure, Architecture & Configuration.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Software architecture developed adapter and strangler patterns that wrap inherited features behind clean interfaces.
Related originating lineages:
- Engineering & Design — Interface and retrofit engineering supplied reuse without invasive substrate change.
Review resolution: Both independent reviews place the primary lineage in computer_science. The queued differences (alternate_origin_disagreement, origin_mode_disagreement, domain_reach_disagreement) concern secondary metadata rather than primary provenance. The final retains engineering_design only where a reviewer supplied a formative-lineage rationale; downstream application by itself is not treated as origin. origin_mode=cross_disciplinary_synthesis records the relationship among origin traditions, while domain_reach=multi_domain records application breadth separately. encyclopedia_synthesis=false reflects whether either reviewer identified a corpus-specific synthesis, and confidence=high preserves the more cautious evidence assessment.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
A wrapper is isolation, not resolution. It contains the old feature's inherited constraints; it does not remove them — so it trades a modification cost now for a standing leak-risk later. That trade is worth making only while the original genuinely must stay untouched; once it doesn't, the wrapper is either retired into a real change (Adaptation Delta Mapping) or promoted into the on-ramp for a replacement, not left to ossify.
[n1] Joel Spolsky's Law of Leaky Abstractions — every non-trivial abstraction leaks the details it was meant to hide. A wrapper is exactly such an abstraction over a legacy feature, so its clean interface will, under enough stress, expose the very inherited assumptions it was built to conceal. ↩