The 15 Principles of Good Public Services

Why Good Services Matters More With Agents

Agents amplify both quality and harm. If the underlying service is coherent, evidence-linked, and owned, they can make it easier to keep standards current, surface failures quickly, and route work across channels consistently. If the underlying service is weak, they accelerate the wrong thing: faster dead ends, more confident misinformation, smoother exclusions, and prettier versions of organizational confusion. Public service cannot afford that trade.

The Fernwood planning case made this concrete. Residents were not mainly asking for a prettier website. They wanted to know whether they needed permission, what documents were required, how long the route would take, what changed if the council asked for amendments, and why a decision had been made. The old service was legal enough to function, but not clear enough to trust. That distinction matters. A lawful service can still be a bad service.

Good Services gives the practice a bar that is human, operational, and politically grounded at the same time. Easy to find. Explains purpose. Sets expectations. Completes the outcome. Familiar. No prior knowledge required. Agnostic of organizational structure. Minimum possible steps. Consistent. No dead ends. Usable by everyone equally. Responds to change quickly. Explains why decisions are made. Easy to get human assistance. Requires the right knowledge from the user. I like this list because none of it is decorative. Every principle forces a service team to reveal whether it has designed the whole service or only one channel.

ASD's contribution is not to replace the principles with a machine rubric. It is to make the principles operational enough that the machine can help enforce them. Principle 13, for example, does not become “write better copy.” It becomes a demand for a decision-explainer artifact, comprehension testing, and an owner who can remediate weak explanations. Principle 14 does not become “show a phone number somewhere.” It becomes a cross-channel requirement that human assistance is visible and joined to the same service state. That translation is where the work gets serious.

The Fifteen Principles as Checks

Fernwood treated each principle as a measurable property rather than an aspiration. That is the pattern I recommend everywhere in public service. Start with the principle. Translate it into one observable test in plain service language. Require evidence before a pass score. Link the principle row to the artifact that proves the response exists. Name the owner who can fix a failure. Then make the gate fail when evidence or ownership disappears. Principle, checklist, evidence, artifact, gate. That chain is what prevents public-service standards from turning into poster rhetoric.

The principles also work well as a portfolio language because they cut across channels and departments. A team that scores only the web form will miss the call-centre script, the PDF letter, the assisted-digital route, the committee decision note, and the backlog rule that silently reintroduces the same burden next month. By forcing an artifact link and an owner per principle, the audit keeps the conversation whole-service. That is especially important in government, where a resident experiences one service while the organization experiences five directorates and three systems.

{
  "principle_id": "P13",
  "principle": "Explains why decisions are made",
  "observable_test": "A refused applicant can explain the decision, evidence, and next step in plain language.",
  "evidence_ref": "quote:resident-test-08",
  "artifact_ref": "decision-explainer-template",
  "owner": "planning_service_owner",
  "gate_status": "pass"
}

That table is intentionally blunt. It lets a team challenge weak claims immediately. “We improved findability” means nothing unless you can point to the search path and the task-success evidence. “We made it more inclusive” means nothing unless the assisted-digital route can complete the same outcome with the same underlying case state. “We explain decisions” means nothing unless users can actually explain them back.

One practical benefit of this translation is that it gives multidisciplinary teams a shared argument surface. Content designers, policy leads, accessibility specialists, service owners, and engineers can disagree over one observable test instead of arguing from separate abstractions. That is a healthier conflict. It turns “this feels clearer” into “can a resident actually complete the route, explain the decision, and recover from failure?” Good public-service standards become stronger when the disagreement is forced down to evidence.

name: planning-service-standard-gate
checks:
  - principles-register-complete
  - accessibility-ci-pass
  - unhappy-paths-covered
  - decision-explainer-present-where-needed
  - missing-owner-for-principle-regression
fail_on:
  - unsupported-pass-score
  - inaccessible-core-task
  - cross-channel-parity-gap

Once the principles are expressed this way, the machine can do useful work without pretending to own public judgment. It can check whether the row exists, whether evidence is present, whether owners are named, whether unhappy paths are covered, whether accessibility CI passed, whether an unsupported pass score slipped in. What it cannot do alone is decide whether the service is politically just, proportionate, or trustworthy in a context where law, democratic accountability, and lived vulnerability collide. That remains human work, as it should.

Running good-services-audit

The platform ships good-services-audit as a measurement-phase method, and it also carries a more explicit sibling called good-services-audit-15. For most teams the important point is the same: the audit is not a mood board. It consumes a live or shipped service blueprint or journey map plus post-launch feedback or support logs, then emits an insight-set that the Critic must review before it can become final. The runtime contract is intentionally tight. At least three nodes. At least one evidence reference per node. The theme field must be non-empty. Anything weaker stays draft.

Teams often assume the audit belongs at the end of delivery, as if Good Services were a compliance stamp. Fernwood shows why that is too late. The most useful moment to run the audit is whenever a service definition, prototype, or standards pack could still be reshaped cheaply. In practice I use it in three modes. Early, as a baseline that exposes structural gaps. Midstream, as a design gate that blocks decorative progress. Late, as a governance instrument that proves whether the live service is actually honoring the bar it claims.

