A pattern transfer preserves an established source pattern's problem structure rather than its implementation syntax. Admission requires all seven elements below to be explicit, observable, and coherent for one declared Skillware Unit and revision.
Source intent
Design forces
Participant correspondence
Consequences
Implementation evidence
Focused verification
Misuse discriminator
| Element | Required record |
|---|---|
| Source intent | State the canonical problem and purpose from the prior pattern tradition. |
| Design forces | Identify the competing pressures that make the structure necessary. |
| Participant correspondence | Map every required source participant and collaboration to concrete Skillware artifacts or runtime relations. |
| Consequences | Preserve relevant benefits, liabilities, and trade-offs rather than reporting only a structural resemblance. |
| Implementation evidence | Cite exact repository paths, a frozen revision where applicable, and the artifacts that realize the participant relation. |
| Focused verification | Exercise the mapping-specific collaboration, contract, ordering, state, or substitution property through reproducible tests. |
| Misuse discriminator | Provide a structurally close case that fails the source contract and explain the decisive difference. |
Pattern names alone do not establish a transfer. File names, directory labels, comments, and architectural vocabulary are navigational evidence until the required participant relations and consequences are demonstrated. For example, an object named adapter does not establish Adapter unless it translates between the canonical and target contracts.
Admission is relation-specific. A constructive sample can establish buildability while an ecosystem correspondence remains unverified. Missing evidence is reported through the controlled claim-status vocabulary; it is not repaired by analogy or by renaming participants.