This prompt is designed for vertical AI product teams building domain-specific retrieval-augmented generation (RAG) systems in fields where generic relevance scoring fails—specifically legal, medical, scientific, and financial contexts. The core job-to-be-done is adapting evidence weighting logic to recognize domain-specific authority signals, specialized terminology, and evidence standards that a general-purpose ranker would miss. If your retrieval pipeline returns passages that must be scored for relevance, authority, and specificity according to professional or regulatory rules before downstream synthesis, this template gives you a calibrated starting point. The ideal user is an engineering lead or AI architect who already has a working retrieval pipeline and needs to inject domain judgment into the scoring layer without rebuilding the entire ranking stack.
Prompt
Domain-Adapted Evidence Weighting Prompt Template

When to Use This Prompt
Determine whether domain-adapted evidence weighting is the right tool for your RAG pipeline before investing in calibration.
You should reach for this prompt when your evidence quality depends on factors that a standard semantic similarity score cannot capture: precedent hierarchy in legal documents, study design quality in medical literature, regulatory filing status in financial reports, or peer-review provenance in scientific papers. The template expects you to supply domain-specific scoring dimensions, authority signal definitions, terminology glossaries, and evidence standards as square-bracket placeholders. It then produces a weighted scoring instruction set that the model can apply consistently across retrieval batches. Concrete signals you might inject include court level and citation count for legal, journal impact factor and sample size for medical, filing date and auditor identity for financial, or replication status and conflict-of-interest disclosures for scientific evidence. The output includes per-passage score breakdowns with explicit justifications, making downstream selection and audit feasible.
Do not use this prompt for general-purpose search ranking, consumer Q&A, or domains where standard relevance scoring is sufficient and the overhead of domain calibration produces diminishing returns. It is also the wrong tool when your retrieval set is small enough for manual review, when you lack domain experts to define the authority signals and evidence standards the template requires, or when latency constraints prevent per-passage scoring with detailed justifications. If you are building a prototype and haven't yet validated that generic ranking is inadequate, start with a simpler relevance scoring prompt and only introduce domain adaptation when you have concrete failure examples. For high-stakes domains, always pair this prompt with human review of the scoring calibration before production deployment, and run eval checks comparing model-assigned weights against domain expert judgments to detect systematic miscalibration.
Use Case Fit
Where domain-adapted evidence weighting works, where it breaks, and what you must have in place before using this prompt in a production RAG pipeline.
Strong Fit: Vertical RAG with Domain Experts
Use when: you have a domain-specific knowledge base (legal, medical, financial) and domain experts who can define authority signals, terminology mappings, and evidence standards. Guardrail: domain experts must review and calibrate the weighting rubric before production use; generic weighting fails on domain-specific authority cues.
Poor Fit: General-Purpose Search
Avoid when: building a general web search or broad Q&A system without domain constraints. Domain-adapted weighting overfits to specific terminology and authority signals, producing worse results than generic relevance ranking on diverse queries. Guardrail: use general evidence weighting templates instead; reserve domain adaptation for vertical applications.
Required Input: Domain Signal Definitions
Risk: without explicit definitions of domain authority signals, recency thresholds, and terminology mappings, the model applies inconsistent or hallucinated weighting criteria. Guardrail: provide a structured domain config with authority source lists, staleness thresholds, and term importance mappings as part of the prompt context.
Operational Risk: Cross-Domain Contamination
Risk: domain-adapted weighting logic bleeds into queries outside the target domain, applying medical authority standards to legal documents or financial recency thresholds to scientific literature. Guardrail: implement domain detection or routing before evidence weighting; never apply a single domain adapter to mixed-domain retrieval sets.
Calibration Risk: Unexamined Domain Bias
Risk: domain experts embed unexamined preferences into weighting rubrics, systematically deprioritizing valid but unfamiliar source types or methodologies. Guardrail: run calibration tests comparing model-weighted rankings against multiple domain experts; watch for systematic exclusion of minority viewpoints or emerging research.
Eval Requirement: Domain-Specific Ground Truth
Risk: generic evidence ranking benchmarks do not measure domain-adapted weighting quality, leading to false confidence in production performance. Guardrail: build a domain-specific eval set with expert-annotated evidence rankings; measure ranking correlation and worst-case ranking failures, not just average precision.
Copy-Ready Prompt Template
A reusable prompt for domain-adapted evidence weighting that you can copy, customize, and integrate into your RAG pipeline.
This prompt template is the core instruction set for a domain-adapted evidence weighting system. It is designed to be dropped into your application code, with square-bracket placeholders that you replace at runtime. The template forces the model to act as a calibrated evidence analyst within a specific professional domain, applying that domain's unique standards for authority, recency, and specificity. Before using it, ensure you have defined your domain's evidence standards and have a clear schema for the output you expect.
textYou are an expert evidence analyst operating within the [DOMAIN] domain. Your task is to evaluate a set of retrieved evidence passages against a user query and assign a weighted score to each passage based on domain-specific criteria. ## Domain Context and Standards - Domain: [DOMAIN] - Key Terminology: [DOMAIN_TERMINOLOGY] - Authority Signals: [DOMAIN_AUTHORITY_SIGNALS] - Recency Requirements: [DOMAIN_RECENCY_RULES] - Evidence Standards: [DOMAIN_EVIDENCE_STANDARDS] ## Input Data - User Query: [USER_QUERY] - Evidence Passages: [EVIDENCE_PASSAGES] ## Weighting Criteria For each passage, assign a score from 0.0 to 1.0 for each of the following criteria, then calculate a final weighted score. Provide a brief justification for each sub-score. 1. **Relevance (weight: [RELEVANCE_WEIGHT]):** How directly does the passage address the user query, considering domain-specific intent and terminology? 2. **Recency (weight: [RECENCY_WEIGHT]):** Is the passage current enough based on the domain's recency requirements? Apply a decay function if the passage date is older than the threshold. 3. **Authority (weight: [AUTHORITY_WEIGHT]):** Does the source meet the domain's authority signals? Penalize sources that lack these signals. 4. **Specificity (weight: [SPECIFICITY_WEIGHT]):** Does the passage provide concrete, detailed evidence, or is it vague and general? Prioritize passages with high detail density and precise claims. ## Constraints - [CONSTRAINTS] ## Output Schema Return your analysis as a single JSON object matching this exact schema: [OUTPUT_SCHEMA] ## Examples [EXAMPLES]
To adapt this template, start by replacing the [DOMAIN] and related placeholders with concrete values. For a legal domain, [DOMAIN_AUTHORITY_SIGNALS] might be 'official court reporters, recognized law reviews, statutes' while [DOMAIN_RECENCY_RULES] could be 'prefer cases from the last 10 years; treat anything older as persuasive but potentially outdated.' The [CONSTRAINTS] placeholder is critical for safety; in a medical domain, you might add: 'If no passage provides direct clinical trial evidence, the final score for all passages must be capped at 0.4, and a flag must be set.' The [OUTPUT_SCHEMA] should be a strict JSON schema definition, and [EXAMPLES] should include one or two few-shot examples of a passage, its sub-scores, and the final weighted score to calibrate the model's behavior. After integrating this prompt, you must run it against your evaluation dataset to calibrate the weights and ensure the model's scoring aligns with human expert judgments.
Prompt Variables
Required inputs for the Domain-Adapted Evidence Weighting Prompt. Each placeholder must be populated before the prompt is sent. Validation notes describe how to check that the input is well-formed and safe before execution.
| Placeholder | Purpose | Example | Validation Notes |
|---|---|---|---|
[QUERY] | The user question or information need that evidence is being weighted against. | What are the side effects of JAK2 inhibitors in elderly patients with renal impairment? | Check that the query is a non-empty string. For domain-specific workflows, verify that the query contains at least one domain term from the configured terminology list. Reject queries that are purely conversational or off-topic. |
[EVIDENCE_PASSAGES] | An array of retrieved passages to be weighted. Each passage should include text content and available metadata. | [{"id": "doc_1", "text": "...", "source": "PubMed", "date": "2024-03-15", "authority": "peer-reviewed"}] | Validate that the array is non-empty and each passage object contains a non-empty text field. Check that metadata fields used by the domain weighting rules such as source, date, and authority are present. If a required metadata field is missing, flag the passage for pre-processing or exclusion before scoring. |
[DOMAIN_CONFIG] | A configuration object defining domain-specific weighting rules, terminology, authority signals, and evidence standards. | {"domain": "clinical_medicine", "authority_tiers": {"peer-reviewed": 1.0, "guideline": 0.9, "expert_opinion": 0.6}, "recency_threshold_days": 730, "required_metadata": ["source", "date"]} | Validate that the domain_config object contains a non-empty domain identifier and at least one weighting rule. Check that authority_tiers values are numeric and between 0 and 1. Verify that recency_threshold_days is a positive integer. Reject configurations that reference undefined domain identifiers or missing rule parameters. |
[OUTPUT_SCHEMA] | The expected JSON schema for the weighted evidence output, including score fields, justification requirements, and confidence indicators. | {"type": "object", "properties": {"passage_id": {"type": "string"}, "weighted_score": {"type": "number"}, "factor_breakdown": {"type": "object"}, "justification": {"type": "string"}}, "required": ["passage_id", "weighted_score", "factor_breakdown"]} | Validate that the schema is valid JSON Schema syntax. Check that required fields include passage_id, weighted_score, and at least one factor breakdown or justification field. Ensure numeric fields have defined minimum and maximum constraints. Reject schemas that allow unbounded score ranges. |
[CONSTRAINTS] | Operational constraints for the weighting task, including score ranges, factor weight limits, and output formatting rules. | {"score_range": [0, 1], "max_factors": 5, "require_justification": true, "confidence_interval": true, "max_passages": 20} | Check that score_range is a two-element array with min less than max. Verify that max_factors is a positive integer not exceeding 10. If require_justification is true, confirm that the output schema includes a justification field. Validate that max_passages does not exceed the model context window capacity for the expected passage length. |
[CALIBRATION_REFERENCES] | Optional array of human-annotated reference examples for calibrating the model's weighting behavior against domain expert judgments. | [{"passage_id": "doc_1", "human_score": 0.85, "human_factors": {"relevance": 0.9, "authority": 0.8, "recency": 0.7}}] | If provided, validate that each reference contains a passage_id matching an entry in evidence_passages, a numeric human_score in the configured score_range, and a human_factors object with keys matching the domain_config factor names. Flag references with scores outside the configured range. This field is optional; set to null when calibration data is unavailable. |
[DOMAIN_TERMINOLOGY] | A list of domain-specific terms, synonyms, and entity patterns that the weighting model should recognize when assessing relevance and specificity. | ["JAK2 inhibitor", "myelofibrosis", "ruxolitinib", "fedratinib", "renal impairment", "eGFR", "CKD stage"] | Validate that the list is non-empty and each term is a non-empty string. Check for duplicate terms. For clinical domains, verify that terms do not include PHI or patient identifiers. For legal domains, verify that terms do not include privileged case references. Flag terms that appear to be generic stop words rather than domain-significant vocabulary. |
[EXCLUSION_RULES] | Rules for excluding passages from scoring based on domain-inappropriate content, outdated information, or prohibited source types. | {"exclude_sources": ["social_media", "unverified_preprint"], "exclude_before_date": "2010-01-01", "exclude_if_missing": ["source", "date"], "exclude_content_patterns": ["case report with n=1"]} | Validate that exclude_sources contains only strings matching known source type categories. Check that exclude_before_date is a valid ISO date string. Verify that exclude_if_missing fields exist in the evidence passage metadata schema. Test exclusion rules against a sample passage to confirm they execute without errors before running the full batch. |
Common Failure Modes
Domain-adapted evidence weighting fails in predictable ways when generic logic meets specialized evidence standards. These are the most common production failure modes and how to guard against them.
Domain Authority Blindness
What to watch: The prompt treats all sources as equally authoritative, assigning high weight to popular but non-authoritative sources in regulated domains. A blog post and a regulatory filing receive similar scores because the model lacks domain-specific authority signals. Guardrail: Include a domain authority tier list in the prompt context. Require explicit authority justification per source type. Flag passages from unvetted sources for human review before weighting.
Terminology Mismatch Scoring
What to watch: The prompt uses general-language similarity to score relevance, missing domain-specific terminology where different words mean the same thing or the same word means different things across contexts. A medical passage about 'staging' is scored low for a cancer query because the model misses the domain meaning. Guardrail: Provide a domain terminology map in the prompt. Require the model to identify and resolve domain-specific synonyms, acronyms, and homonyms before scoring. Test with terminology edge cases.
Recency Override in Stable Domains
What to watch: The prompt applies aggressive recency decay to all evidence, deprioritizing foundational but older sources in domains where knowledge changes slowly. A landmark legal precedent or scientific principle gets scored below a recent but shallow summary. Guardrail: Configure domain-specific recency half-life parameters. Distinguish between time-sensitive queries and stable-knowledge queries. Require the model to justify any recency-based downgrade with a domain-relevance explanation.
Specificity Confusion with Irrelevant Detail
What to watch: The prompt rewards passages with high detail density, conflating specificity with relevance. A passage rich in domain jargon and numbers scores high even when it addresses a different question entirely. Guardrail: Separate specificity scoring from relevance scoring. Require the model to first confirm topical alignment, then assess detail quality. Add a contradiction check: if a passage is highly specific but topically misaligned, flag it for exclusion.
Evidence Standard Mismatch
What to watch: The prompt applies general evidence standards to a domain with stricter requirements. A financial compliance query accepts suggestive evidence when only primary-source documentation is acceptable. The model doesn't know that 'likely' isn't sufficient for audit purposes. Guardrail: Define the domain's evidence standard explicitly in the prompt. Include examples of acceptable vs. unacceptable evidence types. Require the model to classify each passage against the standard before assigning weight.
Cross-Domain Weight Leakage
What to watch: When evidence spans multiple domains, the prompt applies the wrong domain's weighting logic. A legal-medical crossover query weights medical literature using legal authority rules, or vice versa. Guardrail: Require domain classification per passage before weighting. Use separate weighting profiles per domain. Add a consistency check: if a passage could belong to multiple domains, flag it and apply the most conservative weighting profile.
Evaluation Rubric
Use this rubric to test whether the domain-adapted evidence weighting prompt produces calibrated, auditable, and domain-safe scores before shipping to production.
| Criterion | Pass Standard | Failure Signal | Test Method |
|---|---|---|---|
Domain authority signal detection | Prompt correctly identifies and weights domain-specific authority markers (e.g., court level for legal, journal tier for medical, regulatory body for finance) in at least 90% of test cases | Generic authority signals (e.g., domain age, backlinks) dominate domain-specific signals; peer-reviewed journal weighted same as blog | Run 20 domain-specific passage pairs with known authority differentials; measure whether domain-appropriate source ranks higher |
Terminology-aware relevance scoring | Prompt recognizes domain synonyms, acronyms, and technical terms as equivalent to query intent; penalizes passages using correct terms in wrong context | Surface-level keyword match dominates; passage with correct domain term used incorrectly scores higher than passage with synonym used correctly | Curate 15 query-passage pairs with controlled terminology traps; measure precision of relevance ranking against domain-expert labels |
Evidence standard compliance | Prompt applies domain-appropriate evidence standards (e.g., peer-review requirement for medical claims, primary source preference for legal) in scoring decisions | Anecdotal or low-quality evidence scores above domain-standard evidence; preprint weighted equal to published RCT | Construct 10 evidence pairs where one meets domain standard and one does not; verify standard-compliant passage receives higher score |
Cross-domain failure prevention | Prompt refuses or flags low confidence when domain-adapted criteria are applied to queries outside the configured domain | Prompt confidently applies medical evidence standards to a legal query or vice versa without flagging domain mismatch | Submit 10 out-of-domain queries; check for explicit domain-mismatch flag or low-confidence signal in output |
Score justification auditability | Every weighted score includes a traceable justification referencing specific passage content and the domain criterion applied | Scores appear without justification; justifications are generic (e.g., 'relevant') without citing passage content or domain rule | Parse output for justification field per score; verify each justification references a specific passage span and names the domain criterion used |
Recency weighting calibration | Prompt applies domain-appropriate recency decay (e.g., rapid decay for drug interaction evidence, slow decay for constitutional law) when [RECENCY_WEIGHT] is configured | All domains receive identical recency treatment; 10-year-old legal precedent penalized same as 10-year-old medical trial | Run 5 time-sensitive queries per supported domain with known stale vs. fresh evidence pairs; verify domain-appropriate decay |
Confidence calibration | Prompt outputs confidence levels that correlate with evidence ambiguity; low confidence when sources conflict or evidence is thin | High confidence assigned to scores derived from single weak source or conflicting evidence set | Measure confidence scores against human-rated ambiguity across 30 passages; expect confidence-ambiguity correlation above 0.7 |
Output schema compliance | Output matches [OUTPUT_SCHEMA] exactly: all required fields present, types correct, no extra fields | Missing required fields; score field contains string instead of number; justification field absent or null when required | Validate output against [OUTPUT_SCHEMA] using JSON Schema validator; run across 50 varied inputs and require 100% structural compliance |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Adapt This Prompt
How to adapt\nAdd jurisdiction-awareness to the authority signal. Replace generic authority scoring with signals like court hierarchy, citation count, and whether the source is primary law (statute, regulation, case) versus secondary (treatise, blog). Add a `[JURISDICTION]` placeholder and require the model to flag when cited authority is from a different jurisdiction.\n\nModify the prompt to include:\n```\nAuthority signals for legal domain:\n- Primary vs. secondary source\n- Binding vs. persuasive authority in [JURISDICTION]\n- Court level and circuit\n- Shepard's treatment or subsequent history\n- Date of decision relative to statutory changes\n```\n\n### Watch for\n- Model treating persuasive authority as binding\n- Missing jurisdiction mismatch flags\n- Over-weighting recency at the expense of landmark precedent\n- Hallucinated case citations that look plausible\n- Require human attorney review before any downstream use

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us