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.
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.
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.
1. Transparency, including the legal limits.
Without published limits, people are blindsided as a matter of routine. Disability
benefit assessment is the clearest case I know: the decision arrives, the reasoning is not
shown, the criteria were never published in a form you could check, and the only route to
accountability is to challenge, wait, appeal, and wait again, sometimes for years, paying
with your own health and time. Responsibility that only arrives at a tribunal is
liability finally cornered. It corrects one case and leaves the structure that produced
it unchanged.
Publishing is only half of it, because a limit nobody enforces is decoration. An employer
can carry a disability-confident badge it largely awards itself, with nothing checking the
practice behind it, while disabled applicants are still filtered out before a human reads
the work. I have applied to those employers. A commitment with no audit, no consequence,
and no route of redress describes an institution’s self-image, not its conduct.
2. Failing is allowed. Failing quietly is not.
Eighteen months of applications across nearly every route into tech, met mostly with
silence or an automated filter before a human saw the work. A clear no with a reason costs
a system almost nothing and gives a person back their planning. No answer at all is not
neutral: it moves the cost onto whoever is waiting.
3. Measure what changed for the person.
Support is so often counted in sessions attended and applications submitted, and both
numbers can climb for months while nothing in a person’s situation moves. A system can
report excellent health while everyone inside it is stuck. And support aimed at a later
stage, while the person is stopped at an earlier one, is careful work on a step they never
reach.
4. Count the people it turned away.
When I stopped being able to continue, nothing recorded why, and nothing followed what
happened next. Disabled applicants get screened out early and quietly, which means the
population a service fails is exactly the population it cannot see. You cannot fix what you
do not count.
5. The system carries the context, not the person.
I have explained the same history to a new adviser, department, and form more times than I
can count, and kept my own records because theirs did not survive the handover. Records
split across systems that cannot talk to each other make the person the integration layer,
the most expensive place to put it.
6. Never require the thing you exist to provide.
I left university because the environment was not built for the way I learn and recover,
and the same pattern followed into work: burnout, health flare-ups, inaccessible spaces.
At one point severe burnout left me unable to work for nearly two years. Support that only
works for someone who can already sustain a full week asks for the capacity it was built
to restore.
The same shape turns up wherever an environment only makes room for people who can perform
an unwritten version of themselves: fit in, read the room, show the right personality. For
someone already close to their limit, that performance is the capacity. It may get them
through the door, but it has to be kept up every day, and when it slips, the failure lands
on the person at a higher price.
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.
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.