Gaiish Language Specification — Version 1.0

1. Purpose

Gaiish provides a common way to express a human request to a generative AI model. Its purpose is to make the parts of a request that affect interpretation — intent, context, instructions, constraints, result and validation — explicit and reviewable. It does not define a model API, a programming language or a guarantee about an output.

2. Design philosophy

Gaiish favours explicit meaning over clever phrasing, reusable structure over one-off tricks and human review over declarations of certainty. A writer should be able to show a colleague what the model was told, what evidence it received and how the answer will be checked. The method is model-independent, while acknowledging that models interpret the same text differently.

The language is deliberately additive. A writer can start with a small BASIC prompt and add PRO fields or the full six-component method as the task demands. Structure can improve instruction adherence and reduce ambiguity, but it cannot supply facts that were never provided or make a model's answer independently true.

3. Vocabulary

4. Grammar

A Gaiish document consists of one or more declarations. A declaration begins with an uppercase label followed by a colon. Its content continues until the next declaration. A blank line between blocks is recommended for human scanning and clear boundaries. The canonical six-component order is Intent, Context, Instruction, Constraints, Result and Validation; BASIC and PRO define their own documented subsets or expansions.

LABEL:
The material belonging to LABEL.
It may contain multiple sentences or pasted source text.

NEXT LABEL:
The next declaration.

5. Intent declarations

INTENT: states the outcome behind the request: the decision, change or deliverable that makes the work useful. It is different from the verb in INSTRUCTION:. Include the audience or downstream use when those details affect trade-offs. Keep one primary outcome per prompt; name a second prompt when the work truly has two independent goals.

INTENT:
Prepare a decision brief for the finance lead so she can choose whether to renew the vendor contract.

6. Context declarations

CONTEXT: states the situation and supplies what the model cannot infer. Paste the source material under this label, then identify the audience, relevant history, systems, timing and decisions already made. Context is not a place to hide the task; use INSTRUCTION: for the task.

CONTEXT:
The reader is a non-technical customer. The current help article is below.
[paste article]

7. Instruction declarations

INSTRUCTION: names the action with a clear primary verb: analyse, draft, extract, compare, classify, translate or rewrite. Number ordered actions. Say what to do, not only what to avoid, and keep the action separate from pasted material.

8. Constraint declarations

CONSTRAINTS: defines the boundaries of an acceptable answer. It may include scope, length, count, tone, audience, budget, deadline, exclusions, safety requirements and what to do with uncertainty. Quantified constraints are easier to inspect than vague adjectives. Contradictory constraints should be resolved before the prompt is sent.

9. Output declarations

RESULT: or OUTPUT: names the finished artefact and its shape. State headings, columns, fields, schema, order and format. A result declaration describes something a person can use, not merely the topic the model should discuss.

10. Validation instructions

VALIDATION: asks the model to check its response against the declared request. Require it to recheck constraints, support claims with supplied sources, flag missing material and list assumptions. This is a self-check, not proof: a human must verify facts and anything consequential before relying on it.

11. Modifiers

Modifiers are optional, local instructions within a declaration. They are useful when a task needs a tone, audience, source priority or explicit treatment of uncertainty. A modifier does not become a new canonical component. Define a team-specific modifier the first time it is used and do not let a dense collection of modifiers obscure the main declarations.

CONSTRAINTS:
TONE: direct, calm and non-technical.
LENGTH: no more than 300 words.
EXCLUDE: claims not supported by the supplied source.

12. Examples

A small request can use BASIC. A request that needs explicit evidence boundaries and review can use the six-component method or PRO. The framework choice is part of good communication: use enough structure to expose the decisions that matter, not so much that labels become ceremony.

GOAL:
Help a new manager prepare for her first one-to-one.

CONTEXT:
The meeting is 30 minutes. The manager has the employee's role description below.
[paste role description]

ACTION:
Draft five open questions that invite discussion of priorities and support.

OUTPUT:
A numbered list, with one sentence explaining the purpose of each question.

See a full PRO exampleCompare BASIC promptsRead practical syntaxBrowse all Gaiish examplesAdapt a prompt from the library

13. Anti-patterns

• A label with no useful content: INTENT: alone does not communicate an outcome.
• A single paragraph that mixes source material, instructions and constraints so no reader can tell which is which.
• Conflicting limits, such as exhaustive coverage in ten words, left for the model to resolve silently.
• Provider-specific hidden assumptions presented as if they were part of the language.
• A request for confidence or certainty instead of a validation rule and an explicit way to report gaps.

14. Model-specific considerations

Gaiish is designed to be usable across ChatGPT, Claude, Gemini, Copilot, Grok, Llama, Mistral, DeepSeek and Qwen, but no two models interpret text identically. Context limits, instruction following, tool access, system messages and output controls vary by model and product. Keep declarations explicit, test the actual model you will use, and validate the returned result. Do not describe a provider's private behaviour as a Gaiish rule.

15. Version history

Version 1.0 is the initial published specification in this repository. The version is supplied by config.SPEC_VERSION so a future version can be rendered as a sibling route, for example /gaiish-language/specification/1.1 or /gaiish-language/specification/2.0, while this document remains addressable.

16. Changelog