The standard behind everything I build

Software should never fail a person in silence.

Six musts a system has to meet before I will call it fit for purpose. The standard my practice is built on, and free for anyone to use.

Most software does not hurt people by crashing. It hurts them by carrying on quietly in a state it already knows is wrong, like taking payment for an application it has already judged invalid. Nobody is told. The person finds out weeks later, through the consequence. That is a design choice, and it can be made differently.

Where this came from

< I met these systems as a person first />

I did not pick this focus off a list of profitable specialties. I spent years inside public services, benefits processes, health records, and employment programs, as the person the system was supposedly for, and the same failure ran through all of them. Not rudeness, not incompetence, and rarely a crash. Silence.

The loop, as it actually runs

  • The system is split across departments that hold different pieces of the same person.
  • Context does not survive the boundary between them, so the person is asked to supply it again.
  • Something fails: a form, a transfer, a referral, a decision, a renewal.
  • The failure is never announced, because no step was ever made responsible for announcing it.
  • The person carries on assuming it worked, and finds out through the punishment: money gone, appointment missed, support stopped.
  • They become the investigator, calling each department in turn to piece together a system none of them can see whole.
  • They finally reach a person who believes them, who has no authority to change anything.
  • The individual case is patched. The cause is untouched. The next person meets the same loop.

Every link in that chain is a decision an engineer, an architect, or a procurement team either made or declined to make. That is the hopeful part: a system that fails this way was built to, and can be built otherwise.

That loop rarely runs on paper anymore. Eligibility rules, payments, referrals, deadlines, and the steps of legal processes all live in software now, and software inherits whatever the institution built into it, its gaps included. Once a rule becomes code, it stops being a decision somebody makes each time and becomes a default nobody sees, applied to every person, every time. That is why I treat these as engineering failures, not only policy ones.

I have written up the cases: a passport application GOV.UK knew was invalid at question three and still walked to a non-refundable payment, an NHS rollout that moved the forms onto a screen and changed nothing underneath, and the question they forced: when is a system not fit for purpose? The answer became ADR-011, an engineering decision I hold my own work to, and the six musts below are that decision in plain language.

The standard

< Six musts, and one underneath them />

These are absolutes, not aspirations. A system missing any one of them is not fit for purpose, whatever its dashboards, its speed, or its own procedures say. Every must is an obligation the institution owes the person, never a requirement placed on the person, and that distinction is the whole argument.

1. Transparency, including the legal limits

Every system has a boundary: what it accepts, who it covers, its legal duties, the criteria it judges people by, and how to challenge a decision. The institution publishes all of it early, in language a person can act on. A hidden limit or an unstated criterion is a trap, since nobody can meet a standard they are left to guess, and a limit nobody enforces is decoration. The test: can a person hold the institution to it without years and a tribunal?

2. Failing is allowed. Failing quietly is not

The system can conclude that it cannot help, say so, give the reason, and point onward. Refusal is a proper ending, not the absence of one. An early no with a reason beats indefinite processing, just as a clear error beats a request that dies ten services deep without naming the cause.

3. Measure what changed for the person

Activity counters are allowed, never alone: applications received, cases opened, and tickets closed are motion. The outcome is whether the person’s situation changed, and because it is harder to collect, it is the measure left out. It also means finding where the failure actually sits: polishing a later stage while the person is stuck at an earlier one is only motion.

4. Count the people it turned away

The system can say what happened, when, why, where it failed, and what came next, including for the people it could not serve. How many were screened out, and what became of them? A system that only reports its happy path cannot be evaluated, because everyone it failed is invisible to it.

5. The system carries the context, not the person

Records, history, and state belong to the system. When someone has to keep their own paper trail to stop a case falling apart, the system has outsourced its memory to the person least able to bear the cost. That is a defect, not diligence on their part.

6. Never require the thing you exist to provide

A service built to remove a barrier must not require a person to clear that same barrier to use it: an employment program that only works for people who can already manage a full week, or a support line that needs a phone call somebody cannot make. Alternatives and reduced friction are design obligations, not favors.

And underneath all six: hold less, protect it properly, show it back

