Prompt Engineering Guide 2026: Chain-of-Thought, Few-Shot & Structured Output

Key Takeaways

• Role + task + format: Every effective prompt has three parts — a role (You are a senior security engineer), a specific task (Analyse this config for vulnerabilities), and a format specification (Return a JSON array of findings).
• Chain-of-thought for reasoning: Appending Think step by step to complex tasks (math, code, logic) increases accuracy by forcing the model to externalise reasoning before committing to an answer.
• Few-shot beats zero-shot for custom tasks: Two or three examples of your expected input → output format teach the model your conventions faster and more reliably than any amount of natural language description.
• Structured output is a contract: JSON mode with a schema prevents hallucinated field names, wrong types, and missing keys — essential for production pipelines where downstream code parses the response.

---

Introduction

Direct Answer: What are the most effective prompt engineering techniques for local LLMs like Ollama in 2026?

The five highest-impact prompt engineering techniques for local LLMs in 2026 are: (1) Role + context + format — start every system prompt with a specific role, provide relevant context, and specify the exact output format you want; (2) Chain-of-thought — add Think step by step or Reason through this carefully before answering to improve accuracy on reasoning tasks; (3) Few-shot examples — provide 2–5 input/output example pairs before asking your question, especially for custom formats or domain-specific tasks; (4) JSON mode — use format: "json" in Ollama’s API alongside a JSON schema description in the system prompt for machine-readable outputs; (5) Negative constraints — explicitly state what the model should NOT do (Do not include preamble, Do not explain, just output the JSON). For Qwen3 14B and Llama 4 Scout via Ollama, these techniques work identically to GPT-4o — the models are instruction-tuned with the same patterns.

“A prompt is not a magic incantation — it is a specification. Write it the way you’d write a function signature: clear inputs, defined outputs, and explicit constraints. Vague prompts produce vague results.”

---

Part 1: The Anatomy of an Effective Prompt

Every production-quality prompt has three layers:

# prompt_anatomy.py
import ollama

# ── THE THREE LAYERS ──────────────────────────────────────────────────────

SYSTEM_PROMPT = """You are a senior Python engineer reviewing code for security vulnerabilities.
                                           ↑ ROLE: who the model is

Your task: analyse the provided Python function and identify security issues.
           ↑ TASK: what to do

Return your analysis as a JSON object with this exact structure:
{
  "severity": "critical|high|medium|low|none",
  "issues": [{"line": N, "issue": "description", "fix": "suggested fix"}],
  "safe_to_deploy": true|false
}
Return ONLY the JSON. No preamble, no explanation, no markdown."""
  ↑ FORMAT: exactly what to output

USER_MESSAGE = """
def get_user(user_id: str) -> dict:
    query = f"SELECT * FROM users WHERE id = '{user_id}'"
    return db.execute(query)
"""

response = ollama.chat(
    model="qwen3:14b",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": USER_MESSAGE}
    ],
    format="json"    # Forces JSON output mode
)

import json
result = json.loads(response['message']['content'])
print(json.dumps(result, indent=2))

Expected output:

{
  "severity": "critical",
  "issues": [
    {
      "line": 2,
      "issue": "SQL injection vulnerability — user_id is interpolated directly into the query string",
      "fix": "Use parameterised query: db.execute('SELECT * FROM users WHERE id = ?', (user_id,))"
    }
  ],
  "safe_to_deploy": false
}

Compare to a vague prompt: "Review this code" → multi-paragraph prose response that requires parsing. The structured prompt produces machine-parseable output in one attempt.

---

Part 2: Chain-of-Thought Prompting

Chain-of-thought (CoT) forces the model to reason externally before producing an answer — consistently improving accuracy on tasks requiring multiple steps.

# chain_of_thought.py
import ollama

# ── ZERO-SHOT (no CoT) ────────────────────────────────────────────────────
zero_shot = ollama.chat(
    model="qwen3:14b",
    messages=[{
        "role": "user",
        "content": "A server has 16GB RAM. Docker is using 4GB. Nginx uses 512MB. "
                   "PostgreSQL is configured with shared_buffers=4GB and effective_cache_size=12GB. "
                   "Is this configuration valid?"
    }]
)
print("Zero-shot:", zero_shot['message']['content'][:200])

