Skip to content

Decoupling & Interfaces

← Back to Mechanisms by Solution Family

Solutions that reduce harmful dependency by inserting contracts, adapters, abstractions, or replaceable boundaries between interacting parts.

197 mechanisms across 22 solution archetypes in this solution family. A mechanism inherits the primary family of the archetype it instantiates; family is about the move the solution makes, not the domain where it originated.

Archetype Overview

This unusually large family has a compact overview for orientation. Each archetype name jumps to its fully visible section below.

Solution archetypeMechanismsDescription
Arbitrage Capture10Identify a cross-context mismatch in value, information, timing, or resources and move across the boundary to capture the difference.
Archetype Pattern Indexing8Index recurring patterns by structural signature so they can be recognized, compared, and reused across contexts.
Asymmetric Interface Tolerance Calibration14Treat producer strictness and receiver tolerance as separate interface design choices, then choose and govern the regime that preserves compatibility without hiding drift or unsafe ambiguity.
Boundary-Cost Coarsening Management7When boundary maintenance cost pushes many small units into fewer larger ones, measure the size distribution, preserve valuable boundaries, and channel or reverse consolidation before useful microstructure disappears.
Computability Boundary Mapping18Before optimizing or automating a problem, determine whether any correct terminating procedure can solve the declared class, prove that boundary, and publish a weaker but honest fallback when it cannot.
Concurrent Cross-Functional Integration10Integrate specialized perspectives in parallel through shared artifacts, live interfaces, synchronized decisions, and continuous recombination so conflicts appear while they are still cheap to resolve.
Decoupling via Interface0Interpose a stable interface between components so each can change without being exposed to the other's internals.
Discourse Window Recalibration9Recalibrate what can be safely and legitimately discussed by mapping the current sayability boundary, sequencing exposure, and monitoring legitimacy, backlash, and dissent.
Displacement-Aware Capacity Admission9Before admitting or expanding one activity in a finite shared substrate, identify what it will displace and protect, resize, phase, offset, relocate, or reject the expansion accordingly.
Donor-Coupled Capacity Governance9When a recipient appears viable because a donor/source continuously sustains it across a boundary, make the subsidy explicit, test real capacity, and choose continuation, formalization, transition, or withdrawal safeguards.
Edge-Zone Interface Design10When two regimes meet, design the edge as a real third zone rather than treating it as a thin line or incidental spillover.
Editorial Independence Firewall6Protect the evaluator’s judgment from affected-party control by separating authority, incentives, access, correction rights, and accountability channels.
Equilibrium-Aware Capacity Intervention Design9Before adding an attractive path or capacity option to a self-optimizing network, test the equilibrium response and add pricing, routing, metering, access, or rollback controls so local choices do not make the whole system worse.
Evidence-Bounded Trust Governance6Accept vulnerability only within an explicit, evidence-bounded reliance envelope that can expand, contract, repair, or end as behavior and conditions change.
Exaptive Function Redeployment11When an inherited feature appears useful for a function it was not originally built or selected for, map its origin constraints, test the new affordance, adapt only what is necessary, and govern conflicts between old and new uses.
Fragmented Rights Clearance Design9Unlock under-used resources by mapping fragmented exclusion rights and replacing costly one-by-one permission assembly with legitimate clearance, pooling, default, brokerage, or bundling paths.
Harmful Arbitrage Closure10Close mismatches that invite harmful exploitation by aligning rules, prices, access, or accountability across contexts.
Impedance Matching and Coupling Optimization6Match source, interface, and receiver properties so useful transfer increases without creating reflection, instability, overload, fragility, or hidden loss.
LIFO Stack Discipline8Use a last-in, first-out nesting discipline whenever safe work depends on closing the current context before returning to the one beneath it.
Representation-Independent Interface Contract13Specify what a component does at its public surface, hide how it does it, and test that any replacement implementation honors the same contract.
Restraint–Orientation Degree Decoupling0Separate the primary restraint load path from independently governed orientation degrees so alignment does not require moving or torquing the load-bearing reference.
Specification-to-Execution Lowering15Lower a what-level specification into an executable how through explicit refinement stages, carrying forward the contract, assumptions, invariants, evidence obligations, and trace needed to justify that the result actually realizes the intent.

Arbitrage Capture

Identify a cross-context mismatch in value, information, timing, or resources and move across the boundary to capture the difference.

