Paths forward

Directions worth considering.

Seven directions for a healthier development of AI — each with what it is good for, where it falls short, and a concrete example. Proposals to weigh, not a standard to meet.

Proposals Nothing to comply with Updated 2026-09-08
Our reading

Seven directions this project finds worth considering. They are proposals, not requirements — there is nothing here to comply with and nothing to obtain.

None of these is a solution. Each one helps with something, costs something, and fails in some situations — so each is given here with its limits attached rather than as a principle to adopt. A direction whose downsides you cannot name is not a direction you understand yet.

Where a genuine legal obligation applies to you, that is a separate matter and a real one: look it up in the actual text that governs your situation, not on a site like this one.

Path01

User autonomy

Building so that people can understand enough to disagree, adjust what the system does, and leave without losing their work. Autonomy is measured at the exit, not at the welcome screen.

Why it helps

Fewer trapped users, more honest competition, and a system whose flaws surface as feedback instead of resentment.

Its limits

Autonomy has a cost: more settings can mean more confusion, and defaults still decide what most people experience. "Give the user control" is sometimes a way of shifting responsibility onto them.

An example

Being able to export your history and prompts in a usable format — not a PDF dump — so that changing tools is a decision rather than a loss.

Path02

Useful transparency

Publishing what actually helps someone decide: what the system is for, what it was evaluated on, known failure modes, what data it keeps. Not a specification nobody reads.

Why it helps

Transparency that answers a real question lets users, researchers and regulators check claims rather than trust them.

Its limits

Disclosure can become theatre — long documents that satisfy a requirement and inform no one. And full transparency is not always available: we cannot simply read a model's reasoning, so some honest answers are "we don't know".

An example

A short, current page saying what a model is bad at, written for the person about to rely on it.

Path03

Data protection

Collecting less, keeping it for less time, being explicit about what is used for training, and making those answers easy to find for the specific product and plan someone is on.

Why it helps

It reduces the blast radius when something goes wrong — and something eventually goes wrong.

Its limits

Minimisation can conflict with usefulness: memory and personalisation need data. And a clear policy is not the same as a policy being followed, which users cannot verify from outside.

An example

A default where conversations are not used for training, with opting in as a deliberate choice rather than a buried setting.

Path04

Cooperation

Sharing evaluation methods, incident reports and safety findings across organisations that otherwise compete — because a failure mode found once should not need finding six times.

Why it helps

The whole field learns faster, and safety stops being a competitive disadvantage.

Its limits

Cooperation between large actors can shade into coordination that raises barriers for smaller ones. "Industry standards" written by incumbents tend to fit incumbents.

An example

Published evaluation methodology that an independent researcher can rerun and dispute.

Path05

Access

Keeping capable systems reachable across languages, budgets, abilities and regions — and keeping open, self-hostable options genuinely alive rather than nominally available.

Why it helps

It widens who gets to benefit and who gets to scrutinise, and it is the practical counterweight to concentration.

Its limits

Access has real costs someone pays, and wider access also widens misuse. Neither point settles the question; both belong in it.

An example

A capable open-weights model, documented and maintained well enough that a small team can actually run it — the maintenance being the hard part.

Path06

Assessing consequences

Before deployment and after: who could be harmed, how would we notice, what would we do about it. Proportionate to what is at stake, revisited when the use changes.

Why it helps

Most harm comes not from exotic scenarios but from ordinary systems used slightly outside what anyone considered.

Its limits

Assessment can become a checkbox that produces documents instead of changes. And it cannot enumerate what nobody imagined — no framework eliminates risk.

An example

A route for the people affected by a system to report that it went wrong, that reaches someone able to change it.

Path07

Proportionate responsibility

Scrutiny that scales with stakes. A drafting assistant and a system involved in a medical, legal or hiring decision should not face the same requirements.

Why it helps

It puts effort where consequences are, instead of spreading thin compliance evenly and protecting no one well.

Its limits

Everyone believes their own case is low-stakes. Proportionality needs an outside view, and drawing the line is genuinely contested.

An example

Human review that is real — someone with the time, information and authority to overrule the output, not a rubber stamp on a queue.

Turning any of this into something concrete

Directions are easy to agree with and hard to act on. The method describes one way of taking a rough intention and turning it into a structure you can actually check — objectives, constraints, risks and milestones written down before the work starts.

It is one working method among many, offered because it is the one used here — not because it is the right one.

The longer questions

← Back to ORÆ