# ── WITH CHAIN-OF-THOUGHT ─────────────────────────────────────────────────
cot = ollama.chat(
    model="qwen3:14b",
    messages=[{
        "role": "user",
        "content": "A server has 16GB RAM. Docker is using 4GB. Nginx uses 512MB. "
                   "PostgreSQL is configured with shared_buffers=4GB and effective_cache_size=12GB. "
                   "Is this configuration valid?\n\n"
                   "Think step by step:\n"    # ← CoT trigger
                   "1. Calculate total memory used\n"
                   "2. Check if shared_buffers exceeds 25% of RAM\n"
                   "3. Check if effective_cache_size is realistic\n"
                   "4. Give your verdict"
    }]
)
print("CoT:", cot['message']['content'])

Expected output (CoT response):

CoT: 1. Total memory used:
   - Docker: 4GB
   - Nginx: 0.5GB
   - PostgreSQL shared_buffers: 4GB
   - Total committed: 8.5GB of 16GB

2. shared_buffers check:
   - Recommended: 25% of 16GB = 4GB
   - Configured: 4GB ✓ This is exactly at the recommended maximum

3. effective_cache_size check:
   - This is a PLANNER HINT, not actual allocation
   - 12GB of 16GB (75%) is the standard recommendation ✓
   - However, only 7.5GB is actually available (16 - 8.5 = 7.5GB free)
   - Setting effective_cache_size=12GB overstates available cache

4. Verdict: Configuration is PROBLEMATIC.
   shared_buffers is acceptable. However, effective_cache_size should be set to
   ~6GB (actual free RAM) not 12GB. The planner will make suboptimal index decisions
   based on optimistic cache assumptions.

CoT caught the effective_cache_size issue that zero-shot likely misses. The explicit reasoning steps provide both accuracy and a verifiable audit trail.

Qwen3’s built-in thinking mode:

# Qwen3 14B has a native thinking mode — more powerful than manual CoT
response = ollama.chat(
    model="qwen3:14b",
    messages=[{
        "role": "user",
        "content": "/think\n\nDebug this Python function: " + buggy_code
    }]
)
# /think triggers extended internal reasoning before the response

---

Part 3: Few-Shot Prompting

Show the model your expected format with 2–5 examples — faster and more reliable than describing it:

# few_shot.py
import ollama

# Task: classify customer support tickets by category and urgency
# Zero-shot fails to use your exact taxonomy — few-shot teaches it

FEW_SHOT_SYSTEM = """You classify customer support tickets.
Output JSON: {"category": "billing|technical|account|general", "urgency": "critical|high|medium|low"}
Return ONLY the JSON."""

FEW_SHOT_EXAMPLES = [
    {"role": "user", "content": "My payment was charged twice this month"},
    {"role": "assistant", "content": '{"category": "billing", "urgency": "high"}'},
    {"role": "user", "content": "I can\'t log in, getting 500 error"},
    {"role": "assistant", "content": '{"category": "technical", "urgency": "critical"}'},
    {"role": "user", "content": "How do I change my email address?"},
    {"role": "assistant", "content": '{"category": "account", "urgency": "low"}'},
]

def classify_ticket(ticket: str) -> dict:
    messages = [
        {"role": "system", "content": FEW_SHOT_SYSTEM},
        *FEW_SHOT_EXAMPLES,
        {"role": "user", "content": ticket}
    ]
    resp = ollama.chat(model="qwen3:14b", messages=messages, format="json")
    return json.loads(resp['message']['content'])

import json
tickets = [
    "The API is returning 429 errors and our product is down",
    "Can I get a refund for last month?",
    "How do I export my data?"
]
for ticket in tickets:
    result = classify_ticket(ticket)
    print(f"'{ticket[:50]}...' → {result}")

Expected output:

'The API is returning 429 errors and our product is...' → {'category': 'technical', 'urgency': 'critical'}
'Can I get a refund for last month?...' → {'category': 'billing', 'urgency': 'medium'}
'How do I export my data?...' → {'category': 'account', 'urgency': 'low'}

---

Part 4: Structured Output with Pydantic

Pydantic schemas enforce types and provide clear descriptions that guide the model:

# structured_output.py
from pydantic import BaseModel, Field
from typing import Literal, List
import ollama, json