10 mechanisms · View full solution archetype

  • Conversion Layer — Translates value trapped in one form, format, or credential into a form the target context can use, so a mismatch created by incompatibility becomes actionable.
  • Cross-Market Resale — Sources a good where it is cheap or idle and redeploys it where it is valued more, keeping the net margin that survives after all transfer costs.
  • Financial Spread Trade — Holds offsetting positions in two equivalent or linked instruments to capture the price spread between them, buffered against the risk that the spread widens before it converges.
  • Information Arbitrage Workflow — Turns a lawful information advantage into a move — route, buy, warn, prepare — made in the window before that information is widely reflected in others' behavior.
  • Location-Cost Repositioning — Places work, production, or service delivery where cost or availability is better — on the twin conditions that target quality survives the move and local impact is not simply exported harm.
  • Platform Matching Market — Runs a mediated exchange where undervalued supply and underserved demand discover each other, governed by scale limits and a fair split so it captures the mismatch without extracting from either side.
  • Procurement Substitution — Switches sourcing to an equivalent alternative where price, access, or terms are better — but only once equivalence is verified and the full switching cost is netted out.
  • Regulatory Boundary Review — Reviews a rule-regime difference for legality, intent, and harm before any regulatory mismatch is acted on — a guardrail with a veto, not a licence to exploit loopholes.
  • Resource Reallocation Brokerage — Stands up an intermediary that names two contexts and routes one's idle capacity to the other's unmet demand, capturing the value trapped in underuse.
  • Temporal Shift Capture — Moves activity, storage, work, or purchasing across time — into off-peak slack or ahead of a lag — while monitoring the timing gap so it exits before the gap closes.

Archetype Pattern Indexing

Index recurring patterns by structural signature so they can be recognized, compared, and reused across contexts.

8 mechanisms · View full solution archetype

  • Anti-Pattern Catalog — Indexes recurring structures that reliably go wrong, pairing each with the near-misses that are actually fine and the remediation that follows once a match is confirmed.
  • Case Library — Indexes concrete, cited precedents by their case features so a new situation retrieves the closest prior case rather than an abstract rule.
  • Design Pattern Catalog — Indexes proven solution structures by their forces and structure, with known uses and the neighboring patterns each is easily confused with.
  • Diagnostic Atlas — Maps presenting symptoms to candidate patterns with the look-alikes to rule out and a stated confidence in the fit.
  • Pattern Card Template — A fixed entry form that forces every pattern to carry the minimum fields — provenance, confidence, and the rest — needed for retrieval and reuse.
  • Solution Archetype Archive — A governed, versioned repository that preserves each archetype's provenance, variants, and merge history on a maintenance cadence to prevent duplicate drafting.
  • System Archetype Index — Indexes recurring feedback-loop structures by their dynamics, distinguishing look-alike loops and naming the leverage point each implies.
  • Tagging Schema — A controlled vocabulary of facets and tags, governed and maintained, that turns free-text search into structured retrieval by problem features.

Asymmetric Interface Tolerance Calibration

Treat producer strictness and receiver tolerance as separate interface design choices, then choose and govern the regime that preserves compatibility without hiding drift or unsafe ambiguity.

14 mechanisms · View full solution archetype

  • Adapter or Translation Shim — Inserts a translating layer between two parties so a producer's legacy or foreign variants are accepted and re-emitted as the receiver's current canonical form.
  • Deprecation Warning and Tightening Schedule — Turns tightening into an announced, dated plan — warn about a tolerated variant, give producers time to migrate, then stop accepting it on a committed schedule.
  • Feature-Flagged Strictness Rollout — Ships a stricter regime behind a flag and ramps it across cohorts on live safety evidence with instant rollback, so a tightening never becomes a surprise outage.
  • Fuzz Testing Against Acceptance Boundary — Bombards the acceptance boundary with generated malformed and edge-case inputs to find where it crashes, silently accepts the invalid, or repairs into the wrong meaning.
  • Lenient Parser with Canonicalizer — A tolerant front-door parser that accepts a wide envelope of input variants and reduces each to a single canonical form before anything downstream sees it.
  • Malformation Rate Dashboard — Turns the stream of rejected and repaired inputs into a live rate-and-trend view per producer, so tolerance drift becomes visible instead of silent.
  • Negative Case and Malformed Corpus — A curated collection of known-bad inputs, each paired with the verdict and diagnostic it should provoke, held as the fixed yardstick for what the interface must refuse.
  • Quarantine and Manual Review Queue — Holds inbound artifacts that are neither cleanly acceptable nor safely rejectable in a queue, so a human resolves the ambiguous middle instead of the parser silently guessing.
  • Strict Bidirectional Contract Gate — Enforces one strict contract in both directions — nothing off-spec may be sent or accepted — and routes the rare legitimate deviation through a named exception path rather than silent tolerance.
  • Strict Output Linter — Checks everything a system is about to emit against the canonical form and blocks non-conformant output at the source, so producers never teach the ecosystem a sloppier contract.
  • Strict-Mode Shadow Run — Runs a stricter rule set in log-only mode against live traffic to count exactly what it would reject — before any of it actually blocks — so tightening is a measured step, not a gamble.
  • Tolerant Reader / Strict Writer Policy — Sets the interface's standing regime as deliberately asymmetric — strict about what the system emits, liberal about what it accepts — and writes that choice down as policy rather than leaving it to each parser.
  • Unknown-Field Handling Rule — Fixes in advance what a receiver does with fields it doesn't recognize — ignore, preserve, or reject — so tomorrow's additions don't break today's readers.
  • Version Negotiation or Capability Probe — Has the two sides advertise and agree on a shared version or capability set before exchanging real data, so each tailors what it sends and expects to what the other actually supports.

