Pattern Transfer

Purpose / When to Activate

Activate when:

• The Discovery Agent identifies a problem that may have been solved in another domain
• A structural similarity is noticed between a known pattern and a new problem context
• A validated pattern could apply to a different domain (cross-pollination opportunity)

This skill performs explicit cross-domain pattern transfer using structural alignment checking. It does NOT create new patterns (that is

post-mortem-learning

memory-ingest

Theoretical foundation: Gentner's Structure-Mapping Theory (1983) — analogical transfer succeeds when structural relationships (not surface features) are preserved across domains. Alexander's Pattern Language (1977) — patterns are reusable solutions with explicit applicability conditions and contraindications.

Status: This skill is dormant until 3+ patterns exist in different domains in the pattern catalog. With fewer patterns, the transfer search space is too small for meaningful cross-domain discovery.

Prerequisites

Before activating:

1. The pattern catalog (

   contexts/memory/patterns/

   ) must contain at least 2 patterns with

   structural_tags

   in their frontmatter.
2. The target problem must be describable in structural terms (not just surface-level symptoms).
3. The invoking agent must provide a

   target_domain

   that differs from the source pattern's domain.

If the pattern catalog has no tagged patterns, STOP and report: "Pattern catalog lacks structural tags — run pattern card retrofit before invoking pattern-transfer."

Process

Step 1 — Pattern Discovery

1. Use

   memory-search

   (Mode C: structural tag filtering) to find candidate patterns from domains OTHER than

   target_domain

   .
2. Match by structural characteristics:
   • If

     structural_tags

     input is provided: match patterns sharing at least 1 tag
   • If not provided: infer structural tags from the

     target_problem

     description using the controlled vocabulary in

     references/structural-tags.md

3. Rank candidates by tag overlap count (more shared tags = higher rank).
4. Budget: top 5 candidates maximum. If more than 5 match, take the top 5 by tag overlap.
5. If zero candidates match: STOP and report "No structurally similar patterns found."

Step 2 — Structural Alignment Check

For each candidate pattern:

1. Read the pattern card's

   structural_invariants

   list.
2. For each invariant, verify whether it holds in the target domain:
   • PASS: The invariant clearly applies in the target domain (explain why).
   • FAIL: The invariant does not hold or cannot be verified (explain why).
3. Check the pattern's

   contraindications

   list against the target domain context.
   • If any contraindication matches: mark the candidate as

     contraindicated

     .
4. Compute alignment score:

   invariants_passed / invariants_total

   .
5. Filter out candidates where:
   • Any structural invariant FAILS, OR
   • Any contraindication matches

Step 3 — Domain Distance Assessment

For each surviving candidate, rate the structural distance between source and target domains:

near

medium

far

Record the distance rating with a one-sentence justification.

Step 4 — Transfer Proposal

For each viable candidate (passed Step 2 alignment, assessed in Step 3), produce:

## Transfer Proposal: {source pattern name} → {target domain}

### Source Pattern
- **Name:** {pattern name}
- **Domain:** {source domain}
- **Abstraction level:** {domain-specific | domain-portable | domain-agnostic}
- **Confidence:** {N/5}

### Structural Alignment
- **Invariants checked:** {N}
- **Invariants passed:** {N} (all must be N/N to reach this step)
- **Contraindications checked:** {N} — none triggered

### Domain Distance
- **Rating:** {near | medium | far}
- **Justification:** {one sentence}

### Required Adaptations
{What changes when moving from source domain to target domain. Be specific: which roles, which data types, which constraints differ.}

### What Stays Invariant
{The structural relationships that transfer directly without modification.}

### Risk Assessment
- **Risk level:** {low | medium | high}
- **Key risk:** {the single most likely failure mode}
- **Mitigation:** {how to detect or prevent the key risk}

### Recommendation
{transfer | adapt-then-transfer | too-distant-reject}

Step 5 — Risk Gate

Apply risk gates based on the combined assessment:

The risk gate is non-negotiable. High-risk transfers without human approval are a governance violation.

Step 6 — Post-Transfer Validation (After Delivery)

This step executes AFTER the transferred pattern has been used in a delivery cycle. It is NOT part of the initial transfer proposal — it is invoked separately when delivery is complete.

1. Update the source pattern card's

   validated_in

   list:

   validated_in:
     - domain: {target_domain}
       date: {ISO 8601}
       result: success | failure
       decision_ref: {DEC-NNN if applicable}
   

2. Update

   confidence

   score: +1 if success, -1 if failure (floor at 0, ceiling at 5).
3. Add entry to the pattern card's

   transfer_log

   .
4. If the pattern is now validated in 3+ domains: promote

   abstraction_level

   to

   domain-portable

   .
5. If the transfer failed: document the failure context in the pattern card's anti-patterns section.

Quality Checks

• Every structural invariant produces an explicit PASS or FAIL with justification — no silent skips
• Transfer proposals include at least one contraindication check (even if none triggered)
• Risk gate is applied to every proposal — no proposals skip the gate
• Post-transfer validation is mandatory — no fire-and-forget transfers
• Pattern cards are append-only for

  transfer_log

  and

  validated_in

  — history is preserved
• Domain distance rating includes a justification — not just a label
• Recommendations are one of exactly three values:

  transfer

  ,

  adapt-then-transfer

  ,

  too-distant-reject

Outputs

sessions/transfer-proposal-{id}.md

contexts/memory/patterns/{pattern-name}.md

Non-Goals

This skill must NOT:

• Auto-apply patterns to the target domain (the agent + risk gate decide, then Delivery implements)
• Create new patterns (that is

  post-mortem-learning

  +

  memory-ingest

  )
• Modify source pattern cards during transfer proposal (only after post-delivery validation in Step 6)
• Skip structural invariant checking (primary safeguard against false analogies — see

  references/anti-patterns.md

  )
• Transfer patterns with

  confidence < 1/5

  (insufficient evidence for any transfer)
• Match patterns by surface similarity alone (keywords, domain names) — structural tags are the matching mechanism
• Override the risk gate under any circumstances

For the structural tag taxonomy, see

references/structural-tags.md

references/pattern-card-format.md

references/anti-patterns.md

No silent analogies. Every structural match, every invariant check, every risk assessment becomes explicit and governed.