That three-mode use is one reason the sibling methods coexist sensibly. good-services-audit is the general measurement instrument in the shipped library. good-services-audit-15 is the more explicit fifteen-principle variant when the scorecard itself needs to be the direct working artifact. I would rather have both than force one method to pretend every public-service context is identical.

asd method-run --projectId fernwood --methodId good-services-audit
asd artifact-write --projectId fernwood --kind insight-set --file audits/good-services-audit.json
asd review --projectId fernwood --artifactId audit-015 --verdict pass --rows reviews/good-services-pass.json
sd_factcheck fernwood

I like this method because it keeps public-service quality from floating away from the operational record. The audit can start with a principles scorecard, but it has to end with evidence-cited findings that someone can act on. If Principle 10 fails, where is the dead end? Which screen, letter, or phone transfer created it? If Principle 15 fails, what internal knowledge is the resident being asked to supply? If Principle 12 is partial, which change route is still breaking? Those questions drive the artifact toward service repair instead of ceremonial scoring.

theme: decision-explanation
principle_id: P13
severity: high
evidence_refs:
  - quote:resident-test-08
  - document:decision-letter-v2
finding: Residents can repeat the decision outcome but not the reason chain or appeal route.
recommended_artifact: decision-explainer-template
owner: planning_service_owner

The output being an insight-set is a smart choice. It means the audit does not pretend to be the final fix. It surfaces where the service violates the bar, cites evidence, and hands structured insight back to the practice. Mapper, Presenter, or Orchestrator can then turn those findings into blueprint changes, standards updates, backlog items, or a governance intervention. The audit is a measuring instrument, not a decorative certificate.

The human checkpoint is equally important. Before the audit runs, the designer confirms scope, inputs, consent, and intended decision. Before handoff, the designer approves the evidence-backed findings and their open gaps. That is what keeps the method from drifting into automated scorekeeping detached from public consequences. Measurement is still design, not clerical work.

Case: Fernwood Council Phase 2

Fernwood's second-phase planning work is one of the clearest demonstrations in the book because it treats the fifteen principles as a live operating standard. The council did not simply list the principles in a deck. It translated each one into a row in a standards register with a test, evidence requirement, artifact link, owner, and merge gate. Then it redesigned the citizen account and planning route so those rows could actually pass.

Principle 3, “sets expectations,” became a requirement that the start page show route, drawings, fees, consultation, and end-to-end stages before the resident committed. Principle 13, “explains why decisions are made,” became a four-part explanation template tested with refused and conditioned applicants. Principle 14, “easy to get human assistance,” became a structural rule that phone and in-person advisers worked in the same draft and timeline as the digital route. That is the move I want every public-service team to copy. Translate principle language into service mechanics.

That last row is especially instructive. Fernwood did not claim perfection. Principle 12 remained partial because full cross-service propagation into council tax and waste was still on the roadmap. I trust that kind of scorecard more than a wall of passes. Public services earn legitimacy when they are explicit about what has improved, what is still partial, and what evidence would be required to claim more.

The before-and-after audit made the improvement visible without flattening it into one vanity number. Before redesign, the planning service was strong on statutory completion and weak on findability, expectation-setting, decision explanation, assisted digital, and right-knowledge burden. After redesign, the new planning route could credibly pass most principles because the artifacts, tests, and owners existed. Residents could find the service more easily. Decision explanations became understandable. Progress checks per case fell. Complaint pressure eased. None of that required mystical AI. It required disciplined service design with machine-checkable gates.

Fernwood phase 2 is also a reminder that the principle bar applies to governance as well as interface copy. The planning committee chair, digital lead, and service owner all needed the same scorecard language so design, policy, and delivery could argue over one thing. That is why the standards register mattered so much. It gave the organization one public-service quality grammar instead of several competing interpretations of “good enough.” Once that grammar existed, GitHub issues, PR gates, accessibility checks, and decision-explainer reviews all pointed at the same standard rather than inventing their own.

The result was a service that became easier to govern because it became easier to inspect. Residents could find the route more easily. Officers could see which principle a change was meant to improve. The service owner could challenge a pass score that lacked evidence. And the design team could show why a partial remained partial instead of hiding behind optimism. That is exactly what machine-checkable quality should do in public service: make accountability more discussable.

Fernwood phase 2 also shows how the public-service standard interacts with ASD's wider loop. The evidence register grounded the claims. The standards register made the principles operational. The good-services audit surfaced remaining gaps. The Critic stopped unsupported pass scores. sd_factcheck forced integrity, acceptance, and review to agree before a human gate. In other words, the principles were not bolted on after delivery. They were woven into the method spine.

That is why this chapter matters beyond local government. Any organization delivering high-stakes, low-choice, multi-channel services can borrow the pattern. Take the fifteen principles. Write the observable tests. Require evidence before pass. Link the row to an artifact. Name the owner. Gate the merge. Then audit again after the prototype glow fades. Good services are good when the service can survive that audit repeatedly, across channels, owners, and political pressure. That is how a principle becomes a public operating standard instead of a slogan on the wall. It is also how design earns a durable seat in governance. Public trust gets a stronger operating basis.