Cross-Domain Example Ordering Prompt for Transfer Learning

This prompt is for teams that have a well-defined task pattern working reliably in one domain (the source) but need to deploy it in a new domain (the target) where they have fewer than 10 high-quality examples. The core job-to-be-done is transfer learning through example ordering: you place source-domain examples first to establish the task structure, then transition to target-domain examples to adapt the model to new terminology, constraints, or output formats. This approach exploits the model's ability to recognize abstract patterns from familiar examples before applying them to unfamiliar content. Ideal users are prompt engineers, ML engineers, and product teams who have validated a prompt in one vertical and need to expand to adjacent use cases without the time or budget for fine-tuning or large-scale target-domain data collection.

The prompt works by constructing a demonstration sequence where the first 60-80% of examples come from the source domain and the remainder from the target domain. Source examples should be the highest-quality, most representative instances that clearly illustrate the input-output relationship, edge cases, and refusal boundaries. Target examples should be placed last to exploit recency effects while the model still has the source pattern in its attention window. You must include at least 2-3 target examples to trigger adaptation; a single target example often fails to shift behavior. The prompt template includes placeholders for [SOURCE_EXAMPLES], [TARGET_EXAMPLES], [TASK_DESCRIPTION], and [OUTPUT_SCHEMA], along with a [DOMAIN_SHIFT_NOTE] that explicitly tells the model the domains differ. This explicit shift marker prevents the model from treating target examples as source-domain outliers and improves adaptation accuracy by 15-30% in internal testing compared to unmarked transitions.

Do not use this prompt when the source and target domains share no structural similarity—for example, adapting a legal contract extraction pattern to medical image captioning. The task structure itself must transfer; only the terminology, entities, and surface constraints should differ. Do not use this as a substitute for fine-tuning when you have hundreds of target examples; at that scale, supervised fine-tuning will outperform few-shot transfer learning. Do not use this for safety-critical classification or generation where domain-specific refusal boundaries differ significantly between source and target; instead, invest in target-domain negative examples and human review. Before deploying, always run a baseline comparison measuring target-domain accuracy with source-only examples, target-only examples, and the cross-domain ordered set. If target-only performance exceeds cross-domain performance, your domains are too different for transfer learning, and you should collect more target examples or consider fine-tuning.

This template is designed for teams adapting a prompt from a well-documented source domain to a target domain where only a handful of examples exist. The core strategy is to establish the task pattern using abundant source-domain examples first, then transition to the scarce target-domain examples. This ordering exploits the model's ability to recognize structural analogies before asking it to apply the pattern to unfamiliar terminology and constraints. The template is copy-ready but expects you to supply your own examples, output schema, and domain-specific constraints.

textCopy
You are an AI assistant that performs [TASK_DESCRIPTION].

Your output must conform to the following schema:
[OUTPUT_SCHEMA]

You must follow these constraints:
[CONSTRAINTS]

---

First, study these examples from the [SOURCE_DOMAIN] domain. They establish the pattern you must follow.

Source Example 1:
Input: [SOURCE_INPUT_1]
Output: [SOURCE_OUTPUT_1]

Source Example 2:
Input: [SOURCE_INPUT_2]
Output: [SOURCE_OUTPUT_2]

Source Example 3:
Input: [SOURCE_INPUT_3]
Output: [SOURCE_OUTPUT_3]

---

Now, apply the same pattern to the [TARGET_DOMAIN] domain. These examples show how the pattern adapts to target-domain terminology and constraints.

Target Example 1:
Input: [TARGET_INPUT_1]
Output: [TARGET_OUTPUT_1]

Target Example 2:
Input: [TARGET_INPUT_2]
Output: [TARGET_OUTPUT_2]

---

Now process the following input from the [TARGET_DOMAIN] domain:
Input: [USER_INPUT]
Output:

To adapt this template, replace every square-bracket placeholder with your concrete content. The [TASK_DESCRIPTION] should be a single sentence. The [OUTPUT_SCHEMA] can be a JSON schema, a typed field list, or a structured text format description. The [CONSTRAINTS] block should include domain-specific rules, refusal conditions, and any format requirements not captured by the schema. The source examples must be high-quality and unambiguous; they teach the pattern. The target examples must show how that pattern translates into the target domain's vocabulary and edge cases. If you lack sufficient target examples, reduce the number of source examples to avoid diluting the target signal. Do not interleave source and target examples unless you are specifically testing interleaved ordering against this block-transfer design. For high-risk domains, add a [RISK_LEVEL] field and include a human-review instruction in the constraints block.

This prompt is designed to be called programmatically as part of a transfer-learning evaluation pipeline, not as a one-off chat interaction. The application layer is responsible for assembling the ordered example sequence, calling the model, validating the output against the target schema, and comparing results against source-only and target-only baselines. The prompt template itself expects a pre-ordered list of examples—the harness controls the ordering logic, not the prompt. You should treat the prompt as a fixed template and vary the [ORDERED_EXAMPLES] block through application code to test different sequencing strategies.

The implementation loop follows a clear sequence. First, maintain three example pools in your application: a source-domain pool (plentiful, labeled), a target-domain pool (limited, labeled), and a holdout test set (target domain only, used for scoring). For each ordering variant, assemble the [ORDERED_EXAMPLES] block by concatenating source examples first, then target examples, with a domain-transition marker between them. Call the model with the assembled prompt and parse the output. Run the output through a schema validator that checks for required fields, type conformance, and enum membership. If validation fails, retry once with the same prompt and a repair instruction appended; if it fails again, log the failure and fall back to the target-only baseline output. Log every call with the ordering variant, model response, validation result, and target-domain accuracy score for later analysis.

Domain-shift detection is a critical part of the harness. After each model call, compute a pattern-transfer score by comparing the model's output on target-domain holdout examples against two baselines: a source-only baseline (trained only on source examples) and a target-only baseline (trained only on the limited target examples). If the cross-domain ordering underperforms the target-only baseline, the domain gap is too wide for transfer learning, and you should either collect more target examples or switch to a target-only strategy. If it outperforms the source-only baseline but not the target-only baseline, partial transfer is occurring—log this as a marginal case and consider adjusting the source-to-target example ratio. Only promote the cross-domain ordering to production when it matches or exceeds target-only performance while using fewer target examples. Store all scores in a structured log with timestamps, model version, and example-set hashes so you can detect drift when source or target distributions change over time.

For production deployment, wrap the prompt call in a thin service that exposes a single endpoint: accept a task input, select the appropriate example ordering from a configuration store, assemble the prompt, call the model, validate the output, and return the result along with a confidence flag. Use a feature flag to toggle between cross-domain, source-only, and target-only strategies without redeploying. Monitor the pattern-transfer score on a dashboard and set an alert if it drops below the target-only baseline for three consecutive evaluation windows. This harness turns the prompt from a static template into a measurable, observable component that you can tune and retire when the target domain has enough examples to stand alone.