In my last post, I said that we might be onto something, an idea for many of the benefits of universal automatic permanent voter registration, without the need for Federal-plus-50-states overhaul of policy, election law, and election technology that would be required for actual UAP VR. Here is a sketch of what that might be. I think it's interesting not because of being complex or clever -- which it is not -- but because it is sufficiently simple and simple-minded that it might feasibly be used by real election officials who don't have the luxury to spend money to make significant changes to their election administration systems. (By the way, if you're not into tales of information processing systems, feel free to skip to the punchline in the last paragraph.) Furthermore -- and this is critical -- this idea is simple enough that a proof of concept system could be put into place quite quickly and cheaply. And in election tech today, that's critical. To paraphrase the "show me" that we hear often: don't just tell me ideas for election tech improvements; show me something I can see, touch, and try, that shows that it would work in my current circumstances. With input from some election officials about what they'd need, and what that "show me" would be, here is the basic idea ...

The co-ordination of existing databases that A.G. Holder called for would actually be a new system, a "federated database" that does not try to coordinate every VR status change of every person, but instead enables a best-efforts distribution of advisory information from various government organizations, to participating election officials who work on those two important principles that I explained in my last post. This is not a clearing-house, not a records matching system, but just something that distributes info about events.

Before I explain what the events could be and how the sharing happens, let me bracket the issue of privacy. Of course all of this should be done in a privacy-protecting way with anonymized data, and of course that's possible. But whenever I say "a person with a DOB of X" or something like that, remember that I am really talking about some DOB that is one-way-hashed for privacy. Secondly, for the sake of simple explanation, I'm assuming that SSN and DOB can be used as a good-enough nearly-unique identifier for these purposes, but the scheme works pretty much the same with other choices of identifying information. (By the way, I say nearly-unique because it is not uncommon for a VR database to have two people with the same SSN because of data-entry typos, hand-writing issues, and so forth.)

To explain this system, I'll call it "Holder" both because of the A.G. and because I like the idea that everything in this system is a placeholder for possible VR changes, rather than anything authoratative. And because this is a Federal policy goal, I'll tell a story that involves Federal activity to share information with states -- and also because right now that's one of the sources of info that states don't actually have today!

Now, suppose that every time a Federal agency -- say the IRS or HHS -- did a transaction with a person, and that involved the person's address, that agency posts a notification into "Holder" that says that on date D, a person with SSN and DOB of X and Y claimed a current address of Z. This is just a statement of what the agency said the person said, and isn't trying to be a change-of-address. And it might, but needn't always, include an indication of what type of transaction occurred. The non-authoratative part is important. Suppose there's a record where the X and Y match a registered voter Claire Cornucopia of 1000 Chapel St., New Haven CT, but the address in not in CT. The notification might indicate a change of address, but it might be a mistake too. Just today I got mail from of government organization that had initially sent it to a friend of mine in another state. Stuff happens.

State VR operators could access "Holder" to examine this stream of notifications to find cases where it seems to be about a voter that is currently registered in that state, or isn't but possibly should be. If there is a notification that looks like a new address for an existing voter, then they can reach out to the voter -- for example, email, postal mail to the current address on file, postal mail to the possibly new address. In keeping with current U.S. practice:

• it is up the voter to maintain their voter record;
• election officials must update a record when a voter sends a change;
• without info from a voter, election officials can change a record only in specific ways authorized by state election law.

The point here is to make it easier for election officials to find out that a person might ought take some action, and to help that person do so. The helping part is a separate matter, including online voter services, but conceivably, this type of system would work (albeit with a lower participation rate) in system limited to postal mail to voters asking them to fill out a paper form and mail it back.

Next, let's imagine the scenarios that this system might enable, in terms of the kinds of outreach that a voter could receive, not limited to change of address as I described above.

1. "Hey, it looks like you changed your mailing address - does that mean that you changed your residence too? If so, here is how you should update your voter record …"
2. "Hey, it looks like you now live in the state of XX but aren't registered to vote - if so, here is what you should do to find out if you're eligible to vote … …"
3. "Hey, it looks like you just signed up for selective service - so you are probably eligible to vote too, and here is what you should do …"

Number 3 -- and other variations I am sure you can think of -- is especially important as a way to approximate the "automatic" part of A.G. Holder's policy recommendation, while number 1 is the "permanent" part, and number 2 is part of both.

With just a little trial-ballooning to date, I fairly confident that this "Holder" idea would complement existing VR database maintenace work, and has the potential to connect election officials with a larger number of people than they currently connect with. And I know for sure that this does not require election officials to change the existing way that they manage voter records. But how about technical feasibility, cost, and so on. Could it pass the "show me" test?

Absolutely, yes. We've done some preliminary work on this is, and it is the work of a few weeks to set up the federated database, and the demo systems that show how Federal and state organizations would interact with it. But I don't mean that it would be a sketchy demo. In fact, because the basic concept is so simple, it would be a nearly complete software implementation of the federated database and all the interactions with it. Hypothetically, if there were a Federal organization that would operate "Holder", and enough states that agreed that its interface met their needs for getting started, a real "Holder" system could be set up as quickly as that organization could amend a services agreement with one of its existing I.T. service provider organizations, and set up MOUs with other Federal agencies.

Which is of course, not exactly "quick" but the point is that the show-me demonstrates this the enabling technology exists in an immediately usable (and budgetable) form, to justify embarking on the other 99% of the work that is not technology work. Indeed, you almost have to have the tech part finished, before you can even consider the rest of it; an idea by itself will not do.

Lastly, is this reasonable or are we dreaming again? Well, let's charitably say that we are dreaming the same voting rights dream that A.G. Holder has, and we're here to say from the standpoint of election technology, that we could do the tech part nearly overnight, in a way that enables adoption that requires much administrative activity, but not legal or legislative activity. For techies, that's not much of a punchline, but for policy folks who want to "fix that" quickly, it may be a very pleasant surprise.

-- EJS