Parliamentary procedure as process flow
For the past couple of years I've been working with librarians in the House of Commons to codify parliamentary procedure in a way that's legible to machines - or at least queryable by people using machines. We've designed and built an abstract model to capture procedural flows. This model defines a procedure as a set of routes through steps, the steps combined using logic gates.
The procedure model is not explicitly a model of parliamentary procedure. It contains none of the domain language or domain knowledge of Parliament and would not ring many bells in the minds of clerks. It is a general purpose process flow model, allowing us to say that this thing and this thing - or this thing but not this thing - having happened, this other thing is caused or allowed or precluded from happening.
The domain knowledge is captured as something between a flowchart and a state diagram, then encoded as instance data on top of the procedure model.
Mapping Parliament's processes
We work with clerks and with whiteboards, mostly asking "and then what happens?". Sometimes a thing happening causes another thing to happen, sometimes it allows a thing to happen and sometimes it precludes a thing from happening. Sometimes the logic is combinatorial: this AND this OR this but NOT this having happened, these other things are caused or allowed or precluded from happening.
Our procedure model defines a process as a set of routes - joining steps - some of which allow logical combinations to be described. Our maps are a visual representation of the data we add to capture this.
The Indexing and Data Management Section in the House of Commons Library maintains the procedure maps and the procedure data, as well as instance data for Statutory Instruments and Treaties subject to those procedures. We talk about business steps having happened, or being scheduled to happen. Concrete business steps are indexed against abstract procedural steps, by a process we call actualising.
Mapping any process
Having designed a model, the first thing you want to do is try it out and see what breaks. Having designed a model as abstract and general purpose as the procedure model, the first thing you want to do is throw other processes at it to see just how flexible and generic it actually is.
To that end, we did some work with Adam from the Food Standards Agency. We mapped out the process flows around the registration of premises as abattoirs or meat processing plants. We also spent time with Felisia and Ganesh at GDS looking at some of their step-by-step guides, transferring them to whiteboards and pondering whether we might be able to use something like the procedure model to describe them.
GOV.UK step-by-step guides apply a page-by-page pattern to information journeys, stepping out to transactional service en route. The guides are frequently cited as a success story, even winning a Design and Art Direction Wood Pencil, which is definitely more than any of my work's ever done. Whilst there is no underlying content data model, it is something that GOV.UK are working towards. For now, changes to policy or legislation are reflected in interfaces, but not in structure. There's no data for third parties to grab on to and fewer opportunities for syndication to other platforms.
Along with Felisia and Anya and Jayne and Ganesh and Silver, we took to whiteboards to deconstruct at least a little of them. That, though, was before the pandemic - when we still had rooms and whiteboards. These days we're reduced to pixels and shared Omnigraffle documents, but not deterred.
We've continued pulling apart step-by-step journeys and reimagining them as process flow diagrams with a scattering of logic. Although, parsing some of the sentence construction on GOV.UK has occasionally proved problematic. Maybe there's a reason why lawyers write how lawyers write.
Everything is interwingled
The first thing we pulled apart was the step-by-step guide to whether you can get married or enter into a civil partnership - at least in England and Wales. That process map is here. Having made the decision that getting married is actually something you want to do, found out you can and jumped in with both feet, new routes to new entitlements open up and other routes close. The most obvious new thing you can do once married is get divorced; marriage and civil partnerships also open up and close off avenues to other entitlements to benefits, which in turn open up other entitlements.
The service designers amongst us have long advocated a shift from individual siloed services to a suite of services centred around major life events. Whether that's marriage, childbirth, divorce, (un)employment, opening a business, retirement, illness or death. Without mapping out all the services and routing through common steps, there is no way at present to orientate users around such events.
Mapping out each guide and finding commonly used steps allows us to stitch together fragmented journeys, opening up opportunities for exponential effects across services. You should be able to navigate your way through the civil partnership guide and also find out about the consequential effects of entering into a civil partnership. Having met the criteria for entitlement to a service and taken up that option, that may confer entitlements to other services. Criteria become entitlements become criteria and on it goes. In this way, government services can be seen as cyclic and not as a linear journey. Without that underlying structure, it's hard to know how government services can be realigned to match real needs, let alone life events.
What are government services for?
A straightforward description of what government services aim to do is to identify those to whom tax-funded services should be delivered. Money is collected and redistributed in a way that matches political intent. Government hands out benefits - in the very widest sense - to a set of people, or at least legal entities, that match some criteria and possibly perform some duties.
A service delivered by government can be described as a set of conditions and criteria that must be met and a set of duties that must be performed in order to unlock those benefits. This criteria being met AND this duty being performed OR this other criteria being met, entitles the recipient to some benefit, or not. Matching criteria to outcomes is more process flow. Achieving a balance between expected outcomes and appropriate criteria is a large part of politics: that balance being encoded both by means of policy and in legislation.
Always cite sources
Citizen-facing services are the visible tip of an iceberg. Under the waterline are policy, codes of practice, guidance, rules and legislation.
Back in Parliament, we've been working on tying procedural steps and routes to the things that inform them. In the case of Parliament, this means rulings made by the Speaker, precedent, Standing Orders, Resolutions of the House and statute.
Citing statute is trivial, because providence gave us John Sheridan - and John Sheridan gave us legislation.gov.uk. Citing Standing Orders has always been trickier because the citation takes the form of a number in a list, the order of which changes over time. We've been collaborating with a team from Oxford University on making persistent identifiers for House of Commons public Standing Orders, so we're now able to link procedure routes to the underlying ruleset.
It's straightforward to imagine how government services might be described in a similar way. Every step, route, condition and entitlement is there for a reason. That reason will be published somewhere as policy, legislation, rules or guidance.
I've written before about my unease with some of the ‘government as a platform' thinking. There is a lot to be said for tidying away the detailed workings of the state. For someone who wants to open a cafe, knowing that this form has to be sent to this department and this form has to be posted to this office is unwanted friction. And yet, whilst this may be true if you just want to shop for things, obfuscating the mechanics of government may also serve to obfuscate democratic accountability.
A government department is not a warehouse serving a handful of supermarkets. It has a minister, it is answerable to Parliament and - by means of Parliament - to the electorate. It is fashionable to declare that this or that thing is not a snowflake. It is also often true - far too much time is spent reinventing the wrong wheels. Government departments however definitely fit the snowflake bill, and should not be swept under service design rugs.
By all means simplify citizen facing services and hide some of the details of how the state operates, but there should always be a 'view source' button. A properly informed society requires clear and accessible means by which people can see how services are used to drive adherence to duties - and why the criteria being imposed exist.
Taking the marriage and civil partnership guide as an example: I can use it to find out if I can enter into a civil partnership in England and Wales. If all I want is a "yes, no, maybe" answer, it's fine - but it doesn't tell me why. There is no link from the guide to the Marriage Act 1949, to the Civil Partnership Act 2004 or to the Marriage (Same Sex Couples) Act 2013.
Service design in this form is inherently conservative. Failing to expose the ruleset underpinning the service obscures any mechanism for change. If I'd visited a similar service in 2012 as part of a same-sex couple wanting to marry, I'd have been told no. Not why. Just no. Not how that might be changed. Just no. It's service design for passive consumers rather than for active citizens. Our friends in UX often talk of affordances, but a system that hides its seams and underlying ruleset offers no affordance for change.
Which leads neatly on to a final problem.
Put the maps where the domain knowledge is
Encounters with GDS people always uncover a great deal of domain knowledge around GOV.UK, associated services, how they're built, who they're aimed at and how their users use them … and a lack of domain knowledge around the legislation and policy that underpins them. I can't say for sure, but I'm fairly certain that GDS does not have a single librarian, let alone a law librarian. Which, when you're turning legislation into data and code is odd.
If I worked at GDS, I'd build a platform to manage process flow mapping and a means to publish those flows to the web, to users and to third party platforms. I'd push the process flow mapping back out to the departments where the domain knowledge lives and I'd have a team of information managers to spot common patterns and common steps and tie the whole thing together.
Is this "rules as code"?
Having typed to the end, I'm beginning to suspect this is not too dissimilar to "rules as code". A world where the people who write the legislation and the people who write the policy are also drawing out the process flow and capturing the logic. Not perhaps as code, but definitely as data.
"Rules as code" has always scared me slightly. I would much prefer to be judged by a jury made up of my peers, than by a machine running ifs, elses and loops. I've spent too long around software to begin to think that any of it is much good.
We do seem to be stuck with software and this definitely edges in that direction. Whilst the legislation might at present be unparseable to machines, it is clearly possible to parse the translation layer of process flow data. Is that good? I'm really not sure. But it's probably better than encapsulating policy and legislation into content blobs in a CMS.