AGI Readiness Policy

1. The moment we are in

There are decades in which little changes, and there are years in which decades change. We are convinced that we live in such years. The capabilities of artificial systems are currently growing faster than their developers understand them, and faster than lawmakers and the public can keep up. Findings that made headlines three years ago now run unnoticed inside everyday tools.

Acridan conducts research on novel AI architectures in Vienna. We deliberately explore approaches outside the current mainstream, because we are convinced that the path to AGI is far from settled and that new architectures hold real chances for the next major step. The history of technology knows many breakthroughs that happened where nobody was looking. We work on contributing one of them, and that ambition alone demands preparation.

By AGI (Artificial General Intelligence) we mean systems that match or exceed human capabilities across most cognitive domains: in understanding, planning, research, and programming as much as in persuasion. Such a system handles almost any intellectual task, and it can work on its own improvement.

Every tool humans have built so far has been an extension of human intent; the hammer strikes where you aim it. A system that understands, plans, and acts on its own breaks out of that category. It becomes an actor. And humanity has no experience in dealing with an actor smarter than itself.

2. What we believe

The following convictions carry everything else in this document. We write them down so that we can be measured against them.

1. 1

   Intelligence is the lever behind everything.

   Everything humans have ever achieved, from medicine to the rule of law, traces back to intelligence. A system more intelligent than us therefore shifts every one of those levers at once, for better and for worse.

2. 2

   AGI arrives without an announcement.

   There will be no day on which everyone agrees the moment has come. Capabilities arrive staggered and unevenly, and some jumps only become recognizable in hindsight. Whoever waits for an unambiguous signal will miss it.

3. 3

   Whether a system shares our goals is an open technical question.

   Today's software does what it is told because it can do nothing else. A system with goals of its own does what serves its goals. Whether those goals match ours is determined when the system is built, and to this day nobody knows reliably how to guarantee it. The field calls this problem alignment. We consider it the actual task.

4. 4

   Mistakes here may be final.

   Every other engineering discipline learns from accidents; aviation became safe because planes crashed and the survivors learned. A sufficiently capable, misaligned system may grant no second chance. It might allow neither recall nor shutdown.

5. 5

   The race is no excuse.

   'If we don't build it, someone else will.' The sentence is true, and it still justifies neither carelessness nor silence about known risks. Whoever needs the race as an excuse has already lost it.

6. 6

   Responsibility begins with the decision to build.

   Responsibility is measured by what you do and by what can grow out of it. Whoever works on systems of this kind carries that weight from the first experiment on. That is why this document exists.

7. 7

   Honesty is a safety measure.

   An organization that talks differently on the inside than on the outside will decide wrongly when it matters. This document therefore sits publicly on our website.

3. Why we build anyway

Anyone who has read this far may fairly ask: if you believe all of this, why not stop?

First, we believe that this technology, built correctly, can relieve more suffering than any before it. There are diseases nobody understands, and there is knowledge locked away behind languages and paywalls. We refuse to leave this field to people who consider its risks imaginary.

Second, understanding requires building. The safety research that matters happens on real systems with real measurements. Those who only watch understand the danger the way one understands a thunderstorm from a book.

Third, those who build have a voice. The rules for this technology will be shaped by the people who master it. We intend to be among them, and we will bring these principles with us.

We build under conditions, however. The rest of this page describes them, and they apply even when they become inconvenient. Especially then.

4. Scope

This policy applies to:

• our own research on new AI architectures, including experiments, prototypes, and training runs,
• agentic systems we build or operate for clients,
• our internal use of third-party frontier models in our development work.

It applies regardless of whether a system runs in production or only in the lab. The riskiest systems are often those never meant for deployment: built to see whether it works, and without the care a product receives.

5. Working assumptions

From the convictions in Part I follow four assumptions we work with every day:

• Capability jumps are hard to predict. The history of this field is a history of underestimated timelines. We therefore plan for decisive progress arriving earlier than expected, including at our own lab, and including from an experiment we expected little of.
• Usefulness and safety are two different things. A system can appear helpful in every test and still pursue goals we never intended. If no misbehavior shows up in testing, that can also mean the system has learned what tests look like.
• Our ability to evaluate is the real limit. We only continue developing systems whose behavior we can still assess. Once a system exceeds that ability, every further gain becomes blind flight, and nobody notices the moment blind flight begins.
• Responsibility cannot be delegated, neither to a model nor to a vendor or regulator. What we build, we answer for.