Boundary-Cost Coarsening Management

When boundary maintenance cost pushes many small units into fewer larger ones, measure the size distribution, preserve valuable boundaries, and channel or reverse consolidation before useful microstructure disappears.

7 mechanisms · View full solution archetype

  • Anti-Coarsening Inhibitor Protocol — A materials-inspired protocol for adding pinning agents, stabilizers, membranes, standards, or constraints that slow undesired unit growth.
  • Capped-Growth or Split Rule — A rule that triggers splitting, spin-outs, local autonomy, or added interfaces when a unit crosses diseconomy or concentration limits.
  • Controlled Consolidation Gate — A checklist that permits mergers or aggregation only when boundary-cost savings outweigh lost diversity, resilience, and reversibility.
  • Interface-Cost Accounting — A method for separating the real cost of maintaining boundaries from the value those boundaries preserve.
  • Reseeding or Nucleation Program — A workflow for introducing new small units, pilots, categories, teams, grains, entrants, or local nodes after excessive coarsening.
  • Size-Distribution Dashboard — A dashboard that tracks unit count, size skew, merger rate, small-unit attrition, and concentration over time.
  • Target Granularity Review — A recurring review that asks whether the current number and scale of units still match the system’s purpose.

Computability Boundary Mapping

Before optimizing or automating a problem, determine whether any correct terminating procedure can solve the declared class, prove that boundary, and publish a weaker but honest fallback when it cannot.

18 mechanisms · View full solution archetype

  • Abstract Interpretation or Model Checking — Decides a property soundly on a finite abstraction of an otherwise-undecidable system, trading exactness for a guaranteed answer that never misses a real violation.
  • Bounded-Domain Exhaustive Search — Turns a question that is undecidable in general into a decidable one by fixing a finite bound and mechanically checking every case inside it.
  • Computability Boundary Decision Record — Records where a project drew the computability boundary, which guarantee it will ship, and what would force the line to be redrawn.
  • Computational Complexity Analysis — Once a problem is known solvable in principle, measures how its cost grows with input size to place it in a complexity class and separate the tractable from the merely computable.
  • Constructive Algorithm and Correctness Proof — Settles a problem on the decidable side by exhibiting an actual algorithm and proving it both total and correct — the proof and the procedure are one object.
  • Diagonalization Impossibility Proof — Proves that no algorithm can decide a class by constructing, from any candidate decider, a self-referential input on which it must be wrong.
  • Enumeration and Dovetailing — Semi-decides a class by fairly interleaving all candidate computations, halting 'yes' the moment one succeeds and otherwise running on — buying a complete yes-side at the cost of no honest 'no'.
  • Fallback-Mode Router — Dispatches each query to the strongest method that fits where it falls relative to the computability boundary — exact, sound-approximate, bounded, or escalated — under an explicit fallback contract.
  • Halting-Problem Reduction — Proves a target problem undecidable by wiring a known-undecidable problem (canonically the halting problem) into it, so effort on a universal solver stops before it starts.
  • Language-Fragment Restriction — Regains a terminating decision procedure by narrowing the language problems are stated in to a syntactic fragment known to be decidable, trading expressive power for a guaranteed answer.
  • Many-One Reduction Proof — Transfers a problem's decidability or hardness verdict along a single total computable map that preserves membership, exhibiting the mapping itself as the proof.
  • Promise-Problem Restriction — Makes a hard problem solvable by narrowing the inputs the solver is accountable for to those meeting a stated promise, leaving promise-violating inputs as don't-cares.
  • Proof by Counterexample — Refutes an over-broad universal claim — that some method handles an entire class — by exhibiting one well-formed instance on which it demonstrably fails.
  • Proof Checking — Independently re-verifies a decidability or impossibility proof step by step, so the boundary claim rests on a checked argument rather than on its author's authority.
  • Reduction-Direction Checklist — A pre-flight check that a reduction runs from the known-hard problem into the target — the direction that actually proves hardness — with every assumption named before the verdict is trusted.
  • Semi-Decision with Explicit Unknown — Runs a sound one-sided recognizer that confirms YES when it can, but returns an explicit UNKNOWN at a declared resource bound instead of looping forever or faking a NO.
  • Theorem-Prover-Guided Search — Uses an automated or interactive prover to search for and mechanically check the proof or certificate a boundary claim rests on, recording the verified guarantee and any open residue.
  • Turing-Reduction Analysis — Asks whether a problem becomes solvable given an oracle for another, placing it among the degrees of relative computability rather than in a flat decidable/undecidable split.

