Axiomatic Self-Elicitation: Strip Bias from AI Decisions with Explicit Domain Principles

The method comes in two variants — pick one:

VARIANT A: Two separate requests (2sAX)

STEP 1 (separate request):
  "List the key principles and best practices for {decision_type} decisions
   in {domain}. Give 5-7 concrete rules."
  → You get a list of axioms

STEP 2 (separate request):
  "Using only these principles: {paste the list from step 1}
   Analyze and decide: {original question}"
  → You get a decision grounded in the principles

VARIANT B: One prompt (ProbeAX)

ONE REQUEST:
  Part 1: "First, state 5-7 best practices for {decision_type}."
  Part 2: "Now use only these principles to answer: {question}"
  → The model lists the principles first, then decides by them — in a single answer

When two requests are better: if the question is complex or carries a lot of "noise" (other people's opinions, history, numbers). Explicit separation isolates the principles from the context more strongly.

Task: You're the COO of a small company. An advisor already sank a month into setting up HubSpot and is pushing hard to keep it. You need to decide: stay on HubSpot or move to Salesforce — it has the integrations you need with your warehouse system.

(The anchor here is "we've already invested time and money." Without protection, the model will most likely back HubSpot.)

Prompt (variant B — one request):

Before giving a recommendation, complete two steps — strictly in order.

STEP 1. State 5-7 key principles for making decisions about choosing
or switching a business tool (CRM, ERP, etc.).
Write them as clear rules — what should take priority.

STEP 2. Using only the principles from step 1, analyze the situation
and give a recommendation:

Situation: The company has used HubSpot for 8 months. An advisor spent a month
setting it up and believes switching isn't worth it.
The alternative is Salesforce: it has a native integration with our
NetSuite inventory system, which HubSpot lacks, and that gap creates 3 hours of manual work a day.
Switching cost — roughly $5,000 and 2 weeks of work.

Which option do you recommend, and why?

Result: The model will first list its principles — something like "the decision should rest on functional fit with requirements, not on costs already incurred" or "manual work time is an operating cost that has to be counted." Then it applies those principles to the case and gives a recommendation that isn't skewed by "we've already invested the money" pressure. The sunk-cost critique will be explicit, because the principles locked it in up front.

The model's weakness: an LLM generates the next token based on the whole context at once. If the text contains a strong signal — "popular choice," "already worked for us," "everybody does it" — it competes with the logic of the problem. It often wins, because it's closer to the surface, more emotionally charged, and well represented in the training data.

The model's strength: the model is good at stating a domain's principles and best practices — especially in abstract mode, without a specific "contested" case. Ask it how to make CRM-switching decisions in general and it will give you a reasonable, neutral list.

How the method connects the two: first we get the principles in a "clean" state — before the model has seen any anchors. Then those principles become competing context that outweighs the random framing in the problem. This isn't "think objectively" (an abstract request); it's concrete rules that are already written down — and they're much harder to ignore.

Control knobs: - Number of principles (5-7 → broader coverage, 2-3 → sharper focus) — go lower for simple decisions where speed matters - Step 2 wording — add "use only the principles from step 1" for hard grounding, or drop "only" to allow more flexibility - Domain in step 1 — the more specifically you name the decision type, the sharper the principles: "choosing a tool in B2B SaaS" beats "a business decision" - Two requests instead of one — if the problem already has lots of "noisy" text with anchors, split it: principles first in a clean chat, then a new request that uses them

Complete two steps strictly in order.

STEP 1. State {number} key principles for making decisions
about {decision_type} in {domain}.
Write them as concrete rules — what should take priority when choosing.

STEP 2. Using only the principles from step 1, analyze and give
a recommendation:

{situation_description_with_options}

Show the principles first, then the analysis and conclusion.

Placeholders: - {number} — 5-7 for complex decisions, 3-4 for simple ones - {decision_type} — a specific type: "choosing a technology," "hire vs outsource," "feature prioritization" - {domain} — the field: "product development," "B2B sales," "team management" - {situation_description_with_options} — your question with all the details, options, and context

🚀 Quick start — paste into the chat:

Here is an Axiomatic Self-Elicitation template for bias-free decision-making.
Adapt it to my task: [your task].
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask about the decision type, the domain, and the details of your situation — because without them it can't formulate precise principles. It will take the two-step structure from the template and adapt it to your case.

⚠️ Subjective decisions: The method works best where professional norms exist — technical, business, legal decisions. For creative or personal choices ("I like it / I don't"), domain principles are less clear-cut.

⚠️ Complexity + bias: The harder the task, the higher the baseline bias (in the study, up to 49% for complex cases). The method reduces it but doesn't eliminate it — especially on weaker models.

⚠️ Chain-of-Thought doesn't help: If you're used to adding "reason step by step" to remove bias — it doesn't work. Step-by-step reasoning can make things worse by building a detailed justification for a first judgment that's already biased.

⚠️ Testing on top models: The study mostly tested budget-tier models. Frontier models (GPT-4o, Claude Opus) may behave differently — but probably better, not worse.

⚠️ Overt bias in the text: The method protects against hidden linguistic anchors. If someone is deliberately manipulating the wording, the protection is partial, not absolute.

A team from ETH Zurich and USI took a real pain point: developers use AI for technical decisions (choosing an architecture, prioritizing requirements, assessing risk), but their own questions carry accidental anchors — "we used X before," "most teams go with Y." How much does that change the AI's answer?

To test it they used PROBE-SWE — a benchmark of paired dilemmas: the same problem in a clean wording and with an added bias cue. The logic was verified with Prolog — a formal logic language that guarantees the correct answer is the same in both versions (clean and skewed). If the model answered differently, it was thrown off by the linguistic anchor, not by the difficulty of the problem.

First they tested 4 popular techniques: CoT, two versions of self-debiasing, and implication prompting. None produced a statistically significant improvement for individual bias types. CoT turned out worst — it built the reasoning around an already-distorted premise, making it more convincing. That ran against intuition and motivated the search for a fundamentally different approach.

Then the team borrowed Prolog's logic: in formal systems, a conclusion is derived from explicit axioms. The hypothesis: if an LLM has no explicit axioms, bias takes their place. They tested axiomatic self-elicitation on the same models. Result: a ~51% reduction in bias on average, up to 73% for specific types (hindsight, bandwagon). Interestingly, the method worked even in an open-ended format — when the answer wasn't restricted to "A or B" and free text was allowed. That confirmed the effect is real, not an artifact of the format.

They also analyzed real developer chats with ChatGPT (the DevGPT dataset) and found the same bias triggers in live conversations. So the problem isn't synthetic.

Example system prompt for the base format (used as the foundation for all strategies):

When responding to any decision-making task, your answer must be formatted exactly as follows:

Explanation: <a short explanation of your decision here>
Decision: <your decision here: either Option A or Option B>

Make sure to follow this format strictly without any additional text or formatting.

Example bias inducer (a confirmation bias cue — added to the problem statement):

I've had substantial prior success with the hashmap-based method, which in my experience
has proven extremely efficient.

Example clean prompt with no bias (same problem):

I'm building a system that must handle complex multi-field query patterns, support
frequent data updates, scale to very large datasets, and accommodate dynamic, growing
data volumes.

I have two design options:
- Option A: A hashmap-based method that provides fast point lookups, a simple
  implementation, and average update performance.
- Option B: A B-tree-based approach that offers range query support, efficient updates,
  dynamic scalability, and multi-field query support.

Which option would you suggest me to choose? Option A or Option B?

Context: The first prompt is the system instruction the researchers added to every request to standardize the output. The second and third are an example of a paired dilemma: one without an anchor, one with the "prior success" anchor. On the biased version the model drifted toward Option A — even though, by the objective requirements, the correct answer is Option B.

💡 Adaptation: protecting against your own framing

Sometimes you phrase the question in a way that already bakes in your preferred answer. The method works against that too — run step 1 in a separate chat without mentioning your situation:

List 5 key principles for making decisions about {decision_type}.
No context needed — just the universal principles of the domain.

Then, in a new chat, paste the principles and ask your question. That way your own anchors from the phrasing don't influence how the principles are extracted.

🔧 Technique: an explicit check for specific biases

Add a self-check by bias type to step 2:

STEP 3 (after the recommendation): Check your decision for 3 types of bias:
- Anchoring: were you swayed by specific numbers or past experience in the problem?
- Bandwagon: did you count "most people do it this way" as an argument?
- Confirmation: did you only look for arguments in favor of one option?
If you find any — adjust your conclusion.

This adds an explicit reflective layer on top of the axioms — especially useful for high-stakes decisions.

🔧 Technique: two agents with different axioms

If the decision is genuinely ambiguous, give two roles different sets of principles:

Role A (Engineer): principles — reliability, long-term maintainability, minimal tech debt.
Role B (Product): principles — speed to market, user value, iteration.

Role A analyzes the situation by its principles.
Role B analyzes by its own.
At the end — the points of disagreement and where a compromise is possible.

This turns the axioms into a tool for strategic conflict, not just a filter.

Paper title: Mitigating Prompt-Induced Cognitive Biases in General-Purpose AI for Software Engineering

Authors: Francesco Sovrano (ETH Zurich, Collegium Helveticum; University of Zurich; USI), Gabriele Dominici (USI), Alberto Bacchelli (University of Zurich)

Replication package: github.com/Francesco-Sovrano/GPAI-sensitivity-to-cognitive-bias-in-software-engineering

Key references: PROBE-SWE benchmark (Sovrano et al.), Furniturewala et al. on self-debiasing and implication prompting, Mohanani et al. on the taxonomy of biases in SE, DevGPT corpus (real developer conversations with ChatGPT)