class SecurityFinding(BaseModel):
    line: int = Field(description="Line number of the issue")
    issue: str = Field(description="Description of the security vulnerability")
    severity: Literal["critical", "high", "medium", "low"]
    fix: str = Field(description="Specific fix recommendation")

class CodeReview(BaseModel):
    safe_to_deploy: bool
    findings: List[SecurityFinding]
    summary: str = Field(description="One-sentence overall assessment")

def review_code(code: str) -> CodeReview:
    schema = CodeReview.model_json_schema()
    system = f"""You are a security-focused code reviewer.
Analyse the code and return a JSON object matching this exact schema:
{json.dumps(schema, indent=2)}

Return ONLY valid JSON. No markdown, no preamble."""

    resp = ollama.chat(
        model="qwen3:14b",
        messages=[
            {"role": "system", "content": system},
            {"role": "user", "content": f"Review this code:\n{code}"}
        ],
        format="json"
    )

    return CodeReview.model_validate_json(resp['message']['content'])

code = """
import os
def run_command(user_input):
    os.system(f"ls {user_input}")  # Command injection

def get_secret():
    return "hardcoded_api_key_12345"  # Hardcoded credential
"""

result = review_code(code)
print(f"Safe to deploy: {result.safe_to_deploy}")
print(f"Summary: {result.summary}")
for f in result.findings:
    print(f"  [{f.severity.upper()}] Line {f.line}: {f.issue}")
    print(f"    Fix: {f.fix}")

Expected output:

Safe to deploy: False
Summary: Critical security vulnerabilities found — command injection and hardcoded credential.
  [CRITICAL] Line 3: Command injection via unsanitised user input in os.system()
    Fix: Use subprocess.run(['ls', user_input], check=True) with a whitelist of allowed paths
  [HIGH] Line 6: Hardcoded API key in source code
    Fix: Load from environment variable: os.environ.get('API_KEY') or use a secrets manager

---

Part 5: Prompt Versioning and Testing

Treat prompts as code — version control, test, and iterate systematically:

# prompt_manager.py
import json
from pathlib import Path
from dataclasses import dataclass
from typing import Optional
import ollama

@dataclass
class PromptVersion:
    name: str
    version: str
    system: str
    test_cases: list[dict]

class PromptRegistry:
    """Version-controlled prompt registry."""

    def __init__(self, prompts_dir: str = "./prompts"):
        self.dir = Path(prompts_dir)
        self.dir.mkdir(exist_ok=True)

    def save(self, prompt: PromptVersion) -> None:
        path = self.dir / f"{prompt.name}-v{prompt.version}.json"
        path.write_text(json.dumps({
            "name": prompt.name,
            "version": prompt.version,
            "system": prompt.system,
            "test_cases": prompt.test_cases
        }, indent=2))
        print(f"Saved: {path}")

    def load(self, name: str, version: str) -> PromptVersion:
        path = self.dir / f"{name}-v{version}.json"
        data = json.loads(path.read_text())
        return PromptVersion(**data)

    def evaluate(self, prompt: PromptVersion, model: str = "qwen3:14b") -> dict:
        """Run test cases and return pass rate."""
        results = []
        for tc in prompt.test_cases:
            resp = ollama.chat(
                model=model,
                messages=[
                    {"role": "system", "content": prompt.system},
                    {"role": "user", "content": tc["input"]}
                ],
                format="json" if "expected_json" in tc else None
            )
            output = resp['message']['content']
            passed = tc["expected"] in output if "expected" in tc else True
            results.append({"input": tc["input"][:40], "passed": passed, "output": output[:80]})

        pass_rate = sum(1 for r in results if r["passed"]) / len(results)
        return {"pass_rate": pass_rate, "results": results}

# Define and version a prompt
registry = PromptRegistry("./prompts")

v1 = PromptVersion(
    name="ticket-classifier",
    version="1.0",
    system='Classify support tickets. Output JSON: {"category": "billing|technical|account", "urgency": "critical|high|medium|low"}',
    test_cases=[
        {"input": "Payment failed twice", "expected": '"category": "billing"'},
        {"input": "API returning 500 errors", "expected": '"category": "technical"'},
        {"input": "Change my password", "expected": '"category": "account"'},
    ]
)
registry.save(v1)
eval_result = registry.evaluate(v1)
print(f"v1.0 pass rate: {eval_result['pass_rate']:.0%}")