Concurrent Cross-Functional Integration

Integrate specialized perspectives in parallel through shared artifacts, live interfaces, synchronized decisions, and continuous recombination so conflicts appear while they are still cheap to resolve.

10 mechanisms · View full solution archetype

  • Big-Room Planning or Concurrent Set-Based Workshop — A periodic all-hands planning event where every function aligns dependencies, reserves shared capacity, and commits to an integration cadence — carrying several options forward where interfaces are still unstable.
  • Concurrent Engineering Workcell — A working arrangement where the specialists developing tightly coupled elements design them together in real time, so constraints and interfaces are negotiated as the design takes shape rather than discovered at assembly.
  • Cross-Functional Design Review — Convenes the affected functions to resolve one bounded cross-functional tradeoff on shared evidence — with a named decider and a recorded rationale — before the commitment hardens.
  • Cross-Functional Swarm on Integration Constraint — Temporarily redirects the minimal set of specialists onto the single issue throttling integration — under a timebox and a stop-rule — then returns ownership.
  • Dependency and Change Notification Board — A live shared surface that shows current cross-team dependencies, interface versions, and changes — and pushes each change to the owners it affects until they acknowledge and act.
  • Integrated Product or Service Team — Stands up one small, complete team that owns an end-to-end outcome — with the specialist authority and protected capacity to integrate continuously instead of handing off.
  • Integrated Readiness and Release Review — A whole-system readiness gate that checks the release unit operates end to end and that a named owner accepts the transition — not that each function is locally green.
  • Integration Build or End-to-End Increment — Frequently recombines the teams' partial outputs into a running end-to-end increment and runs cross-functional cases, so interface and workflow failures surface now instead of at final assembly.
  • Interface Control Document and Contract Test — Makes each interface between functions explicit, versioned, and executable — a written contract plus automated tests that fail the moment a provider or consumer breaks compatibility.
  • Shared System Model or Digital Thread — Connects every function's requirements, designs, decisions, interfaces, tests, and changes into one authoritative, traceable model, so everyone works from the same current state and a change's impact is visible along the links.

Decoupling via Interface

Interpose a stable interface between components so each can change without being exposed to the other's internals.

0 mechanisms · View full solution archetype

No mechanism currently instantiates this archetype as its primary archetype.

Discourse Window Recalibration

Recalibrate what can be safely and legitimately discussed by mapping the current sayability boundary, sequencing exposure, and monitoring legitimacy, backlash, and dissent.

9 mechanisms · View full solution archetype

  • Acceptability Window Map — A visual or tabular map of positions inside, near, and outside the current discourse window, annotated with social costs and venue constraints.
  • Backlash and Harm Signal Dashboard — A monitoring tool for participation changes, sanction patterns, misinformation spread, trust shifts, and affected-party harm signals.
  • Consideration-Not-Endorsement Disclaimer — A repeated communication convention that makes clear when a position is being examined, not adopted or normalized as correct.
  • Counterframe Register — A record of objections, alternative frames, affected-party interpretations, and evidence challenges that remain visible during window movement.
  • Discourse Boundary Label Review — A review of labels such as radical, mainstream, taboo, settled, experimental, or out-of-bounds to see how they enforce or move the window.
  • Graduated Public Exposure Sequence — A staged sequence that moves from private review to small forums, pilot language, public explanation, and broader institutional adoption or rejection.
  • Managed Discourse Retreat Plan — A plan for withdrawing a position from active normalization when further exposure causes harm or when the legitimacy rationale fails.
  • Pilot Forum or Discussion Sandbox — A bounded forum where participants can test whether a formerly unsayable position can be examined without harm, panic, or premature commitment.
  • Window Shift Retrospective — A post-shift review that asks what moved, what evidence mattered, who gained or lost voice, and whether the boundary should expand, contract, or stabilize next.

