Fitness for Purpose: Essential Properties for System Evaluation and User Outcomes

Context

The earlier decisions in this series each answer a narrow question: where a validation belongs, which layer owns an invariant, what a component is allowed to assume about the data reaching it. Each one is a local judgment about correctness at a boundary.

Sitting above them is a question those decisions do not answer on their own. A system can satisfy every local rule, run every component as designed, and still fail the person it exists for. A service can have a portal, a workflow, a set of criteria, a budget, and staff, and process a high volume of cases through all of it. None of that establishes that it is doing what it was built to do. A system existing is not the same thing as a system working.

The same gap appears in software. A workflow where submission succeeds, validation passes, assessment runs, and a decision is recorded has performed exactly as expected at every step. If the user reaches the end without the thing they came for, the system produced activity rather than an outcome. Dashboards showing requests processed, jobs completed, and uptime maintained describe the machinery, not the result.

Problem

Without a stated definition of fitness for purpose, evaluation defaults to whether the components ran. That default has three consequences.

It lets a system look healthy while its users experience failure, because the health signals measure throughput and the failure is in the outcome.

It hides architectural faults that produce no exception. A process that can only intervene once a condition is met, but exists to help create that condition, has a circular dependency: it waits for the event it was built to cause. Nothing crashes. The system is simply unable to transition into the state that success requires, and the loop repeats at the user's expense.

It moves the cost of failure onto whoever is least able to absorb it. When a system does not preserve context, retry cleanly, or explain its own state, the user starts keeping the records, tracking the case history, and reproducing the context the system dropped. They become the external state store, and none of that work appears in the system's metrics.

We need a fixed set of properties that are checked before a system is called fit for purpose, so that "the process ran" is never accepted as the answer.

Decision

Fitness for purpose is assessed against the properties below. They are treated as absolute musts: a system missing any one of them is recorded as not fit for purpose, regardless of its throughput, compliance posture, or uptime.

Must 1. Declared boundaries

Every system has a boundary: an API has supported inputs, a database has constraints, a service has capacity and scope. The boundary is published, and published early enough that a user can make decisions about their own time. A system that discovers its limits only after the user has invested months in it has hidden its own architecture.

Must 2. A reachable failure state

The system can conclude that it cannot help, say so, give the reason, and route onward. Refusal is a defined terminal state, not an absence of one. Early rejection with a clear reason is better system behavior than indefinite processing, in exactly the way a clear error from an API beats accepting a request, threading it through ten services, and failing without naming the cause.

Must 3. At least one outcome measure

Activity counters may exist, but never alone. There is at least one measure of whether the user's situation changed. Applications received, cases opened, appointments attended, and forms processed are activity. What changed for the person is the outcome, and outcome measures are harder to collect, which is precisely why they get omitted.

Must 4. Observability that includes the people it turned away

The system can answer what happened, when, why, how long it took, where the failure occurred, and what happened next. That last question extends to the users it could not serve: how many were identified as unsuitable, and what became of them. A system that can only report on its successful path cannot be evaluated, because the population that failed is invisible to it.

Must 5. The system owns its own state

Records, history, and context are held by the system. Where a person has to maintain their own audit log to keep a case coherent, the system has outsourced state management to the user, and that is recorded as a defect rather than as diligence on the user's part.

Must 6. No dependency on the capability the system provides

Participation must not require the thing the system exists to supply. A service intended to reduce a barrier must not require the user to overcome that same barrier in order to use it. This is the accessibility requirement stated structurally: alternatives and reduced friction are design obligations, not accommodations bolted on afterward.

Where a must cannot be satisfied, the gap is documented as a known limitation of the system rather than left implicit, so that it is visible to the people deciding whether to rely on it.

Alternatives Considered

Judge the system by operational health

Rejected.

Uptime, throughput, and error rates describe whether the machinery ran. They are necessary and they are not sufficient. A system can be operational, compliant, fully staffed, and processing thousands of cases while still not being fit for purpose, and operational health reports that state as success.

Judge the system by compliance with its own process

Rejected.

Conformance to the defined process only establishes that the process was followed. If the process itself contains a circular dependency or has no failure state, following it faithfully reproduces the fault every time, and the compliance record becomes evidence that nothing is wrong.

Treat refusal as a failure to be minimized

Rejected.

Optimizing against refusals pushes a system toward keeping people inside the process rather than resolving them out of it. That converts a defined failure state into an expensive failure path: the same conclusion, reached months later, after the user has paid for the delay. Saying no is a legitimate outcome. What matters is whether it is reached early and explained.

Measure outcomes only, and drop activity metrics

Rejected as impractical.

Outcome measures are slower, noisier, and sometimes only observable long after the system has finished its part. Activity metrics remain useful for diagnosing where a process stalls. The decision is that they never stand as the sole evidence of success, not that they are discarded.

Let the user compensate for the gaps

Rejected.

This is the default that occurs when no decision is made. It works, in the sense that the case still progresses, which is what makes it durable and hard to see. The cost is real and is paid in the user's time, attention, and capacity, and it is systematically absent from the system's own reporting.

Consequences

Positive

• Fitness has a definition that can be checked rather than argued, and the checks are the same for a software system and for a service.

• Failure modes that produce no exception, such as the circular dependency and the missing failure state, become findable, because the review asks which state transition is missing rather than whether an error was thrown.

• Work that users are silently doing on the system's behalf is reclassified as a defect in the system, which puts it in scope for repair.

• The musts double as an audit checklist, which is directly reusable in reliability and validation engagements.

Trade-offs

• Must 3 and Must 4 require instrumentation that most systems were not built to provide, and retrofitting outcome measurement is substantially more work than adding another activity counter.

• Must 4 asks for data about people who left the system, which is often the data least likely to have been retained.

• Publishing boundaries under Must 1 exposes limitations that an organization may prefer to leave unstated, so this must tends to meet the most resistance.

• A strict reading can classify a genuinely useful system as unfit over a single missing property. The mitigation is that the assessment names which must is unmet and what it costs, rather than issuing an overall pass or fail with no detail.

Evidence and Related Work

The reasoning behind this decision is set out at length in "When Is a System Not Fit for Purpose?", which works through the activity and outcome distinction, the circular dependency, the two shapes of failure state, and the user as the system's error handling layer.

Implementation Evidence

Enforcement at the shared boundary, in OpenSPP

The invariant work on OpenSPP is Must 5 applied to stored data. A rule guarded only in the form left every other write path free to store violating rows, which meant the system was not holding its own state correctly, and the cost surfaced downstream in computes and integrations. Enforcing at the write boundary and pairing the fix with a migration to repair existing rows is the system taking responsibility for its own consistency rather than leaving consumers to cope.

Boundary declaration, in the Social Resource Floor blueprint

The blueprint states plainly what exists and what does not: language-neutral contracts and a conformance suite that two independent runners agree on, and no running network, no governance body, and no funded pilot. That is Must 1 practiced on my own work. The conformance suite is Must 4 in the same project, since it makes the claim that the contracts are implementable testable rather than asserted, and the comparison was itself verified by forcing the two implementations to disagree.

Relationship to the Broader Engineering Approach

This series has been describing one principle at progressively wider scope.

The configuration validation decision places a guard between external input and execution, so invalid configuration cannot reach the running system.

The write boundary decision places a guard between every write path and stored state, so invalid data cannot reach the database.

This decision places a guard between the system and the claim that it works, so a system that produces activity without outcomes cannot pass as functioning.

Input → guarded before execution
Writes → guarded before storage
Purpose → checked before the system is declared fit