Robustness and security are part of this, not a separate department. A system holds the least it needs, defends it as though the people in it cannot afford a breach (most cannot), and lets a person see and correct what is recorded about them. Data someone never agreed to, cannot see, and cannot fix is another silent failure waiting to happen.

Where a must genuinely cannot be met, the gap is written down as a known limitation, visible to everyone deciding whether to rely on the system, instead of left implicit for a person to discover the hard way.

Provenance

< Every one of these has years of my life behind it />

I am disabled and neurodivergent, and my route through education and work has been shaped far more by missing accommodation than by any limit on what I can build. I did not take these six musts from a textbook. Each one is a failure I lived through first and only later understood as architecture.

The layer that is always missing

Every one of these musts has already been written down somewhere: statutory duties, equality law, codes of practice, accessibility standards, charters, and whole programs built to help. Little of it changes what happens to a person, because the same layer is missing everywhere: the one that enforces the rule when it is broken, not years later, on appeal, for the one person who still had the health to fight.

Help that cannot be enforced is not help. Where an institution or a company treats a person’s health and rights as optional, a scheme built to support that person is a statement of intent they can decline at no cost. Enforcement falls to the person, paid for with the very time, health, and money the help existed to protect. The stronger the need, the less capacity there is to enforce, so the failure lands hardest on the people the system was built for.

In software that layer has a name: validation, the check at the boundary that runs before the damage, refuses the invalid state, and says out loud what it refused and why. A right with no enforcement and a rule with no validation fail the same way, for the same reason: somebody decided the check was optional, and moved the cost onto whoever had least power to refuse it.

This is why I build the enforcement layer rather than write about the principle. A guardrail that rejects a bad state at the boundary is the same idea as a duty somebody can actually be held to, expressed in the one medium where I can make it real.

The barrier has almost never been capability. It has been role structure, accommodation, and routes never designed with people like me in mind. That is why I treat clear systems as an accessibility feature, not a nicety: predictable behavior, loud failures, and context the system holds for you decide whether a person takes part or is quietly filtered out. I build the thing I needed and could not find.

It was never only me. Every person is born with skills, talents, and something to give, and a great many of them are filtered out before anyone sees what they can do, often by institutions whose mission they share and would gladly have helped build. The talent is everywhere. The routes in are not.

A person’s place in the world is theirs by birth, not by a stranger’s judgment on paper. When people are free to be themselves and to contribute, much of what looks like scarcity turns out to be a design choice, and design choices can change. That is the world this standard points toward, one system at a time.

The longer version of this is my note on perseverance →

Take it

< You do not need to hire me to use this />

I would rather this standard spread than stay mine: a standard about removing gatekeepers that only I could apply, for a fee, would be a gatekeeper of its own. If you build, buy, commission, or run software people depend on, here are seven questions to ask about it this week, no consultant needed.

Seven questions for something you already own

  • Where are our limits, criteria, and legal duties written down, and would a person find them before investing their time?
  • Which of our published commitments could somebody actually enforce against us, and what happens to us when we breach one?
  • Can this system say no, give a reason, and point somewhere else? What happens today when it cannot help?
  • Name one measure we hold of whether a user’s situation actually changed. Not a volume, an outcome.
  • How many people did we turn away last quarter, and can we say what happened to them?
  • Which parts of this only work because users keep their own records to compensate?
  • Does using this service require the very thing the service exists to provide?

If one of those lands badly, you have found real work worth doing, whether or not I am the one who does it.

The furthest I have taken this myself is the Social Resource Floor, an open blueprint for reaching the resources a person needs to survive on the basis of being human, not financial status. It is unpaid, long-term, and open to collaborators, built on the same argument as this page: the systems people’s lives run on should carry responsibility, not shed it. You can see it working in its Blueprint Explorer.

It is not a campaign to tear institutions down, and it does not pretend physical limits are imaginary. It targets institutional scarcity, where the resource and the capacity exist and only the route to them runs out. The floor adds redundancy, so the failure of one route never becomes the failure of the person. The aim is to need any one system less, not to swap one gatekeeper for another.