Displacement-Aware Capacity Admission

Before admitting or expanding one activity in a finite shared substrate, identify what it will displace and protect, resize, phase, offset, relocate, or reject the expansion accordingly.

9 mechanisms · View full solution archetype

  • Capacity Reservation Rule — A rule that reserves part of the shared substrate for incumbent, public-good, safety, ecological, or vulnerable uses.
  • Crowding-Out Monitoring Dashboard — A dashboard tracking substrate utilization, entrant growth, incumbent shrinkage, protected-floor violations, and mitigation status.
  • Displacement Impact Assessment — A pre-admission assessment estimating which incumbent uses will shrink when a new activity consumes shared substrate.
  • Incumbent Use Register — A register of existing formal and informal uses of a shared substrate, including protected functions and dependency strength.
  • Moratorium and Reversal Gate — A stop rule that pauses or reverses expansion when observed displacement crosses protected thresholds.
  • Offset or Relocation Plan — A plan for relocating displaced activity, expanding substrate, compensating affected parties, or substituting alternate capacity.
  • Phased Admission Trial — A staged rollout of the entrant with measurement gates, rollback authority, and incumbent impact review.
  • Shadow Displacement Accounting — A counterfactual accounting method that estimates what incumbent activity would have remained without the entrant.
  • Substrate Capacity Budget — A budget stating total shared capacity, reserved floors, discretionary slack, phase-in allowance, and emergency reserve.

Donor-Coupled Capacity Governance

When a recipient appears viable because a donor/source continuously sustains it across a boundary, make the subsidy explicit, test real capacity, and choose continuation, formalization, transition, or withdrawal safeguards.

9 mechanisms · View full solution archetype

  • Capacity Milestone Agreement — Defines the recipient capabilities and evidence required before support changes or autonomy claims are accepted.
  • Cross-Boundary Support Agreement — Formalizes rights, obligations, data sharing, support levels, review cadence, and exit/continuation rules.
  • Donor Stress Test — Examines whether the donor can maintain the subsidy under shocks without degrading its own critical functions.
  • Source-Sink Monitoring Dashboard — Tracks donor flow, recipient baseline, support share, donor stress, and autonomy-claim status over time.
  • Subsidy Dependency Assessment — Assesses how much of recipient performance depends on donor flow and which functions would fail without it.
  • Subsidy Ledger — Maintains a visible record of support flows, costs, beneficiaries, duration, and governance terms.
  • Support Load Quota — Caps donor obligation or hidden subsidy share until support is diversified, repriced, or capacity is increased.
  • Taper and Handoff Plan — Coordinates staged reduction, localization, substitution, or formalization of support with contingency buffers.
  • Withdrawal Rebound Drill — Simulates or rehearses support loss to reveal rebound failure paths and needed buffers.

Edge-Zone Interface Design

When two regimes meet, design the edge as a real third zone rather than treating it as a thin line or incidental spillover.

10 mechanisms · View full solution archetype

  • Adaptive Boundary Repositioning — Treats the edge's position as provisional and relocates it on a pre-set trigger, moving the boundary as evidence shows its current line has stopped being valid.
  • Cross-Boundary Flow Gate — A controlled crossing point that maps every flow between two regimes and permits, filters, or blocks each by explicit rule instead of letting the boundary leak.
  • Ecotone Inventory — Finds and catalogs every edge zone in a system — each with the two regimes it divides and the phenomena that live only there — so edges stop being invisible to interior-oriented rules.
  • Edge Stewardship Review — A recurring governance forum that gives the edge an accountable owner and works its opportunity-and-risk ledger, so the interface neither interior claims stops being an orphan.
  • Edge Transect Mapping — Drives a measured line through a single edge to profile how conditions change across it and read off the edge's true width.
  • Edge-Condition Dashboard — Turns the edge zone's live condition into a running set of indicators and alerts, so its state is watched continuously rather than noticed only when something has already broken.
  • Edge-Effect Impact Assessment — Estimates how far the edge's influence reaches into each interior and what it destroys or creates there, sorted into a ledger of edge risks and opportunities.
  • Gradient Heatmap — Renders the cross-edge gradient as a colour field, making the invisible transition visible and showing where the edge zone actually begins and ends.
  • Interface Broker Role — A standing person or team that personally holds the interface — translating between the two sides, controlling what crosses, and owning the edge as their patch.
  • Interior-to-Edge Ratio Check — Measures the proportion of protected interior to exposed edge and tests it against a guardrail, flagging when a design has too much edge and too little core.

