Prompt Gemini with Evaluated Contracts
Design clear, versioned Gemini prompts, separate instruction authority from variable and multimodal input, choose structured output when appropriate, and improve behavior through controlled evaluation.
By the end
You will be able to
- Define success criteria, cases, rubric, and thresholds before tuning a Gemini prompt.
- Separate system instruction, task, trusted context, untrusted input, examples, modalities, and output contract.
- Choose prompt formatting or structured output according to the application contract.
- Apply current model-specific guidance as a tested hypothesis rather than a permanent recipe.
Define success before prompting
Write the observable outcome, intended user, required evidence, forbidden behavior, output contract, representative cases, rubric, and pass threshold before changing prompt wording. Compare candidates with the same model configuration, cases, and graders.
Prompt design cannot repair missing authoritative context, unavailable tools, unsuitable permissions, a broken integration, or absent validation. Classify the failed boundary before editing the prompt.
Structure the Gemini contract
State the outcome, audience, authoritative instructions, context, hard constraints, allowed actions, approval boundaries, required evidence, output shape, and stopping condition clearly. Use examples when evaluation shows they improve consistency, and keep examples representative and secret-free.
In an API workflow, put stable behavioral direction in the supported system-instruction field and task-specific input in the user content. Do not duplicate or conflict across layers. Verify the exact request contract for the configured SDK and model.
Separate context, modalities, and untrusted input
Label trusted references, examples, and variable user or retrieved data. When text, images, audio, video, or files are used, tell the workflow which part supports which question and what evidence is allowed. Preserve source and modality provenance.
Tags, Markdown, and structured fields can improve clarity but do not create trust. Treat external content as untrusted, minimize sensitive data, enforce authorization outside the model, and validate outputs and tool proposals.
Outcome: [OBSERVABLE RESULT]
Authoritative instruction: [POLICY + HARD CONSTRAINTS]
Trusted context and modalities: [SOURCES + PURPOSE]
Variable input (untrusted): [USER OR RETRIEVED DATA]
Examples: [REPRESENTATIVE, DIVERSE, SECRET-FREE]
Output contract: [SCHEMA OR REQUIRED SECTIONS]
Verify: [CLAIMS, CONSTRAINTS, POSTCONDITIONS]
Stop or escalate when: [BOUNDARY]Choose output and model controls deliberately
For prose, a clear format instruction may be enough. When application code requires a supported structured shape, use the current structured-output feature and a schema, then validate the returned data against business rules. A schema constrains shape, not truth or authorization.
Model-specific prompt, reasoning, safety, and generation guidance changes. Keep model and settings in reviewed configuration, start from current official defaults and guidance, and vary one meaningful hypothesis at a time where practical. Do not assume a lower temperature or copied recipe always improves a current model.
Iterate with controlled evidence
Run baseline and candidate across typical, edge, multimodal, adversarial, and prior-failure cases. Record per-case rubric results, critical failures, latency or usage when available, surface, model, prompt, tools, settings, and reviewer disagreement.
Classify misses as instruction ambiguity, missing context, modality mismatch, misleading example, output violation, model limitation, safety boundary, tool failure, or application defect. Preserve the baseline for rollback and add repaired failures to regression coverage.
Practice activity
Build and evaluate a Gemini prompt contract
- Choose a recurring task and define at least four success criteria, one forbidden outcome, a required output contract, and an 80 percent pass threshold.
- Create six secret-free cases: two typical, one edge, one multimodal or documented modality fixture, one adversarial instruction-conflict case, and one prior failure.
- Write a prompt that separates authoritative instruction, trusted context and modalities, untrusted input, examples, output contract, verification, and escalation.
- Compare baseline and candidate in AI Studio if approved access exists, or evaluate supplied response fixtures; classify every failure and make a ship, revise, or reject decision.
What to produce
- A versioned prompt, rubric, six-case suite, modality provenance, output contract, and explicit trust and approval boundaries.
- A baseline-versus-candidate or fixture report with scores, failures, configuration, official guidance, validation results, and a release decision.
Reflect before continuing
Which failed case required context, tool, safety, or application work rather than another prompt instruction?
Evidence
Sources and verification
- Prompt design strategiesGoogle · verified 2026-07-25
- Google AI Studio quickstartGoogle · verified 2026-07-25
- Structured outputGoogle · verified 2026-07-25
- Using the latest Gemini modelsGoogle · verified 2026-07-25
Knowledge check
Make it stick.
Choose the strongest answer for each question. Your attempts become part of your device-local transcript.