Gaiish PRO — Gaiish

PRO is for work that has a reviewer, a downstream system, a meaningful consequence or a need to be repeated by someone else. It expands the compact BASIC shape into eight components. Role establishes the stance and expertise to adopt; Knowledge separates provided facts from general background; Process makes reasoning steps inspectable; Constraints and Validation bound and check the result.

The eight components

Role: The perspective, responsibility or expertise the model should use. A role sets the lens; it does not grant real-world credentials or access.
Intent: The outcome the work serves and the decision or deliverable behind the request.
Context: The situation, audience, source material and prior decisions that shape the task.
Knowledge: Facts, definitions, policies or domain rules the model must treat as the working knowledge for this task. Mark assumptions and unknowns.
Constraints: Hard boundaries: scope, exclusions, tone, safety, budget, time, length and requirements that make an answer acceptable.
Process: The sequence or method to follow. Ask for intermediate checks or a decision procedure when the order affects the outcome.
Output: The finished artefact and its exact structure: sections, fields, schema, format and audience.
Validation: The checks the model should perform before returning the result, including source support, constraints, gaps and assumptions.

When to choose PRO over BASIC

Choose PRO when the prompt will be handed to a colleague, used repeatedly, evaluated against a rubric or fed into a workflow. PRO is also useful when the model must keep provided policy separate from its general knowledge, follow a multi-stage process or show where the source material does not answer a question. BASIC remains the better choice for a quick, low-risk request where those distinctions would add more writing than value.

Role
Intent
Context + Knowledge
Constraints
Process
Output
Validation

A full PRO prompt

ROLE:
You are an internal operations analyst preparing a decision brief for a COO. Be precise about evidence and do not present assumptions as facts.

INTENT:
Decide whether our support team should move from four shifts to three without reducing coverage for urgent tickets.

CONTEXT:
[paste the last 12 weeks of ticket volumes by hour and priority]
The team has 8 people. Current coverage is 08:00–20:00 Monday–Friday. The COO will review the brief on Monday.

KNOWLEDGE:
Urgent means priority P1 or P2. A shift is 8 paid hours. The source table is the authority for volumes; do not fill missing hours with estimates.

CONSTRAINTS:
Do not recommend overtime or hiring. Preserve current weekday coverage. Show all calculations, use plain language, and distinguish observed values from assumptions.

PROCESS:
1. Check the source for missing or inconsistent rows.
2. Calculate urgent-ticket volume by hour and compare it with each shift pattern.
3. Identify the coverage gap, if any, under three shifts.
4. State the decision the evidence supports and the evidence it cannot support.

OUTPUT:
A decision brief with Recommendation, Evidence table, Calculation notes, Risks, and Questions for the COO. Include a one-sentence executive summary.

VALIDATION:
Recheck every calculation against the pasted rows, flag missing hours, and list each assumption. If the data cannot support a decision, say so instead of inventing a coverage estimate.

A shorter request, made PRO

Traditional prompt

Look at our support data and tell me if we can reduce shifts.

Gaiish prompt

ROLE: Internal operations analyst writing for the COO.

INTENT: Decide whether three shifts preserve urgent-ticket coverage.

CONTEXT: 8-person team; current weekday coverage 08:00–20:00; [paste 12 weeks of ticket volumes by hour and priority].

KNOWLEDGE: P1/P2 are urgent; pasted rows are authoritative; missing hours are unknown.

CONSTRAINTS: No overtime or hiring; show calculations; separate facts from assumptions.

PROCESS: Check data, calculate hourly urgent volume, compare shift patterns, identify gaps, then state the limit of the evidence.

OUTPUT: Decision brief with recommendation, evidence table, calculations, risks and questions.

VALIDATION: Recheck calculations and flag every missing value or assumption.

Why this works better

The PRO version does not ask the model to be more confident. It gives the model and the reviewer a shared record of the role, decision, evidence boundary, rules, process, deliverable and checks. That makes the prompt easier to hand off and the answer easier to challenge. Models still interpret prompts probabilistically and should not replace human review.

A framework, not a ceiling

PRO is the current eight-component framework, not a claim that every future task must look exactly like this. The architecture allows further frameworks to be added later as the vocabulary develops. New shapes can be documented alongside BASIC and PRO without changing the six canonical components of the Gaiish method.

How to write the labels Read the language specification Compare with BASIC Check component definitions