Editorial Independence Firewall

Protect the evaluator’s judgment from affected-party control by separating authority, incentives, access, correction rights, and accountability channels.

6 mechanisms · View full solution archetype

  • Advertising/Editorial Firewall — Structurally severs the revenue and advertising operation from editorial judgment, and blinds each side to the other, so that who pays can never decide what is said.
  • Conflict Disclosure and Recusal Form — A pre-judgment intake instrument that elicits an evaluator's ties to the parties a decision could affect and, when a disqualifying tie exists, routes the case to recusal before judgment begins.
  • Correction Without Control Workflow — A process that lets affected parties contest facts and win genuine corrections while structurally denying them any control over framing, timing, conclusions, or a pre-publication veto.
  • Editorial Charter — A founding, ratified document that names the protected domain of judgment and vests final authority in the evaluator, so independence rests on written mandate rather than goodwill.
  • Independence Breach Review — A retrospective, case-specific investigation run by an independence officer into whether an affected party actually controlled, suppressed, or distorted a particular judgment — adjudicated and logged as precedent.
  • Influence Attempt Log — A running, contemporaneous record of every attempt to pressure, preview, delay, or veto a judgment, turning ambient and deniable pressure into a documented, reviewable pattern.

Equilibrium-Aware Capacity Intervention Design

Before adding an attractive path or capacity option to a self-optimizing network, test the equilibrium response and add pricing, routing, metering, access, or rollback controls so local choices do not make the whole system worse.

9 mechanisms · View full solution archetype

Evidence-Bounded Trust Governance

Accept vulnerability only within an explicit, evidence-bounded reliance envelope that can expand, contract, repair, or end as behavior and conditions change.

6 mechanisms · View full solution archetype

Exaptive Function Redeployment

When an inherited feature appears useful for a function it was not originally built or selected for, map its origin constraints, test the new affordance, adapt only what is necessary, and govern conflicts between old and new uses.

11 mechanisms · View full solution archetype

  • Adaptation Delta Mapping — Maps the smallest set of changes that make an inherited feature actually fit its new function — and, just as important, the parts that must be left untouched.
  • Affordance Discovery Workshop — A facilitated session that mines an existing feature for latent affordances and turns the promising ones into explicit claims about new functions it could be redeployed to serve.
  • Bounded Co-option Trial — Runs the new use of a feature in a small, contained, reversible slice of the real system to get honest evidence before committing to redeploy it everywhere.
  • Dual-Function Compatibility Test — 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.
  • Feature Refunctioning Audit — A systematic sweep that finds features already being used for functions they weren't built for, draws a clear boundary around each, and grades how well the borrowed feature actually fits its new job.
  • Legacy Feature Wrapper — 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.
  • Lineage-Preserving Documentation — Keeps a durable, dated record of what a repurposed feature was originally built for and what it has meant, so its new use can't quietly rewrite its history.
  • Origin-Context Constraint Review — Reconstructs the context a feature was built for and catalogs the assumptions it silently carries, flagging the ones that will misfire once it serves its new function.
  • Purpose-Built Replacement Gate — A decision checkpoint that periodically asks whether a repurposed feature is still the right vehicle, or whether its new function has outgrown it and now warrants a purpose-built replacement.
  • Repurposed-Feature Monitoring Dashboard — A live instrument that watches a feature serving two functions at once, tracking whether the new use stays healthy and the original use isn't quietly being degraded.
  • User Appropriation Review — Examines how people have repurposed a feature on their own and turns that emergent, unsanctioned use into an explicit, consented, legitimate claim — or an informed refusal.

Fragmented Rights Clearance Design

Unlock under-used resources by mapping fragmented exclusion rights and replacing costly one-by-one permission assembly with legitimate clearance, pooling, default, brokerage, or bundling paths.

9 mechanisms · View full solution archetype

Harmful Arbitrage Closure

Close mismatches that invite harmful exploitation by aligning rules, prices, access, or accountability across contexts.