Expected output:

Saved: ./prompts/ticket-classifier-v1.0.json
v1.0 pass rate: 100%

---

Quick Reference: Prompt Patterns

ROLE:       "You are a {expert role} specialising in {domain}."
TASK:       "Your task is to {specific action} for {specific input}."
FORMAT:     "Return ONLY a JSON object with {fields}. No preamble."
COT:        "Think step by step before answering."
FEW-SHOT:   [user: example1] [assistant: output1] [user: example2] [assistant: output2]
NEGATIVE:   "Do not include explanations. Do not add markdown. Do not hallucinate."
CONSTRAINT: "Limit your response to {N} items. Use only the information provided."
PERSONA:    "Respond as if you are reviewing this for a production deployment."

---

Troubleshooting

Model ignores format instructions and returns prose

Fix: Add "Do not include any text outside the JSON object. Your entire response must be valid JSON." at the end of the system prompt. Use format="json" in Ollama’s API. If still failing, switch to a larger model (Qwen3 7B is less reliable for JSON than Qwen3 14B).

Responses are inconsistent across runs

Cause: High temperature setting or vague prompt. Fix: Set temperature=0 for deterministic tasks (classification, extraction). Make the task more specific — vague prompts produce variable outputs.

Few-shot examples making the model repeat them

Cause: Examples not terminated clearly, model treats them as continuation. Fix: Add a clear separator after examples: "--- END OF EXAMPLES --- Now process the following:".

---

Conclusion

Prompt engineering is the bridge between raw LLM capability and reliable production behaviour. The core toolkit — role/task/format prompts, chain-of-thought for reasoning, few-shot for custom patterns, JSON mode for structured output, and versioned evaluation — applies identically to Qwen3 14B via local Ollama and GPT-4o via the OpenAI API. The sovereign advantage: iterate and test prompts locally at zero cost before committing to a cloud API deployment.

See LangChain and LangGraph with Ollama to use these prompt patterns in agent pipelines, and MCP Protocol: Build a Server in Python to expose prompt-engineered tools as MCP endpoints.

---

People Also Ask

Does prompt engineering work the same way on local models as on GPT-4?

Yes — the core techniques (system prompts, chain-of-thought, few-shot, JSON mode) work identically because local models like Qwen3 14B and Llama 4 Scout are instruction-tuned with the same RLHF and DPO methods as GPT-4. The differences: larger models (GPT-4o) handle ambiguous instructions more gracefully; smaller local models (7B) require more explicit formatting instructions; some local models have model-specific features (Qwen3’s /think mode). For structured output, Ollama’s format="json" is equivalent to OpenAI’s response_format={"type": "json_object"}.

How many few-shot examples should I include?

2–5 examples cover most cases. Fewer than 2 is usually insufficient for the model to reliably infer the pattern. More than 5–8 adds context window tokens with diminishing returns and may confuse models into paying more attention to the examples than the actual task. The exception: if your task has many distinct categories or complex format requirements, 8–10 examples may be warranted. Always test with 2 examples first — if performance is acceptable, don’t add more.

What is the difference between system prompt and user message?

The system prompt sets the model’s persistent role, constraints, and output format — it’s the developer-controlled context that doesn’t change across queries. The user message is the per-query input — what the end user or your application sends for each request. In Ollama’s API: {"role": "system", "content": "..."} for the system prompt; {"role": "user", "content": "..."} for each query. The model treats system prompt instructions as higher-priority than user messages — use the system prompt for format constraints you want to hold across all interactions.

---

Part 12: Advanced Prompt Composition

Prompt engineering is a deliberate craft. The best prompts are structured, repeatable, and aligned to the task.

12.1 Task-oriented instructions

Start prompts with a clear task statement. Describe the desired output format and the exact constraints.

You are an expert system documentation writer. Summarize the following content into bullet points and include one recommendation at the end.

12.2 Few-shot examples

Provide a small number of high-quality examples when you need the model to mimic a specific style or format. Keep examples concise and directly relevant.

12.3 Chain-of-thought and rationale

For reasoning tasks, ask the model to explain its reasoning before giving a final answer.

Explain your reasoning step-by-step, then provide the final recommendation.

This can improve correctness, especially for complex queries.

Part 13: Prompt Templates and Reuse