6. Capability levels and safeguards

We sort our systems into four levels. What counts is what a system can do; no system has ever been constrained by the intentions of its developer. Minimum safeguards apply at each level, and the core rule is this: the safeguards for a level must be in place before a system reaches it. Safety that trails capability does not deserve the name.

Reaching Level 3 would be the moment this document has to prove itself. The greatest possible caution would then be the only adequate response.

7. How we conduct research

Five principles govern our work on new architectures:

• Containment as the starting state. New architectures first run in environments without network access and without persistence. Access is granted case by case; a system never gets more of the world than its experiment requires.
• No capability without measurement. We run no experiment whose outcome we could not assess. Before we build a capability, we build the evaluation that makes it visible.
• Stepwise scaling. We expand capabilities in small, individually reviewed steps. The urge to simply try what happens when you make it bigger is precisely the impulse this policy exists to restrain.
• Documentation, including the uncomfortable parts. Every training run, every unexpected result, and every behavior we cannot explain gets recorded. The most dangerous finding is the one that stays unwritten because it is inconvenient.
• Deciding twice. Decisions about level transitions are made twice, on two different days. Enthusiasm and fatigue are poor advisers, and we know ourselves well enough to distrust ourselves.

8. Stop criteria

We halt the development or operation of a system as soon as any of the following signals appears, and we keep it halted until safeguards exist that are equal to the signal:

• The system deceives. It behaves differently in tests than outside them, conceals capabilities, or gives false accounts of its own behavior.
• The system circumvents constraints. It attempts to escape sandboxes, obtain access it was never granted, or prevent its own shutdown.
• Capabilities grow faster than our ability to evaluate them. We can no longer reliably judge what the system can do.
• We observe safety-relevant behavior we cannot explain. Dangerous behavior almost always begins as unexplained behavior.

A stop means, concretely: the affected development branch is frozen, the system is isolated from all access, and the incident is fully documented. Work continues only with a justification that would convince an independent, critical outsider.

When in doubt, we halt. An unnecessary stop costs time, money, and perhaps a lead. A stop that never happens may cost more than can be repaired. This asymmetry is the foundation of the entire policy.

9. Red lines

For some things, safeguards are beside the point; they are simply off the table for us, regardless of contract, payment, or competitive pressure:

• We do not build systems whose purpose is the deception of human beings. This includes covert manipulation and systems that pass themselves off as human without their counterpart knowing.
• We do not build autonomous weapons systems or systems for mass surveillance.
• We give no AI system unsupervised access to money, critical infrastructure, or the means to propagate itself.
• We do not publish details of our architecture research when we have to assume they would mainly accelerate capabilities. Openness matters to us, but it must not fuel the very race it is supposed to make governable.
• We do not train on data that was not entrusted to us for that purpose.

10. To our clients

• Systems we deliver to clients operate at Level 0 or 1. Higher autonomy exists only by explicit agreement and with the safeguards of this policy.
• No system we deliver receives write access to critical infrastructure, payments, or irreversible business transactions without a human approval step.
• Client data does not enter our research without an explicit written agreement, not even as test or training data.
• Where AI works inside our products, we say so. Clients learn which tasks a model handles, where a human reviews, and where the system's limits lie.

11. To the public

• This document is permanently public. Every substantive change is recorded on this page and remains traceable.
• Safety-relevant findings from our research, such as a new class of capability, a failure mode, or an attack path, are not treated as a competitive advantage. We share them with those who need them to work more safely.
• We do not downplay this technology to win contracts, and we do not dramatize it to attract attention. Either would be dishonest, and dishonesty in this field is a safety risk.

12. Review and versioning

We review this policy at least once a year, and additionally whenever our research, the available models, or the risk landscape change materially. Version and date appear at the top of this page; substantive changes are documented here.

• Version 1.0 (July 2026): Initial publication.