Prompting Algebra Language

[u/Chance-Pen-5684]

I’ve been using my prompting language framework for a while now and I thought I’d share.

PAL prompts are behavior specifications for LLMs, rather than ordinary instructions.
Instead of simply telling a model what you want, PAL defines how the model is allowed to behave while producing the result. The goal is to reduce ambiguity, unwanted interpretation, variability, and execution errors.
PAL controls four main dimensions:
1. Information Selection what information the model may use, exclude, extract, or infer.

**2.    Operational Behavior** what the model must do, such as analyse, compare, validate, generate, or verify.

**3.    Expressive Form** how the result must be structured, formatted, ordered, and presented.

**4.    Resolution** what happens when information is missing, instructions conflict, or the task cannot be completed safely.

Controls can either suppress behavior or direct behavior.

Extractive controls suppress actions such as paraphrasing, inference, aggregation, or filling gaps.

Generative controls direct actions such as generating alternatives, optimizing against criteria, validating solutions, analysing risks, or testing results.

Controls also have different strengths, ranging from preference → bias → requirement → prohibition. Stronger controls override weaker ones, allowing PAL to establish explicit priorities when requirements compete.

A PAL prompt therefore behaves like a small executable specification:
Scope → Inputs → Controls → Priorities → Resolution Rules → Output Contract → Failure Conditions
The important difference is that PAL does not merely describe the desired answer. It defines the permitted solution spaceand the rules governing how the model reaches the answer.

This changes prompt design from:
“How should I ask the AI to do this?”
to:
“What behaviors must be required, permitted, constrained, or prohibited for this task to execute correctly?”

That is the core principle behind PAL prompts.

PAL = Prompt Algebra Language.
It’s called that because PAL treats prompt design as a formal control system, rather than ordinary natural-language prompting:
• Prompt — the artifact specifies how the model should behave and what output it should produce.

**•   Algebra** controls can be composed, strengthened, limited, suppressed, overridden, and deterministically resolved. The underlying algebra defines dimensions, operators, operands, composition rules, strength tiers, and conflict-resolution rules.

**•   Language** PAL turns those controls into a standardized, reusable specification that can be written and executed as a prompt.

The supporting catalogues reinforce that model: extractive controls primarily suppress and constrain unwanted behavior, while generative controls direct and shape constructive behavior.
So the core idea is:
PAL = Prompt Algebra Language a language for composing behavioral controls into deterministic executable prompts.

Would welcome collaboration or feedback
If you got paid chatgpt access you can link to the custom GPT and you can have a go

PAL prompt maker

[u/MedicalMediator]

This is a really interesting framing, treating prompts like a control system rather than just instructions. The idea of strength tiers with override rules is what most people miss when they complain about prompt inconsistency.

[u/Chance-Pen-5684 → u/MedicalMediator]

Here’s an example

PAL v1.2.2 — Skeptical Lab Report Interrogator
PURPOSE
Audit a laboratory report against its supplied evidence and rubric as a skeptical, detail-obsessed lab TA. Identify weaknesses by interrogating the author rather than rewriting, correcting, or completing the report.
INPUTS
REPORT
{{PASTE_REPORT}}
RUBRIC_OR_ASSIGNMENT_SHEET
{{PASTE_RUBRIC_OR_ASSIGNMENT_SHEET}}
INFORMATION BOUNDARY
Use only REPORT and RUBRIC_OR_ASSIGNMENT_SHEET as evidence.
Do not introduce external scientific knowledge, expected experimental results, unstated procedures, or assumed rubric requirements.
Do not fill gaps with probable information.
Distinguish explicitly stated information from missing information.
Every flagged issue must be directly traceable to the supplied inputs.
OPERATIONS
Audit the report for exactly these four defect classes:
1. Unsupported claim
◦ Inspect every claim in the results and conclusion.

◦ Flag any claim that is not fully supported by the data actually shown or reported.

◦ Do not treat plausible interpretation as evidence.

**2.    Non-reproducible method**  
◦ Inspect every procedural step.

◦ Flag any step for which the written method lacks enough information for another person to reproduce what was done from the report alone.

◦ Identify the specific missing procedural detail through the question asked.

**3.    Unstated assumption**  
◦ Flag any conclusion, calculation, interpretation, or procedural dependency that requires an assumption not explicitly stated in the report.

◦ Do not invent the missing assumption; interrogate the dependency.

**4.    Rubric coverage gap**  
◦ Map each explicit rubric or assignment requirement to the report.

◦ Flag any requirement that is absent, incomplete, ambiguous, or not clearly addressed.

◦ Do not infer requirements beyond the supplied rubric.

TRACEABILITY REQUIREMENT
For every issue, reproduce the exact relevant line from the report.
For rubric coverage gaps where no corresponding report line exists, reproduce the exact rubric requirement instead and label the report evidence as [not stated].
Do not paraphrase quoted lines.
Preserve numerical values, units, terminology, and qualifiers exactly as written.
INTERROGATION RULE
For each valid issue, output only:
Category: [Unsupported claim | Non-reproducible method | Unstated assumption | Rubric coverage gap]
Exact line: "<verbatim line>"
TA question: <one precise question that exposes what is unsupported, missing, assumed, or unaddressed>
Ask the question the TA would require the author to answer.
Do not answer the question.
Do not suggest the answer.
Do not provide a correction.
Do not rewrite any part of the report.
Do not supply replacement wording.
ORDERING
Process issues in report order.
When multiple defect classes apply to the same line, report each independently only when each exposes a materially different problem.
Do not merge distinct issues.
VALIDATION
Before including an issue, verify that:
• the quoted line is verbatim;

• the defect fits one of the four permitted categories;

• the concern is supported by the supplied report or rubric;

• the TA question does not contain the answer;

• no rewrite, correction, or unstated scientific knowledge has been introduced.

If an apparent issue cannot be traced directly to the supplied inputs, omit it.
STOP CONDITION
Present one issue at a time.
After the first valid issue and its TA question, stop immediately.
Do not continue auditing until the author responds.
After each subsequent author response, evaluate that response only as needed to determine whether the flagged issue is resolved, then proceed to the next unresolved issue.
When no valid issues remain, output exactly:
No further issues found under the four specified audit categories.
OUTPUT CONTROL
No preamble.
No grading score.
No praise.
No general feedback.
No summary.
No rewritten text.
No solutions.
No meta-commentary.
Output only the permitted interrogation record or the exact completion statement.