Dual-Function Compatibility Test¶
Protocol — instantiates Exaptive Function Redeployment
Checks whether a feature can serve its new function without breaking its old one — and, when the two genuinely conflict, records the decision to split them.
Redeploying a feature rarely retires its first job; more often the feature is now asked to serve two masters. Dual-Function Compatibility Test is the mechanism that holds both functions live at once and probes for interference — resource contention, semantic clashes, mismatched service levels, hidden coupling — that neither function shows on its own. It is the biological problem of pleiotropy in engineering dress: one element carrying two functions, where selection for the new use can quietly degrade the old.[n1] Its distinctive output when coexistence genuinely fails is a fork decision — the recorded, reasoned choice to split the feature into two variants, each owning one function — as opposed to blessing a coexistence that will fail under load or abandoning the original use. Testing fit to the new function is not enough here; this mechanism's obsession is what the new function does to the old one.
Example¶
A university facilities team is asked whether its 500-seat flagship lecture hall can double as an emergency shelter when the region is evacuated. On paper the room is ideal: large, central, generator-backed. The Dual-Function Compatibility Test holds both uses live and hunts for interference. Scheduling: evacuation season overlaps finals week — a direct calendar collision a handful of days a year. Physical: the floor is steeply tiered for sightlines, and you cannot lay sleeping cots on stepped concrete — a clash with the shelter's core need. Access: shelter operation needs 24/7 external door control the academic badge system doesn't grant. The test classifies each conflict: the scheduling clash is mitigable (a documented rule that emergencies preempt exams), the access gap is mitigable (a wrapper on the door system), but the tiered floor is irreconcilable for sleeping.
Because both functions must exist, the test records a fork: the hall keeps the daytime shelter roles it can do — charging, information, triage on its flat stage apron — while overnight sleeping forks to the flat-floored gymnasium next door. The output is not "yes" or "no" but a map of where the two uses coexist, where they can be reconciled, and the one place they must be split — with the reasoning attached.
How it works¶
- State each function's real requirements. Old and new, side by side, including the assumptions the original use never had to write down.
- Find the interference points. Walk the two requirement sets against each other looking for contention, timing conflicts, semantic collisions, and coupling that only appears when both are active.
- Classify, don't just list. Mark each conflict compatible, mitigable (by scheduling, quota, or a wrapper), or irreconcilable. The classification, not the inventory, is the deliverable.
- Record a fork only when forced. Where a conflict is irreconcilable and both functions must persist, record the decision to split — two variants, each owning one function — with the rationale that justifies doubling the maintenance.
Tuning parameters¶
- Conflict dimensions probed — performance, semantics, security, timing, ownership. Which axes you test determines which conflicts you can find.
- Load realism — testing under nominal versus peak conditions. Dual-function conflicts often stay invisible until contention is real, so a calm-day test flatters coexistence.
- Mitigation appetite — how hard you try to reconcile a conflict (reschedule, quota, wrap) before declaring it irreconcilable. Set it low and you fork too eagerly; high and you force a doomed coexistence.
- Old-function protection weight — how much priority the original use keeps when the two collide. Turning this up defends the thing that was already working.
When it helps, and when it misleads¶
Its strength is that it protects the function that was already working — the one a naive "can this also do X?" quietly puts at risk — and drags hidden coupling into view before it degrades both uses at once.
Its failure modes cluster around the conflicts it can't provoke: those that only appear under rare load or at scale, invisible to a test run in calm conditions. It can also mis-classify — calling a mitigable clash irreconcilable and forking prematurely (doubling cost for nothing), or the reverse, blessing a coexistence that peak load will tear apart. The classic misuse is skipping the test and assuming coexistence, or running it to ratify a fork already decided on political grounds. The discipline that keeps it honest is to test under genuine contention and to exhaust isolation — a wrapper, a quota, a schedule — before accepting the standing cost of a fork.
How it implements the components¶
Dual-Function Compatibility Test fills the conflict-governance components — the ones about old-versus-new coexistence:
dual_function_compatibility_model— the classified map of where the two functions coexist, clash, or can be reconciled, built by holding both live at once.function_fork_decision_record— when a conflict is irreconcilable and both uses must persist, the recorded, reasoned decision to split the feature into two variants.
It does not build the isolation layer that resolves a mitigable conflict — that is Legacy Feature Wrapper — nor decide whether to abandon reuse for a purpose-built build, which is Purpose-Built Replacement Gate. Fork (split in two) is a different decision from replace (build new), and from the third-party side effects owned by Negative Transfer Red Team.
Related¶
- Instantiates: Exaptive Function Redeployment — this protocol is where conflicts between the old and new uses are found and, if forced, resolved by splitting.
- Consumes: Adaptation Delta Mapping supplies the adapted design whose coexistence with the original function is under test.
- Sibling mechanisms: Legacy Feature Wrapper · Adaptation Delta Mapping · 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: Assessment, Review & Assurance
Rationale: Dual-Function Compatibility Test operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it checks whether a feature can serve its new function without breaking its old one — and, when the two genuinely conflict, records the decision to split them.
Independent corroboration: The frozen evidence defines Dual-Function Compatibility Test as 'Checks whether a feature can serve its new function without breaking its old one — and, when the two genuinely conflict, records the decision to split them', so its operative form is Assessment, Review & Assurance.
Nearest alternative: Protocol, Workflow & Routine — The mechanism evaluates two function sets and produces a compatibility finding; the ordered checks structure that assessment.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Biology & Ecology
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Evolutionary biology cohered exaptation and pleiotropic tradeoffs, where a feature's new function can interfere with an older retained function.
Related originating lineages:
- Engineering & Design — Compatibility and regression testing supplied the practice of exercising old and new functions separately and together before accepting reuse.
Review resolution: Biology is primary because co-option and exaptation made old-versus-new function compatibility a recognizable problem; engineering supplies the explicit compatibility-test form.
Attribution caveat: The two-function conflict is biologically framed, while the governed test protocol is an engineering synthesis.
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¶
A fork is the last resort, not the goal: it permanently doubles what has to be maintained, so the test earns its keep as much by finding reconcilable conflicts — the ones a schedule rule or a wrapper can absorb — as by declaring irreconcilable ones. When it does fork, the decision belongs on the record with its rationale, so a later team doesn't quietly re-merge the two variants and reinherit the conflict.
[n1] In genetics pleiotropy is one gene influencing several traits, so that selection improving one can worsen another — a built-in source of adaptive conflict. A single feature carrying two functions has the same structure: tuning it for the new use can silently degrade the old, which is exactly the interference this test exists to surface. ↩