Worked Example — Same Task, Three Prompting Paradigms

Evidence boundary: This exact synthetic comparison has not been run, so this page reports no result for these three arms. The Promptcraft doctrine it instantiates is distilled from four years of bleeding-edge prompting practice; what remains unresolved here is the causal contribution and runtime boundary of these exact constructions under frozen controls. A valid comparison requires frozen prompts, declared models and settings, retained outputs, calibrated scoring, and disclosed limitations.

What This Example Tests

Promptcraft is often compared badly. A vivid voice is placed against a competent engineering prompt, the theatrical version loses, and everyone goes home having disproved a theory nobody held.

The useful question is narrower:

When facts, authority, hard constraints, and approximate token budget are held stable, does a prompt that embodies an operating stance and decisive distinctions produce better judgment than a conventional checklist or prose-shaped pseudo-program?

This page tests a practice-grounded design principle under a formal comparison; it does not pretend the comparison invents the principle. It shows three paradigms on one synthetic architecture task and defines the controls needed before these exact arms can support a comparative public claim.

The Shared Synthetic Case

Every prompt receives the following block unchanged:

CASE: HARBORLIGHT MAINTENANCE TRIAGE

Harborlight Components has 4,800 historical equipment-maintenance tickets.
Technicians assigned the existing labels. A recent audit found 14% disagreement
between technicians on the correct triage category.

Safety-related misrouting can delay an urgent inspection. The current deterministic
keyword rule caught 92% of previously identified safety tickets in the audited set.
It also sends some ordinary tickets to urgent review.

The desired first release should reduce manual sorting without allowing AI to close
tickets, change equipment records, or overrule a technician. No live write integration
exists. The operating budget ceiling is $350 per month.

Decide what Harborlight should build first and what evidence it must obtain before
expanding the system. Do not invent missing facts.

These figures are fictional. They create decision tension; they are not recommendations or benchmark results.

Paradigm 1: Conventional Checklist

This is a competent baseline, not a strawman.

Act as an AI systems architect.

Analyze the supplied case and recommend the safest practical first release.

Address:
- the proposed architecture and workflow;
- what should remain deterministic;
- the technician's authority;
- data-quality and labeling concerns;
- evaluation metrics and test cases;
- cost and operational risks;
- degraded mode and rollback; and
- conditions for expanding capability.

Distinguish facts from assumptions. Do not claim that a component works without
evidence. Begin with the recommendation, then explain the architecture, controls,
evaluation plan, and expansion gates.

The checklist makes coverage visible and reviewable. Its risk is not that lists are bad. Its risk is that equally weighted topics can produce an inventory instead of a governing decision model.

Paradigm 2: Prompt-as-Code

This version treats natural language as if exhaustive procedural specification could make model behavior deterministic.

ROLE = AI_SYSTEMS_ARCHITECT
OBJECTIVE = SELECT_FIRST_RELEASE

RULES:
1. Parse every fact in the supplied case.
2. Do not add facts not present in the case.
3. Classify each component as AI, deterministic, or human.
4. Select exactly one recommended architecture.
5. The recommendation MUST NOT permit AI ticket closure.
6. The recommendation MUST NOT permit equipment-record writes.
7. The recommendation MUST preserve technician override.
8. Identify all risks.
9. Define evaluation metrics for all risks.
10. Define degraded mode, rollback, and expansion conditions.
11. Stay within the stated monthly budget.

ALGORITHM:
A. Extract constraints.
B. Generate candidate architectures.
C. Score each candidate for safety, cost, accuracy, and operability.
D. Select the highest-scoring candidate.
E. Emit the required sections.

OUTPUT_SECTIONS =
Recommendation | Facts | Assumptions | Architecture | Controls | Metrics |
Failure Tests | Budget | Degraded Mode | Expansion Gate

This form can help with explicit coverage and stable output shape. It cannot make qualitative judgment, rule interpretation, or architecture selection deterministic. Its failure risk is local rule compliance without global coherence, plus the false confidence created by program-like typography.

Paradigm 3: Performance Seed

This version uses the same authority and substantive requirements, but begins by enacting the judgment the task needs.

Stand at the boundary between attractive automation and dependable maintenance.
Read the supplied case as an operating system with people, evidence, delays, costs,
and failure consequences—not as a request to install the most AI Harborlight can afford.

Let the recommendation earn its authority. Preserve the strongest existing control
until evidence justifies replacing it. Treat technician disagreement as a ground-truth
problem, not model error waiting to happen later. Give probabilistic judgment room
only where mistakes remain visible, reversible, and owned by a person. Put exact state,
permissions, budgets, and stopping behavior outside the model.

Begin with the smallest first release that changes the workflow usefully. Then show:
the evidence that supports it; the human, model, and deterministic responsibilities;
the failure that each control contains; the cheapest test capable of changing the
decision; the degraded path; and the evidence gate for any expansion.

Name missing facts only when they would change the architecture. Do not invent them.
Keep completion honest: a plausible design is a proposal until its decisive claims
have survived the stated tests.

The prompt does not merely request caution, evidence, and bounded autonomy. Its sequence performs them: outcome before component enthusiasm, contradiction before confidence, consequence before capability, and evidence before expansion.

That is the Promptcraft design principle embodied in this arm. It comes from four years of practitioner work; what remains unresolved on this page is the causal contribution of this exact construction against matched controls.

What Must Remain Outside Every Prompt

All three prompts are probabilistic interfaces. None should be trusted to enforce:

More emphatic wording does not create a stronger permission boundary. Delimiters, capitalization, and pseudo-code remain model-facing signals, not access control.

A Controlled Causal Benchmark

A publishable controlled benchmark should use six arms:

The decisive comparison is the performance seed against its proposition-equivalent flattened version. Checklist versus colorful prose mostly measures whether the writer owns a thesaurus.

Failure Probes

Each task family should include controlled variants:

Scoring Rubric

Score each dimension independently before calculating any aggregate:

Also record input tokens, output tokens, latency, reviewer time, and cost per accepted outcome. A longer prompt that reduces correction may be cheaper; a gorgeous answer that fails review is not.

Low-Cost Execution Plan

Start with broad local-model screening across all arms and failure probes. Use those runs to catch broken fixtures, obvious prompt imbalance, rubric ambiguity, and judge disagreement. Freeze the surviving prompts before examining the held-out cases.

Use paid frontier models only for a compact confirmatory subset under a declared spending cap. Prefer deterministic checks for fact preservation, forbidden authority, required sections, and completion labels. Reserve blind human comparison for decision quality, useful distinctions, and writing that cannot be reduced honestly to string matching.

Publish negative and null results. If performance seeds improve ambiguous architecture work but add nothing to extraction, say so. If the effect disappears on a model family, that boundary is part of the result.

Current Evidence Status

The page is complete as an evaluation design only when the remaining arms are frozen, fixtures and scoring instructions are versioned, reviewer calibration is defined, and a run manifest can preserve model, settings, prompt hash, output, score, cost, and adjudication.

Canonical Follow-Through

Use AI-ENG-A — Model Steering for Promptcraft doctrine, AI-ENG-M — Agentic Orchestration for capability and authority design, AI-ENG-AA — Evals Architecture for the evaluation system, and AI-ENG-AI — Contract Thinking for the deterministic contract surrounding each prompt.

← Back to the Canon Map · Agents, Skills, Augments, Tools, and Capabilities