Skip to content

Boundary Condition Checklist

Applicability checklist — instantiates Transfer Scaffolding

Enumerates the conditions under which the source knowledge applies as-is, must be adapted, or must be dropped — a standing gate that stops a good practice from being carried where it no longer holds.

"It worked before" is not a reason; it is a claim with hidden conditions. Boundary Condition Checklist makes those conditions explicit and turns them into a gate. It is a checklist of the specific circumstances under which the source knowledge applies as-is, needs modification, or should be rejected outright — run before the knowledge is used in the target. Its defining move is that it is the guardrail against false universality: it neither maps nor teaches, it conditions — converting "this practice works" into "this practice works when X, Y, and Z hold," and refusing the transfer when they don't.

Example

A growth lead who ran paid acquisition at a consumer app joins a B2B security startup and reaches for the old playbook: heavy paid social, a viral referral loop, optimize relentlessly for signups. Before a dollar is spent, the checklist forces the conditions the playbook silently assumed:

  • Low-consideration, impulse purchase? — Fails. Enterprise security is high-consideration with a months-long sales cycle.
  • The end user is the buyer? — Fails. The buyer is a CISO; the user is not the buyer.
  • Value visible within one session? — Partial.
  • Fast feedback loop on acquisition cost? — Fails. Deals close over quarters, not clicks.

Readiness verdict: reject the paid-social-and-referral core; adapt only the funnel-instrumentation discipline. That red/yellow/green sheet stops the largest negative transfer before it happens, and it does so on stated conditions anyone can inspect rather than on the lead's gut.

How it works

Each condition is written as a testable statement about the target and tagged with a verdict:

  • Enumerate the preconditions the source practice depends on — often the very assumptions "best-practice" language hides.
  • Tag each as applies / adapt / reject against the target.
  • Roll up to a readiness verdict: go, go-with-adaptation, or no-go.
  • Keep an "unknown conditions" line open, because the conditions you cannot list are the dangerous ones.

Tuning parameters

  • Granularity — a few coarse gates or many fine conditions. Fine lists catch subtle mismatches but grow unwieldy and invite rubber-stamping.
  • Verdict scheme — binary go/no-go versus graded apply/adapt/reject. The graded form preserves partial transfers a binary gate would kill.
  • Evidence bar per condition — assert from judgment, or require target evidence before a condition may be marked satisfied.
  • Authority — advisory checklist versus hard gate with rejection power. A hard gate bites but can also block valid transfer.
  • Living vs one-shot — frozen at adoption, or updated as boundary knowledge accrues from experience.

When it helps, and when it misleads

Its strength is cheap insurance: it is the explicit antidote to portable-sounding "best practice" that travels with its conditions stripped off, and it stops the biggest mis-transfers for the price of a form.[1]

Its failure mode is that a checklist is only as good as the conditions on it — an unknown boundary condition cannot be checked, so a clean sheet can give false confidence, while an over-stuffed list can strangle valid transfer. The classic misuse is running it after the adoption decision is already made, to bless a choice rather than test it. The discipline is to derive conditions from real failures and adversarial review, keep the "unknown conditions" line honest, and revisit the list as target evidence lands.

How it implements the components

Boundary Condition Checklist fills only the guardrail-and-gate subset of the archetype:

  • boundary_condition_set — its content is this component: the enumerated conditions under which the source applies, adapts, or fails.
  • transfer_readiness_check — running the checklist produces the readiness verdict (go / adapt / no-go) that gates the transfer.

It does not discover those conditions from lived cases (that is Case Comparison and Contrast, which reads boundaries off contrasts) or actively hunt for live traps in the target (Negative Transfer Red Team's negative_transfer_check); it holds and gates on conditions those siblings help find.

Notes

Distinguish this standing gate from Negative Transfer Red Team: the red team discovers traps by adversarial attack, while the checklist holds and enforces the resulting conditions as a reusable gate. The two work best in sequence — attack to find, checklist to remember.

References

[1] Learning research describes expert knowledge as conditionalized — stored together with the conditions of its application, not as free-floating facts. A boundary-condition checklist is the deliberate, written version of that: it externalizes the conditions a novice would otherwise lack. ↩