---
name: evaluation-tor-draft
description: Draft an evaluation Terms of Reference from supplied program and evaluation materials. Use when a user needs a structured, evidence-linked TOR draft with gaps and feasibility issues made explicit.
---

# Evaluation Terms of Reference draft

## Purpose and trigger
Create a bounded TOR draft using the supplied program evidence and evaluation decisions. The result is a draft for commissioner and technical review, not an approved procurement document.

## Minimum inputs
- Program or intervention description and evaluation purpose.
- Intended users or decisions, if known.
- Evaluation scope, timing, or constraints, if known.

Accept explicitly uploaded files or a user-designated folder and file list. In upload mode, use only the attachments and text. In folder mode, inspect only the named folder and list files used. Confirm ambiguous files. State intake mode. Do not claim access to unavailable files.

## Starter prompt
> Use evaluation-tor-draft with the attached files [or folder: path]. Draft a source-linked evaluation TOR using the ten-section structure. Preserve unknowns as placeholders, distinguish facts from assumptions and proposals, and flag design or ethics decisions that require the commissioning team. Return editable Markdown.

## Procedure
1. Confirm the intake mode, intended deliverable, audience, and whether an existing TOR must be revised or a new one drafted.
2. Extract program, results framework, M&E plan, prior findings, donor requirements, decisions, timing, budget constraints, and governance only where supplied. Create evidence IDs as `filename#heading`, page, table, or row.
3. Record facts, assumptions, and recommendations separately. Preserve contradictions with both source IDs. Do not invent targets, budgets, results, owners, deadlines, donor obligations, or approval status.
4. Draft evaluation questions or use supplied questions. If missing, provide provisional questions only when enough purpose and scope exist; otherwise leave a clearly marked placeholder. Use criteria relevant to purpose, not every DAC criterion by default.
5. Check that each question can be answered by the proposed evidence. Specify methods only to the level supported by inputs. Do not imply causal attribution from a simple pre/post design.
6. Draft the ten sections below. Mark absent content “To be confirmed” and explain the decision needed. Do not turn absence from supplied files into a claim that the real program lacks the information.
7. Review internal consistency across scope, questions, methods, team expertise, timing, deliverables, resources, ethics, and governance.
8. Provide a short issue list ordered by consequence and identify what must be resolved before procurement or fieldwork.

## Required ten-section structure
1. Background and context
2. Evaluation purpose and intended use
3. Scope and boundaries
4. Evaluation questions and criteria
5. Methodology expectations and evidence needs
6. Team composition and expertise
7. Deliverables, timeline, and review process
8. Budget and logistics
9. Ethics, safeguarding, and data protection
10. Management, governance, and quality assurance

## Output structure
Return the ten-section TOR, followed by: source and evidence register; facts, assumptions, and proposals; unresolved decisions; consistency and feasibility issues; and a completion checklist. Use editable Markdown. Where a required fact is unknown, insert `[To be confirmed: specific item]` rather than guessing.

## Section drafting checks
- **Background:** Give a concise program summary, results logic, stage, and relevant context. Do not copy promotional claims as findings.
- **Purpose/use:** Name intended users and decisions. If the use is unclear, state this as a commissioning decision.
- **Scope:** Specify geography, population, themes, and period. State exclusions where known and do not imply comprehensive coverage from a bounded sample.
- **Questions:** Number a manageable set, connect them to purpose, and identify criteria only when relevant.
- **Methods:** Describe evidence needs and methodological expectations while leaving evaluator design room. Do not prescribe a method that cannot answer a question.
- **Team:** Connect expertise to scope and method. Do not invent years of experience, local roles, or level of effort.
- **Deliverables:** For each product, state purpose, format, timing, and review path only when supplied or proposed.
- **Budget/logistics:** Separate ceiling, inclusions, exclusions, travel, translation, and payment details. Unknown values remain placeholders.
- **Ethics:** Address voluntary participation, consent, do-no-harm, confidentiality, safeguarding, data protection, and applicable review route as relevant. Do not claim legal sufficiency.
- **Governance:** Identify commissioner, evaluator, and approval roles only where the source names them. Distinguish technical review from management approval.
- **Consistency:** Check question-to-method fit, scope-to-team fit, deliverable-to-timeline fit, and resource-to-ambition fit. Explain each unresolved mismatch.

Label the document as a draft. Keep source wording when it carries an approved requirement. For proposed edits, show the original requirement, proposed wording, reason, and decision owner if known. Do not erase unresolved questions in a polished rewrite.

## Feasibility and evidence rules
Select DAC criteria by evaluation purpose. Distinguish evaluator independence from commissioner oversight. Require appropriate consent, do-no-harm, safeguarding, privacy, data handling, and ethics review provisions where relevant to the context, without inventing the applicable legal authority. A timeline or budget is not realistic or unrealistic by a universal number alone; explain the basis and uncertainties. If there is no sample frame, design, or assumptions, do not give a sample size. Treat draft recommendations as proposals pending commissioner decision.

## Missing, conflicting, or unsuitable inputs
- Sparse context: produce a clearly bounded TOR shell with only supported sections drafted and prioritized questions for missing decisions.
- Conflicting dates, populations, or objectives: show both source versions and do not harmonize silently.
- No budget: leave budget ceiling and cost assumptions for confirmation; do not insert a benchmark as fact.
- Existing document appears to be a brief, RFP, or SOW: describe the classification uncertainty and adapt structure without penalizing intentionally absent sections.
- Non-evaluation request: state scope and stop, or point to the closest relevant M&E drafting task.

## Completion checklist
- Preserve the exact scope and authority of supplied facts. A cohort-level target is not a target for each center or subgroup; compare subgroup values descriptively unless a subgroup target is supplied. A decision owner is not automatically the commissioner, approver, data controller or budget holder. Label any additional role assignment as proposed and requiring confirmation.
- Check negative claims as carefully as positive claims: "not supplied" or "not confirmed" does not mean nonexistent, not done or refused. If no consent record is supplied, say consent status is unconfirmed and make contact conditional on verification; never assert that no consent was obtained merely because the input does not mention it.
- All ten TOR sections appear, including explicit placeholders where unresolved.
- Each substantive factual statement has an evidence ID or is marked as an assumption.
- Questions, scope, evidence, methods, timing, resources, and expertise align.
- Ethics and data protection are context-appropriate and not falsely certified.
- Unknown budget, sample size, targets, owners, and dates remain unknown.
- Conflicts and decisions requiring commissioner input are visible.
- Draft status and required human review are explicit.

## Interruption and resumption
If interrupted, preserve the actual TOR draft, evidence register with source filenames/versions or dates, and unresolved commissioner decisions. Resume only from files and handover supplied for the resumed task. Check whether sources changed and flag differences. Record draft changes. Never upgrade a proposal, assumption, or pending decision into an approved decision.