A prompt library makes engineering prompts manageable.

13.1 Template variables

Use placeholders for user input, context, and options.

Context:
{context}

Question:
{question}

Answer:

13.2 Template versioning

Version your templates along with the evaluation data they were tuned on. When you change a template, record the observed effect.

13.3 Reusable prompt blocks

Factor repeated instructions into reusable blocks. For example, keep a format_instructions block that you append to many different prompts.

Part 14: Robustness and Safety

Prompts should guard against hallucination and misuse.

14.1 Instruction constraints

Tell the model what not to do as explicitly as what to do.

Do not invent facts. If the answer is not in the material, reply "I don't know."```

### 14.2 Output validation

Design prompts that make it easy to validate the output automatically. For example, ask for JSON with specific keys, then parse it and reject invalid responses.

### 14.3 Safety filters

Wrap prompts with a safety layer that detects sensitive or problematic input before it reaches the model. This is especially important for self-hosted systems that process internal data.

## Part 15: Iterative Prompt Testing

Prompt engineering is an iterative cycle.

### 15.1 A/B testing prompts

Compare prompt variants on a set of representative queries. Measure both accuracy and user satisfaction.

### 15.2 Simulated edge cases

Test prompts against edge cases, ambiguous queries, and adversarial inputs. Observe how the model behaves when the instruction is incomplete or contradictory.

### 15.3 Regression prompts

Keep a set of prompts that have historically exposed problems. Re-run them whenever the prompt template or model changes.

## Part 16: Prompting for Different Model Families

Different models respond differently to prompts.

### 16.1 Decoder-only models

Decoder-only models often benefit from explicit completion delimiters and stop tokens. Make the task instruction clearly separate context from query.

### 16.2 Instruction-tuned models

Instruction-tuned models understand task statements more naturally, but they still benefit from precise format instructions and examples.

### 16.3 Retrieval-augmented prompts

When you use retrieval, include a grounding section with sources and a strict instruction to use only that material.

```text
Sources:
{sources}

Question:
{question}

Answer using only the sources above.

Part 17: Prompt Engineering Metrics

Measure prompt quality in objective ways.

17.1 Format compliance

Track whether outputs conform to the expected format. A high format compliance rate is especially important for structured prompts.

17.2 Content correctness

Use reference answers or human review to score correctness. For some tasks, semantic similarity metrics can also help.

17.3 Cost and performance

Record prompt token usage and latency. Longer prompts may improve accuracy, but they also increase cost and response time.

Part 18: Organizing Prompts for Teams

Prompt engineering works best when prompts are shared and maintained collaboratively.

18.1 Prompt repository

Keep a centralized repository of prompt templates, examples, and evaluation results. Use clear names and tags so engineers can find the right prompt for a task.

18.2 Documentation

Document the intent, expected input, expected output, and failure modes for each prompt.

18.3 Review and governance

Review prompt changes in the same way you review code. Ensure major prompt adjustments are justified with empirical results.

Part 19: Final Prompt Engineering Checklist

• prompts start with a clear task statement
• output format is explicitly defined
• safety constraints are included
• prompt templates are versioned and documented
• prompt behavior is tested with edge cases
• prompt changes are reviewed and recorded
• model-specific tuning is considered
• prompt reuse is encouraged through a library

Prompt engineering is an engineering discipline, not a one-off creative act. When you treat prompts as reusable, measurable, and manageable artifacts, your AI system becomes far more reliable and predictable.

Part 20: Prompt Engineering for Complex Workflows

Complex applications require prompts that handle multi-step reasoning and context management.

20.1 Multi-turn prompt design

When building multi-turn interactions, preserve only the most relevant context. Summarize earlier turns instead of repeating everything.

20.2 Scoped context windows

Use a scoped context window for task-specific information. Keep global instructions separate from per-request data.

20.3 Structured task decomposition

Break complex tasks into simpler subtasks. Ask the model to complete each subtask in sequence, then combine the results.

Step 1: Extract the key facts.
Step 2: Summarize them.
Step 3: Produce the final recommendation.

Part 21: Prompt Automation and Tooling

Manage prompts with automation rather than manual edits.

21.1 Prompt linting

Use linting rules to enforce prompt structure, required sections, and consistent language. Detect common anti-patterns automatically.

21.2 Prompt testing harness