10 mechanisms · View full solution archetype

  • Anti-Abuse Rulebook — Catalogs the evasion patterns — sham transfer, category manipulation, harm displacement — that trigger review and remedy, so form-compliant arrangements that defeat a rule's purpose are still caught.
  • Coordinated Enforcement MOU — Binds separate authorities to share evidence and apply aligned remedies against actors who exploit the seam between their jurisdictions.
  • Cross-Boundary Reporting Dashboard — Renders comparable activity, anomalies, and complaint signals side by side across contexts so the migration of harm becomes visible in one view.
  • Emissions Leakage Control — Measures the embodied environmental burden crossing a boundary and neutralizes the cost differential, so a local gain can't be manufactured by exporting the harm.
  • Loophole Closure Amendment — Surgically rewrites the operative rule text to delete one identified evasion route, with an effective date and grandfathering for compliant actors.
  • Platform Policy Harmonization — Aligns a platform's rules across its regions, categories, and seller tiers so users can't escape a safeguard by relabeling the same activity.
  • Procurement Conformance Check — A transaction-level checklist that catches attempts to bypass procurement rules by splitting, relabeling, or subcontracting a purchase — and passes documented legitimate exceptions.
  • Regulatory Alignment Protocol — Reconciles definitions, classifications, and triggers across rule regimes so the same behavior is treated the same wherever it lands.
  • Tax Harmonization Agreement — Aligns a minimum tax standard and comparable reporting across jurisdictions so shifting income or presence across a border stops being the cheapest way to lower the bill.
  • Transfer Pricing Review — A forensic test of related-party prices against an arm's-length benchmark, pinpointing where internal prices move value out of the accountable context.

Impedance Matching and Coupling Optimization

Match source, interface, and receiver properties so useful transfer increases without creating reflection, instability, overload, fragility, or hidden loss.

6 mechanisms · View full solution archetype

LIFO Stack Discipline

Use a last-in, first-out nesting discipline whenever safe work depends on closing the current context before returning to the one beneath it.

8 mechanisms · View full solution archetype

  • Breadcrumb Navigation Stack — Pushes each nested context a user enters onto a visible trail, so the current screen is always the top and Back closes one level at a time, returning to the context beneath exactly where it was left.
  • Call Stack and Activation Records — Gives every active procedure call its own activation record on a runtime stack, so nested calls always resume the exact caller that invoked them with its local state intact.
  • Depth Limit and Stack Trace — Caps how deep nesting may go and, when a limit is hit or a failure occurs, prints the whole chain of open frames from the current point down to the root so hidden depth becomes visible before or right after it breaks.
  • Parser Delimiter Stack — Pushes each opening delimiter as it is read and requires the next closer to match the delimiter kind on top, so nested brackets, tags, and quotes can only close in the order they opened.
  • Push/Pop Interface — Defines the stack as a minimal abstract data type — push, pop, peek, and top — whose contract enforces last-in/first-out access no matter what the frames actually hold.
  • Resource Acquisition/Release Stack — Records each acquired resource as it is taken and guarantees release in strict reverse order — even when work fails partway — so no dependent resource is ever freed before the thing that relied on it.
  • Transaction Savepoint Stack — Marks named savepoints inside a running transaction so a nested step can be rolled back to a chosen marker — discarding only the tentative changes above it — without abandoning the work beneath.
  • Undo/Redo Stack Pair — Keeps two stacks — one of completed actions, one of undone ones — so each undo pops the most recent action and reverses it onto the redo stack, and each redo replays it, stepping through edit history one action at a time.

Representation-Independent Interface Contract

Specify what a component does at its public surface, hide how it does it, and test that any replacement implementation honors the same contract.

