Whilst we may not be as young as we look, we feel we are fully au fait with the world of modern development practice. If you’re not deploying to live at least 100 times a day - at least - “you need to get out of the game, grandad”. Or so we’re told. Still, we have never been followers of fashion. Which is why Friday afternoon saw us shoving two years of long, hard work onto the public internet in one almighty push. Not a situation we would readily recommend to anyone. That said, if there’s one thing we have learnt over our many years, it’s how to usefully abstract model from data from code. Which meant, when the time finally arrived, our Jianhan hunkered down over the pipework, Librarian Jayne turned her attention to frantic button pressing and the whole thing went without a hitch. Not a single hitch. Well done us.
Reader, you will know that our old procedure model served us well. But it did not allow us to describe procedural possibilities with quite the precision required. The old model had typed routes. Given a procedural step being declared to have happened, routes into the ‘next’ step allowed us to state that that next thing was CAUSED to happen, ALLOWED to happen or PRECLUDED from happening. Which was all well and good but tended to fray at the edges when causality was distributed. As it so often is. Two cases in point:
We were able to say that the House of Commons agreeing to an approval motion for a made affirmative instrument ALLOWED that instrument to remain law. When what we actually wanted to state was that an instrument approved by the Commons ((AND being laid into the Lords AND being approved by the Lords) OR (NOT being laid into the Lords)) AND all approvals happening whilst the egg timer of approval had NOT exhausted its supply of sand, the instrument would be CAUSED to remain law.
We were also able to say that the Joint Committee on Statutory Instruments having considered an affirmative instrument, ALLOWED the approval motion to be moved. When what we actually wanted to say was that the JCSI having considered OR scrutiny reserved being dispensed with AND the instrument NOT being revoked AND an approval motion being extant AND the egg timer of approval NOT having run short of sand, the approval motion is ALLOWED be moved.
Which all pointed to a new and improved model, this time doing what computers tend to do best - logic. By the time we hit the CRaG treaty procedure, we had another problem on our hands. For reasons we’ve never pretended to understand, treaty procedure allows for a - theoretically - infinite number of loops through the Commons. Now, if you know as much about computers as we do, you’ll know that computers and infinite loops do not make for good bedfellows. And that, if you want to avoid such complications, it’s probably best if your computer can count. All of which led to our new and improved logical procedure model adopting new step types in the form of some very basic arithmetic. Should we ever meet the person who drafted CRaG we would not offer them so much as a drink.
We had known for some time that our existing model was lacking somewhat, but never quite found the time to take out our trusty procedural spanners and tighten its nuts. Then the 19th March 2020 happened and we all got sent home. Partly because the ensuing chaos opened up time and partly in a quest for company - Michael pines if he’s left alone for too long - Librarian Jayne and Michael took to Teams and remodelled and remapped everything. Which is why we now have a new model, new maps and new data.
So what marvellous new features should our reader expect from all this effort? Well, erm, none. Quite yet. We are not a feature factory. As us ex-R&D types like to explain to the recalcitrant managerial classes, when they’re presented with work for which they can’t quite discern any measurable output, this is an ‘enabler’. Of what, we’re not quite sure yet. But experience has taught us that user needs are emergent from materials. Which in the case of computers means time spent on data models and information management is never wasted. And in the case of all things HTTP means building to be generative.
In the meantime, both the statutory instrument and treaty websites will continue to operate as before. Our beloved twitter bots - made-n-laid and Tweaty Twacker will continue to inform their small but devoted audience of instruments laid before Parliament. But behind the scenes, our crack team of librarians get a new dashboard showing - for a given work package - what things are caused to happen, what things are allowed to happen, what things should not happen yet and what things should not happen now. That alongside a new - and at this stage slightly incomprehensible - visualisation. All of which come with a degree of precision previously impossible.
Still, you’d be quite correct in thinking this was a lot of effort for an audience comprised only of a handful of librarians. A crack team though they may be. Over time we’d like to roll out the procedure parsing code to a wider audience. Before we had the SI and treaty websites it was rather difficult for people both inside and outside Parliament to work out what HAD happened to an instrument. One would need to know which committees were likely to take an interest, when those committees were likely to meet, when and indeed where they were likely to publish reports. And that’s just the committee bit. The new websites solve the what HAS happened problem, but only that. To work out what WILL or MAY happen next, you’d need a working knowledge of legislation, standing orders, resolutions of the Houses and Erskine May. Which is a lot to know. With a logical model, logical maps and parsing code, our reader can safely set aside reams of documentation and let the computers take the strain. As can - one day soon, we hope - Members, clerks, lawyers, lobbyists, journalists and wider civic society. Lovely stuff.
Pleased though we are with Friday’s progress, there is plenty left to do. Week 3 saw us sketching out procedural plans for the future. Whilst not on the same scale as a complete remapping exercise, it should keep us busy for the considerable. Elsewhere, young Robert continues to prod pixels in a mission to make our work package visualisations not only extremely impressive, but also useful. That last bit being tricky.
In somewhat limited bill mapping news, this week saw Librarian Jayne and Michael combing through the Scottish Parliament’s standing orders and adding new citations to our legislative consent motion map. Which means our homework is now ready for marking. A second meeting with Scottish Parliament colleagues is pencilled in for next week.
Fans of remedial orders will be delighted to learn that we have now checked our made affirmative remedial order data against our made affirmative remedial order map and, quite miraculously, found nothing awry. Which means we are now map-complete on remedial orders. We’ve also tidied up the labelling which was an odd mix of remedial order, Remedial order and Remedial Order. And didn’t always include the word draft in places where it should have. It only remains to add proposed draft remedial orders to our legislation model and we’ll be ready to go live.
Paragraph 14 of Schedule 8 of the European Union (Withdrawal) Act 2018 sets out a duty toward Parliament whereby instruments that seek to amend or revoke subordinate legislation made under section 2(2) of the European Communities Act 1972, are subject to an additional procedure hurdle. Paragraph 14(6) of the same Act puts in place an escape valve, where the Minister concerned may bypass the published draft procedure and lay an SI immediately. To date, we’d always been quite convinced that the publishing of a draft - or the triggering of the escape valve - would always precede an affirmative instrument. Imagine our surprise then when an escape valve statement was made as part of a negative procedure. Both librarians and computational experts were quite gobsmacked. Acting on the instructions of JO Jane, we have now added the option for such a statement to appear in both our draft negative map and data and our made negative map and data. All in the course of a good day’s work.
Still on the subject of JO Jane, we were delighted to be joined on Friday morning by both her and - for a short spell - her dog. Having so very nearly finished up work on remedial orders, we wanted to return to our earlier sketch mapping delegated legislation types to delegated legislation procedures, double check our understanding and work out where we should go next. Jane was good enough to take out one of her many manuals which means our map now comes complete with the roman numeral SI types that fans of such things like to show off about. Thanks JO Jane.
A while back we set off on an undertaking to make the reference data in our Rush database into actual manageable reference data. Librarians Anna and Ayesha have been busy at the information management coalface, tidying assorted columns into a more reasonable shape. Computational expert James continues to pick up their tidyings and normalise data into new tables. This week we have brand new lists for surname types and titles - as applied across both Members and the alternative names of Members - sat in our column for testing. More lovely stuff.
Still in the Rush database, we’ve been exploring options for de-gendering our relationship types. At the moment we have relationships like ‘daughter of’, ‘son of’, ‘mother of’ and ‘father of’. Given we know the genders of the people at both ends of the relationships, splitting the actual relationships by gender feels slightly redundant. To this end, mappings have been compiled of proposed relationship types and their reciprocals. All of which was going well until we hit upon Major-General John Edward Bernard Seely being the great-great uncle of Bob Seely. Now this may not come as a surprise to our reader, but it certainly came as a surprise to us. At least according to the internet, the de-gendered term for an aunt or uncle is a pibling. Whether we can get away with calling Major-General John Edward Bernard Seely the great-great pibling of Bob Seely is most definitely what we like to call a ‘brarian question. Over to our A-list team of Anya, Ayesha and Anna.