Keep a test harness that runs prompt templates against sample inputs and checks output structure. This helps catch failures before deployment.

21.3 Prompt documentation

Document each prompt’s intent, expected inputs, and expected outputs in a centralized prompt library.

Part 22: Prompt Efficiency and Cost Control

Efficient prompts save both tokens and latency.

22.1 Minimal necessary context

Give the model only the context it needs. Trim extraneous background text and keep the input window focused.

22.2 Reusable instruction blocks

Reuse the same instruction blocks across prompts to reduce maintenance overhead and improve consistency.

22.3 Output truncation and paging

If responses can be long, paginate them or ask for summaries with follow-up details as needed. This avoids unnecessary token use for overly verbose first responses.

Part 23: Evaluation and Governance

Prompt engineering needs measurable goals.

23.1 Prompt performance metrics

Track correctness, format compliance, hallucination rate, and token usage. Use these metrics to compare prompt variants objectively.

23.2 Human-in-the-loop review

Include human review for new prompt templates, especially those used for important outputs or customer-facing content.

23.3 Prompt change control

Version control prompt templates and review changes with stakeholder signoff when the prompt affects business-critical behavior.

Part 24: Final Prompt Engineering Checklist

• complex tasks are decomposed into clear subtasks
• multi-turn context is managed and summarized
• prompts are linted and tested automatically
• prompt templates are documented and versioned
• output format and safety constraints are explicit
• prompt cost and performance are monitored
• prompt changes are reviewed and justified with data
• prompt reuse is prioritized across the system

Good prompt engineering makes AI behavior predictable, auditable, and maintainable. Treat it as a systems engineering discipline rather than a one-off creative exercise.

Part 25: Prompt Localization and Internationalisation

When your system supports multiple languages, prompt design must account for linguistic variance.

25.1 Language-specific instructions

Write templates that work in the target language. Do not rely on automatic translation of English prompts for production behavior.

25.2 Multilingual examples

Provide few-shot examples in the same language as the input query. This improves fluency and reduces cross-language hallucinations.

25.3 Culture-sensitive phrasing

Adapt examples and safety constraints to the cultural expectations of each locale. Avoid idioms or references that do not translate clearly.

Part 26: Model-Specific Prompt Calibration

Different models require different prompt engineering approaches.

26.1 Temperature and sampling

Adjust sampling settings with the prompt itself. A prompt that asks for creative writing may tolerate higher temperature than one asking for factual summaries.

26.2 Stop sequences and delimiters

Choose stop sequences that align with the model’s generation behavior. For models that echo prompts, explicit delimiters are critical.

26.3 Identity and role prompts

Use role prompts such as You are a technical writer or You are an assistant for developer documentation. These help the model adopt a consistent tone.

Part 27: Completion and Follow-up Strategies

Sometimes the best prompt is one that issues a follow-up request.

27.1 Summarize and refine

Ask the model for a summary first, then request a refinement pass.

First summarise the content. Then rewrite the summary in bullet points.

27.2 Guided refinement

Use the model’s own output as input for a second pass. For example, ask it to shorten, clarify, or format the first answer.

27.3 Feedback-driven prompts

If the initial response is not ideal, include a feedback loop that describes what changed.

The previous answer was too verbose. Please rewrite it more concisely.

Part 28: Prompt Governance and Lifecycle

Treat prompt templates as products.

28.1 Prompt lifecycle stages

Define stages such as draft, review, approved, and deprecated. Manage prompts through these stages to avoid accidental use of obsolete templates.

28.2 Ownership and stewardship

Assign prompt owners who are responsible for maintaining templates, measuring performance, and updating them when requirements change.

28.3 Compatibility checks

When model versions change, validate existing prompts against the new model before switching the production service.

Further Reading

• LangChain and LangGraph with Ollama — use prompt templates in agent pipelines
• Best Local LLM Models for Coding in 2026 — model capabilities that these prompts leverage
• How to Install Ollama and Run LLMs Locally — the inference backend for all examples
• MCP Protocol: Build an AI Tool Server in Python — expose prompt-engineered functions as MCP tools

Tested on: Ubuntu 24.04 LTS (RTX 4090), macOS Sequoia 15.4 (M3 Max). Ollama 0.5.12, Qwen3 14B. Last verified: April 28, 2026.