Home · Approach
How we work“Responsible” has to mean something checkable.
Almost every technology organisation now says it builds responsibly. The word has been used often enough, and loosely enough, that it no longer carries information on its own. This page says what we mean by it in terms specific enough to be wrong.
A guarantee you can verify beats a guarantee you must trust.
Most responsibility claims in software are promissory: the system could do the harmful thing, and the organisation undertakes not to. That undertaking depends on the organisation continuing to exist, continuing to be owned by the same people, and continuing to mean it. All three change.
We prefer properties that hold structurally — where the harmful thing is not prevented by policy but is absent from the design. A dictation tool that makes no network call in the dictation path cannot send your voice to a server, regardless of what its privacy policy says, who buys the company, or what the terms become next year. The user does not have to trust anyone; they can read the source and watch their own network interface.
This is not always achievable. When it is not, the honest move is to say which parts rest on trust rather than to blur the two together.
Stating what a system cannot do is what gives its other claims value.
A capability list with no boundary is marketing. We publish, on the same page and with the same prominence, what each system is not good for and who should not use it.
In YazSes, 74 of 141 documented capabilities are wired; the other 67 are publicly marked “planned” rather than described as though they already worked. The project page states plainly that it is not an AI agent, does not handle non-English well out of the box, and may lose to a cloud service on a noisy microphone.
This costs something. A page that lists its own weaknesses converts worse than one that does not. It is worth it because the alternative — discovering the limitation yourself, after installing — is how software loses users permanently, and how a small lab loses the only asset it has.
If a claim cannot be independently checked, we do not make it.
Every factual claim on this site should be traceable by a reader who does not trust us. In practice that means work is released as open source, with published tests, versioned packages on public registries, and archived releases carrying permanent identifiers that resolve whether or not this website still exists.
- Open source — the implementation is readable, so a privacy or safety claim about the architecture can be confirmed rather than believed.
- Published tests — a stated behaviour has an executable check behind it.
- Permanent identifiers — archived releases have a DOI, so a citation still resolves years later.
- Numbers with a source — a figure on this site comes from a file or a public registry we can point at, or it does not appear.
Automated systems should inform a decision, not quietly replace the person making it.
We work on systems that detect, document and flag — and then hand to a person. In domains where the underlying science is genuinely uncertain, an automated pass/fail verdict manufactures a confidence the evidence does not support, and it moves responsibility from someone accountable to something that cannot be.
The design consequence is concrete: prefer risk signals, event logs and reviewable records over automated judgments; make the reasoning inspectable; and make the system useful for improvement rather than for blame, because a monitoring tool that is experienced as an accusation gets switched off.
What this lab is, precisely.
Responsible Systems Lab is a small, independent, early-stage interdisciplinary project group. It is not a registered company, nonprofit, foundation or public institution, it employs no one, and it does not sell anything. We say this in plain terms because the alternative — a website whose tone implies an organisation that does not exist — would fail the first principle on this page.
Projects developed within the lab are independent open-source works. Their copyright and licences rest with their authors and contributors, not with the lab.
What that scale buys is the ability to choose problems on merit rather than on market size, and to say no to work we cannot finish. What it costs is throughput. We would rather ship and maintain a few useful things than announce a dozen — and the things we have not shipped are named as such, on the projects page, rather than described as though they already worked.
Disagree with any of this?
We would rather hear it. We welcome collaboration, advisors, and partners across responsible AI, sensing, verification, and human-centered design — and criticism of the reasoning above.
Get in touch