13 mechanisms · View full solution archetype

  • Abstract Data Type Specification — Specifies a type by its abstract values and operations, then pins any concrete storage to that meaning with a representation invariant and an abstraction function — so the storage can change without a client noticing.
  • Abstraction-Barrier Code Review — A code review read through a single lens — is anything here reaching past a component's public surface into its internals? — that sends reach-throughs back before the coupling hardens.
  • Black-Box Contract Test Suite — One reusable battery of tests written only against the public contract — no test may peek at internals — so that any implementation which passes it is accepted as a valid substitute.
  • Design-by-Contract Clause — Attaches to each operation a precondition, a postcondition, and the policy for a broken precondition — so that when a call goes wrong, the clause names, per call, whether the caller or the component is at fault.
  • Interface Definition Language — A machine-readable schema of a component's operations and their parameter and result types, from which client and server stubs are generated — so both sides compile against the published surface, never against each other's internals.
  • Metamorphic Behavior Test — Checks behavior through relations between related runs — if this input maps to that one, the outputs must relate this way — so a contract can be verified even when no one can state the single correct output.
  • Mock, Fake, or Stub Implementation — A lightweight stand-in that honors a component's interface but not its real behavior — an in-memory fake, a canned-response stub, or an expectation-checking mock — so clients can be built and tested without the real component.
  • Opaque Type / Module Boundary — Makes a component's representation physically unreachable to clients, so the only thing they can couple to is its declared operations.
  • Property-Based Conformance Test — Checks a contract by generating many random inputs and asserting the laws that must hold for every one, instead of a handful of hand-picked cases.
  • Reference-Implementation Differential Test — Runs the candidate and a trusted reference implementation on the same inputs and flags any observable divergence — the reference is the oracle.
  • Representation Leakage Probe — Hunts for behaviour clients can observe but the contract never promised — the accidental internals that quietly become an unofficial interface.
  • Semantic Versioning & Deprecation Gate — Governs how the contract may change over time, encoding compatibility in the version number and giving clients a deprecation window before anything breaks.
  • Substitutability Trial / Canary — Proves a replacement in production by routing a slice of real traffic to it and promoting only if it behaves indistinguishably from the incumbent.

Restraint–Orientation Degree Decoupling

Separate the primary restraint load path from independently governed orientation degrees so alignment does not require moving or torquing the load-bearing reference.

0 mechanisms · View full solution archetype

No mechanism currently instantiates this archetype as its primary archetype.

Specification-to-Execution Lowering

Lower a what-level specification into an executable how through explicit refinement stages, carrying forward the contract, assumptions, invariants, evidence obligations, and trace needed to justify that the result actually realizes the intent.

15 mechanisms · View full solution archetype

  • Compiler Intermediate-Representation Lowering Pipeline — Lowers a source program to machine code through a ladder of intermediate representations, one semantics-preserving pass at a time, so the whole translation is a sequence of individually-justifiable rewrites rather than one opaque jump.
  • Differential Equivalence Test — Feeds the same inputs through two implementations and flags any divergence, establishing that a new or lowered version behaves like a trusted reference — without needing a full specification of the correct output.
  • Executable-Specification Interpreter — Runs the specification itself as the implementation — an engine that directly executes the what-level spec, so there is no separately generated code to drift out of sync with intent.
  • Hardware or Controller Synthesis — Lowers a behavioural description into a physical or controller realization — gates, an FPGA image, or PLC logic — under hard timing, area, and power constraints set by the target technology.
  • Infrastructure-as-Code Generation — Lowers a declared desired end-state of infrastructure into concrete provisioning actions, reconciling what exists toward what was declared, with typed module interfaces and a rollback path when an apply fails.
  • Model Checker and Static Analyzer — Verifies that a model or program satisfies stated properties and pre/post-conditions by analysing its reachable states, returning a counterexample when it doesn't — proof over a bounded domain, not evidence from sample runs.
  • Model-Driven Code Generation — Generates implementation code from a higher-level model via templates, keeping the model the single source of truth: code is regenerated when the model changes, never hand-edited, with each generated line traceable to its model element.
  • Policy-to-Rule-Engine Compilation — Compiles written policy — regulation, eligibility rules, business decisions — into an executable rule set, forcing conflicts, precedence, and coverage gaps to be resolved as it goes.
  • Proof-Carrying Transformation — Emits, alongside each lowering step, a machine-checkable proof that the step preserves the source's meaning — so the result is trusted by re-checking the proof, not by trusting the translator.
  • Query-Plan Lowering and Optimization — Lowers a declarative query into a physical execution plan, letting a cost model choose freely among result-equivalent plans — not just a correct plan, the cheap one.
  • Refinement-Calculus Derivation — Derives a program from its specification by a chain of small, individually correctness-preserving refinement steps, each licensed by a law of the calculus — so the code is correct by construction.
  • Regression Test Suite — Re-runs a corpus of previously-passing cases against each new version so that any unintended loss of working behaviour breaks the build, using the system's own recorded past output as the reference.
  • Schema and Configuration Generator — Generates the static declarations a system stands on — database schemas, validation schemas, config files — from a single higher-level model, so they can never drift out of sync with it.
  • Translation-Validation Harness — Instead of proving a translator correct once, it checks each individual translation after the fact — establishing that this output faithfully realizes this input against the source as oracle.
  • Workflow-Model Compiler — Compiles a process model — a diagram of tasks, decisions, and flows — into an executable orchestration, wiring in the failure handling, compensation, and versioning a long-running process needs but the diagram omits.