Safety and accessibility, in practice.
Safety and accessibility are part of how we build, not a separate step. This page says what that means in practice, so the people we build for know what to expect.
How we approach safety.
Where the conviction comes from
Toussaint Minett, our founder, spent seven years in Twitter’s Health organization, better known as Trust & Safety. As an engineer he built machine-learning systems for abuse and compliance, including a German hate-speech classifier for the NetzDG law. As a manager he led the Reporting, Appeals and User Notice teams. He also led the engineering work for the platform’s EU Digital Services Act readiness and its obligations under several national laws. Safety, he learned, is rarely a clever model. It’s plumbing, and it has to exist on day one. That means a report that reaches a person, an appeal that can be won, a notice that says what happened and why, and a record someone can check.
The standard every project is held to
Before a release, each of these has an answer, and the answer is written down:
- A way to report.
- A person can flag a thing, and the flag lands with a human.
- A way to appeal.
- Automated decisions can be contested, and appeals can be won.
- A way to be told.
- When we act on someone’s content, account or data, they’re told what and why.
- A threat model, written down.
- Abuse cases, misuse cases, and who gets hurt if we’re wrong.
- Clear about data.
- Say what we collect and why, and keep it only as long as we need it.
- A security review of the release.
- And dependencies that are kept current.
- A limit on what a model may miss.
- For any model that makes a decision about a person.
If you find something we’ve shipped that doesn’t meet this, write to us and we’ll tell you what happened. That’s the whole enforcement mechanism, and it only works if you use it.
None of this makes a product safe. It makes it possible to find out that it isn’t, and to fix it. We would rather be honest about that than sell certainty we don’t have.
How we approach accessibility.
Accessibility, in the narrow sense
We build to WCAG 2.2 AA. This site is tested against it on every release — automated checks in the browser plus keyboard and screen-reader passes by a person — and we fix what we find. Standards conformance is a direction we hold, not a certificate we’ve been issued. If something here doesn’t work for you, write to hello@m3tlabs.ai and we’ll fix it and tell you when it’s done.
Known limits: the 3D object has a text description for screen readers, given once, in one place. It holds still wherever reduced motion is set or a device can’t draw it live. Screenshots on the work pages carry text descriptions, but a screenshot is still a picture of an interface. Last reviewed 2026-09-12.
Accessibility, in the broad sense
Many people have never used an AI product, and many distrust the ones they’ve seen. We aim for products a newcomer can use without help. That means plain language, an obvious next step, a way to undo, and no assumption that anyone knows what a “model” or a “prompt” is.
What this looks like in the work
In LeagueCoin, low-confidence prices go to a human review desk instead of the market, and the tokens were kept off-chain while the regulation was unsettled. On this site, the 3D object becomes a still image when motion is off or a device can’t draw it. A standard only counts if it shows up in small details like these.
Questions about any of this go to a person.
Twitter and Groupon are named as former employers. Neither is affiliated with M3T Labs, and neither endorses it.