OUR COMPROMISED ELECTION SYSTEMS:

• With the influx of illegal migrants and in view of the wide spread fraud in the 2020 election, a great concern has arisen regarding the integrity of our national election system. Our current election system is a piece of crap. It is a hodgepodge of manual and batch systems ripe with fraud. That a secure online real time election system “database”  has not been made available by now is an absolute crime. What is presented herein is to suggest a solution to that dilemma.

A HIERARCHICAL DATABASE PRIMER:

• What is a “database”, you ask? It is an electronic filing organization that provides an externally accessible entree points to “Master/Parent Records” which in turn provide internally navigatable link chains to more “Nested Detail/Child Records”. It is a piece of electronic infrastructure contained on a serving computer. Today, there are all kinds of things called “databases”. But there is one in particular that is the grand daddy of them all, ie, the hierarchical database.
• The Meaning Of “Hierarchical”:
  • To understand the meaning of “hierarchical”, a good analogy would be the master directory folders on your computer or cell phone, where you probably have many nested detail sub folders under each master folder. The only difference between this analogy and a hierarchical database is we are not talking directory “folders”. We are talking “records” and their relationship to each other.
• The Jargon Back Then:.
  • Before the computer came along, a “record” was said to be any multi-page document contained within a physical folder which was stored in a “file cabinet”. There was no relationship between records other than their physical proximity to each other. If they were not stapled together, pages could get mixed up. With the advent of the computer, that all changed, and a more precise meaning was given to the terms “record” & “file”.
• And Now Fixed-Length Vs Variable-Length Records:
  • Today, a “record” is a single line (terminated by a carriage return) within a single “page” of a single “file”, all contained within a specific electronic folder. A record is made up of variable-length and/or fixed-length data fields. Obviously if it is comprised of only fixed length data fields, then the entire record is said to be a fixed length record. Otherwise, it must be a “variable length record” . For our purposes here, we will assume it to be a fixed length record.
• Record Types:
  • The record may or may not conform to a specific format, ie, a template that specifies data be arranged into fixed position, fixed length & contiguous “fields” within the record, and if it does, then it is said to be of a specific “record type”. If you wish, you can call a “record-type” a “record-template” . This concept of a “record-type” makes it possible to identify master-detail relationships between record types & eliminate the need for pages or files.
• Thus, the hierarchical database came into being as a multi-file entity & became the grand daddy of all databases. General Electric’s Integrated Data Store & IBM’s DL1 were two originating hierarchical databases. And now for the IMPORTANT PART.
  
  
• THE DATABASE SCHEMA DIAGRAM.
  • Here we have what is known as a “database schema diagram”. Simply put, it is a map of accessibility to records contained in a database.
    
  • This example shows 3 different record-types represented as boxes and their relationship to each other shown as lines connecting the boxes, representing link pointer chains. It should be intuitively clear that the bottom box represents a detail child record-type that is subordinate to the two higher boxes representing master record-types. The lines between boxes represent link pointers chains wherein 1) the master record points to the first detail record, which in turn points to the next sibling detail record, with the last sibling detail record pointing back to the master record or simply dropping dead, ie, the end of the chain. In addition, you can see little circles with squiggly arrows pointing at the two master record-types. These represent external access to the master record-types given a key field.
    
    Let us associate this diagram with a real application, say a Customers Order History. The top record would be the customers id record. The next box down would be his order header records ( note plural). And finally the last bottom record type would be the item records on that specific order. All customer order headers and all customer ordered items would be accessible to anyone knowing the customer number. And all items of a specific order would be accessible to anyone knowing the order number. It is all about record access.
    
    RECORD-TYPE READ-UPDATE PERMISSIONS:
  • But record-type access is only part of the story.  Equally important is the principle of full or partial record “update permissions” which is key to protecting the data within the database. It is one thing to only see data. It is quite another to be able to add, change or  delete data. A person’s logon should contain an indication of their level of update permissions. This is what separates administrators from non-administrators. And in our election system,  it is what separates citizens from non-citizens.
    
    Hopefully by now it is intuitively clear on how to read a database diagram.

#jmp1

THE OVERALL ELECTION SYSTEM DATABASE:

The above image is a schema diagram of what an overall National Election Database should look like. You should note at the top are numbered sectional identities. (Image too small? On your phone, expand it. On your computer, right click and open image in new tab. Or download & save it to resize.)

Key to understanding this map is the concept of “governance levels”. We all understand the divisions within our own government as being  federal, state, county, & city which represents the most geographically remote part of our government that includes the progressively nearer parts of our government. These we call the governance levels each of which can be uniquely identified by a single digit. 

And each governance level maintains its own records. When these records are all thrown into one big pile, we need to know who can do what with respect to altering these records. This necessitates the need for a way of identifying  who has the permission to update records at what governance level.  Because any one person should not have update permissions to records within more than one governance level, it should be sufficient to tag any one person’s update permissions with the digit assigned to the governance level. But sometimes, as in the case of the various levels within a state, a 2 digit suffix to the permission-level is required to identify the state.

In this election system, I have assigned  numbers to the governance permission-levels as follows:
0 = non-citizen
1 = citizen
2 = citizen precinct-admin
3 = citizen city-admin
4 = citizen county-admin
5 = citizen state-admin
6 = citizen federal-admin
This, in essence, identifies the basic workings of this online election system database.

All users will initially be assigned  a permissions-level = 0, meaning they have no update ability to any part of the database.  After that, any user who is qualified to vote, including any administrator,  must provide PROOF OF CITIZENSHIP,  which subsequently grants them a  user’s permissions-level higher than 0, meaning they have update ability to those parts of the database as specified by their permissions-level. 

 State governments should not be assigning a permissions-level higher than 0 simply based upon a DMV ID or social security number, because these are issued to citizens and non-citizens alike and are not proof of citizenship.  And absolutely no state should be issuing ballots in any form to anyone who has not submitted a validated citizen request.  Capisce?

The database diagram, ie, map, can be seen as divided into four sections:

1. The left section 1 represents all user logons (including non-citizens,  citizen voters, & citizen administrators)  & their online requests records for access & update permissions-level to the appropriate governance-level records in section 3 of the database. 

  2. The middle-left section 2  represents the administrator control area which provides the mechanism required for validating & identifying citizen logons as distinct from non-citizen logons, as well as identifying citizen logons as distinct from citizen administrator logons.

3. The middle-right section 3 represents the government’s organizational hierarchical levels, ie, governance levels, from the top-down and associated election data. 

4. The right section 4 represents the area where administrators create linkages from a citizens’s request to:
a. be linked to a government office as a candidate,   or
b. access a ballot based upon his submission of a ballot request.
These requests are serviced  by state election administrators who are basically online voter registrars. 

The following discusses in detail the workings of each section.

Section 1 – USER LOGONS & UPDATE PERMISSIONS:

This section 1 is the  left-hand side of the database map which represents the part of the database that contains all users’ (including all administrators’) logon records. Anybody can create a user logon record with password,  regardless of citizenship.  In creating a logon, the user must submit his birth date  &  the last four digits, if not all, of his social security tax-id number, the combination of which should uniquely identify his logon to any election administrator & remain relatively unchanged, even if he moves to a new state.  He should also include his zip-code which he should keep up-to-date at all times.

For privacy reasons, access to his user’s logon record is restricted to the individual user who owns the logon. This is to protect the user’s profile from being exposed, including his voting record.  Absolutely no one will have access to the user’s logon record & profile.  Any data needed by administrators will be plugged into the user’s subsequent request record(s) which will be accessed and updated by administrators. 

Even though a user has created a logon, it does not mean he has update-permissions to any part of the database other than his own logon area. Such update-permissions can only be obtained by submitting a first one-time request record along with proof of citizenship in the form of a picture plus a passport-id or medicare-id or birth-certificate or naturalization-papers. Such submission can be in-person or via online. 

Upon entry of the request into the database, a  self assigning SYSTEM-USER-ID record will be automatically created for his logon having a permissions-level = 0, meaning he has no update permissions.  His unique system-user-id will be formed from the combination of his birth date & last four digits of his social security number to become what might be called a preliminary “voter-id”. 

In conjunction with his first one-time request record, the request record will be linked into a federal or state administrator work-list file to notify administrators of the request. And upon approval of his proof of citizenship by an administrator, his permission-level will be appropriately set higher than 0, thereby granting him the update ability he requested. If the user fails to qualify as a citizen, his newly created  system-user-id will remain at permissions-level = 0 , meaning he has no update=permission to the  rest of the database.   Otherwise, he will be assigned a permissions-level number higher than 0.

There are three  types of  a user requests, any of which can be the first one-time request.
a) An ADMINISTRATORS PERMISSIONS REQUEST is simply a request to change ones logon permissions-level to be changed to higher than 1. 
b) A CANDIDATE REQUEST can be made by any permission-level greater than 0. It must specify the specific Nation-ID, State-ID, County/ District-ID,  City-ID & Office-ID  for which the user seeks to run.  The administrator processing the request must link the request  record to the appropriate year & office-id records.   
c) A BALLOT REQUEST can be made by any permission-level greater than 0. It is simply a request by a user to his lowest level of local election administration to create link chain from his request record to the candidate link records applicable to his geographic area for the year in question. Therefore, he must include his zip code in making the request. 

Each user request subsequent to the first request must be validated by the assigned permissions-level in his first one-time request record.  

Of course, not every body may have a cell phone or computer which is quite unlikely.  In this case they should be able to find a public internet terminal like a library or the county registrars office. In the absence of that, they should obtain a paper ballot, but only upon proof of citizenship which could include having a social security number or some other form of federal id that the user has in mind.

Section 2 – THE ADMINISTRATION CONTROL SECTION  FOR SECURING THE ELECTIONS. 

This section 2 is the middle-left section of the database schema & represents the area of the database which houses  the  externally accessible system-user-id records  created as described in section 1.

The following applies to this section.

a. Once a user’s  system-user-id record  is created by submitting his first one-time request, it will be impossible for another user to create a duplicate system-user-id  record.

b. The system-user-id  record will be qualified by the assignment of a permissions-level number to identify non-citizens from citizens & regular citizens from administrators.
The permissions-level numbering is as follows:
0 = non-citizen (no update permissions)
1 = citizen
2 = citizen precinct-admin
3 = citizen city-admin
4 = citizen county-admin
5 = citizen state-admin
6 = citizen federal-admin

c. The first creation of a system-user-id will assign a permissions-level = 0  & remain so until proof-of-citizenship is approved. 

d. State level administrator permission-levels 2 through 5 require a 2-character State-ID suffix appended  to restrict their update permissions  to the state in which they are qualified to serve. For example, we do not  want an administrator in Georgia making changes in Arizona.  For the rest of this document, we will assume that the permissions level for a state administrator includes that state suffix.

Any administrative level within a state can service any user’s request within the same state  for  a permissions-level change to 1. But any user’s request for a permissions-level greater than 1 must be serviced within the state & not by any administrative level higher than the permissions-level requested.  Any user’s request to be a candidate for office must be serviced within the state & not by any administrator other than an administrator at the same level as the office. Lastly, any user request for a ballot connection must be serviced within the state at the lowest level of administration available to user’s location.  

e. Federal administrator logons will be flagged as permissions-level 6 & include employees within the Federal Election Commission,  the US State Dept, the Medicare Admin, or the Social Security Admin. All federal administrators must be proven citizens  to have level 6 update permissions. if the feds wish to qualify their administrators permission-level, they can attach a 2 character code suffix to the permissions-level number. It should be noted that the Social Security or Medicare Administrations may invalidate a user’s permissions-level by submitting a record linked to the first one-time request record to indicate a deceased user. 

f. With the exception of initializing identity records below its level,  no administrative level can alter any of the detail records added by the administrative levels above or below its own level.

g. Looking at the database diagram you will note that the users system-user-id record can be linked to either of two header record types. One is a federal administrators work list which queues the feds to a system-user-id that requires attention. The other is the state administrators work list which is a list to queue the state a request requires their attention.  

h. Now turning to the feds work list, it is a file of notifications that queue the feds of items requiring their attention. A new user may have submitted a first one-time request using only a passport, medicare or social security number as proof of citizenship. Such a case should result in an automatic notification being put in the feds work list. Or maybe a user in creating their logon  specified a combination of birth date and last 4 digits of social security number that conflicts with an existing system-user-id. Again, an automatic notification should go in the feds work list.  And yet again, put an automatic notification in the feds work list when a system-user-id  is approaching  the 4-year permissions-level expiration date. Did you hear me say a “4-year permissions-level expiration date”? Yep, you heard right. We just cannot afford to let deceased citizens continue to vote. So why not automatically notify the fed of a possibly deceased voter? 

i. With respect to the state work-list, a work list  for each level of state government needs to be identified & accessed by its permissions-level level number and a combination of State-ID, County-ID, City-ID, & Precinct-ID to facilitate processing of user requests at the correct level.  

j. With respect to processing the previously mentioned requests, due diligence in validating citizenship & existing citizenship currency is of the utmost importance to  prevent any bad actors from trying to game the system & vote as a non-citizen or more than once in any election.

It should be noted that state governments should not be assigning a permissions-level of 1 based simply upon a DMV ID.  Nor should states be issuing ballots without a request from a qualified citizen system-user-id, ie, voter-id.

Paper ballots should be eliminated as much as possible. Ballots should only be given out  in electronic form  to people who have a qualified citizen system-user-id, ie, a voter-id.  

For the purpose of validating new first one-time requests,  any among the Federal State Dept, Social Security or Medicare Admin should be able to confirm citizenship in the absence of proof-of-citizenship documents. For the purpose of validating citizenship currency, the Social Security &/or Medicare Administrations should inactivate any voter-ids of dead people.

For the purpose of preventing bad actors from voting more than once in any given election every voter must issue a ballot request for every election. Validated voters should not have their ballots automatically setup, ie, issued, to them, because they may have moved to another state. This requirement for the voter to submit a ballot request every election year helps to prevent a voter from obtaining more than  one voter-id by changing his logon profile identity, because his previous requests will show his logon was used with another voter-id. However, women who marry should be able to change their name in their logon when they marry.

We must be able to deal with the voter who creates multiple logons. Where he might be able to present different birth dates, he should still be unable to submit more than one social security number in conjunction with the same birth date. And if he randomly picks those numbers, there is a good chance the combination already belongs to someone else

Section 3 – THE ORGANIZATIONAL HIERARCHY & GOVERNANCE LEVELS:

This section 3 is in middle-right part of the database map & represents the identities of our governmental hierarchical levels & their respective offices to be filled by elections.  It should be intuitively clear that within the nation are several states, & within states are several congressional districts and counties, & within counties are several cities, & within cities are several zip codes, & within zip codes are precincts. Excluding the zip-code level, each level is assigned an identity number. It should come as no surprise to see that our assignment of each level’s ID number corresponds to a user permission-level number.  But to be perfectly explicit, start at the national level as level 6 & proceeding down through the levels, each lower level gets tagged with the  next  lower level indicator. As a consequence, we have level 6 being the national level, level 5 the state level, level 4 the county & district level, level 3 the city level, level 2 the precinct level. And again, this leaves levels 1 & 0 representing the individual user logon.

a. GOVERNANCE LEVEL 6 INITIALIZATION: We now turn our attention to the initial establishment of this part of the database.   So we begin with the feds, because they are the keepers of the database, it being on their computer, & because they have ultimate authority regarding citizenship status. The very top master record is the Nation-ID record is assigned a level-ID = 6 & will be created by the feds via a single backdoor logon with permissions-level-6 . This single backdoor logon will be able to service any permissions-level 0 system-user-ids requesting  level 6 permissions as previously discussed, thereby creating more federal administrators. 

b. GOVERNANCE LEVEL 5 INITIALIZATION:
Before we continue any further, we must state this principle. In section 3 any given administrative level may create the master id header records for the entities one level below it’s own level  & provide that level with a single backdoor administrator logon.

Therefore, the feds can create State-ID hybrid master records as detail records to the overall Nation-ID master record, but nothing below those State-ID records. As each State-ID record is created, a single backdoor permissions-level 5 logon for each state will be provided to the lead state administrator for that state. ( Note:This is the one exception to assigning an administrative permissions-level lower than the processing administrator.)

In addition, if the feds are really nice, they might even initialize all system-user-id records setting each system-user-id to permission-level 0 or 1 , even before any real users create their logons. After all, they do have the information to do so, ie, birth date and social security number. But knowing the feds, we cannot count on it. And there really is no need until a user creates a logon.

After initializing the State-ID records,  the feds should not be creating or updating any other records in section 3  or section  4 of the database. They can only update the permissions-level in the user’s-system-id record in section 2 of the database & create, update or delete notice records in their own federal work list.

c. GOVERNANCE LEVEL 4 INITIALIZATION:
We now turn to the state administration level 5 processes with respect to initializing district and county updating records in section 3, the following holds.  In the same fashion as the feds setup the next lower level governance ids, each state’s backdoor level-5 logon will be able to change any level-0 logon to another level-5  administrator logon once the level 0 logon owner submits proof of citizenship either in person or via the logon online administrator request process. And the level-5 administrators will create the County-ID records & District-ID records, along with creating a backdoor level-4 administrator logon for each county. This same cascading process will apply to initializing the lower level  governance ids, ie, county, city & precinct ids.

In a similar fashion, each state’s backdoor level-5 logon will be able to change any level-0 logon to another level-5 or level-4 administrator logon once the level 0 logon owner submits proof of citizenship either in person or via the logon online candidate/ballot request process. Any level-5 administrator will create the County-ID records & District-ID records, along with creating a backdoor level-4 administrator logon for each county.

d. GOVERNANCE LEVEL 3 INITIALIZATION:
In a fashion similar to the state, each county would setup City-ID records, along with creating backdoor level-3 logons to be used by city administrators in conducting its elections.

e. GOVERNANCE LEVEL 2 INITIALIZATION:
In a fashion similar to the county, each city may elect to setup Precinct-ID records, along with creating backdoor level-2 logons to be used by the precinct administrators.

f. OFFICE/PROPOSITION RECORDS:
Obviously for each level of governance from city on up there exists departments & offices with positions to be filled, some of which are filled via elections. And so each level of government is responsible for defining those positions to be filled via election. These are the Office-ID records, and each year some or all of them may have vacancies to be filled by candidates.

Section 4 – TYING USER LOGONS TO THE GOVERNMENT ORGANIZATION & ELECTION RECORDS:

The right side of the database diagram deals with linking the user request record-types to the appropriate area of section 3 . Clearly before a voter can request a ballot, there must be candidates to select from.

This brings us to the creation of a candidate-link record by the appropriate level administrator. And how do we do that? 

A CANDIDATE REQUEST will call out the specific State-ID, County/ District-ID, & City-ID where applicable & the specific Office-ID. Assuming the would-be candidate is qualified & has a valid Voter-ID, the impacted administrator level will create a candidate link record for the year in question, thus establishing his candidacy.

It should be noted that there are times when there are non-candidate measures at the city, county, or state levels to be voted upon. These are identified as Propositions. They are identified in the same candidate link record-type which is accessible via the voter to the same candidate link record-type as used for candidate-to-office links.

A BALLOT REQUEST is simply a request to his lowest level of election administration to create links between his ballot request master & the candidate link records applicable to his geographic area.

VOTING:

The database is now ready for the voter to make his candidate selections by clicking the appropriate candidate-selection button in each appropriate voter-ballot-link record, at which time a write-permission lock is placed on the voter-ballot-link record. This would prevent anyone from changing candidate-selection button and the corresponding link to the selected candidate record.

POST VOTING RECORD ACCESS:

For secrecy/privacy purposes all cast voter-ballot-link records should be locked from updating by anyone other than the voter and as soon as they are counted. With this one exception, all should be able to view any record at any time, thus providing complete transparency and veracity of an election. In other words, everyone can look anywhere but not touch.

TALLYING UP THE TOTALS:

In addition, currency of vote tabulation is essential. As soon as a voter has locked his voter-ballot record, his vote should be counted and tallies by candidate should be made available. Washington DC should be connected to each state & have access to each state database for the purpose of rolling up ballot totals for each national candidate by state.

KEEPING THE VOTER-ID ROLLS CLEAN:

Currency of the voter rolls is essential and a responsibility of the feds. Voters who have died would have their Voter-ID record flagged as such. But aside from that, there are bad players who would try to vote more than once. This should be averted by looking out for duplicate Voter-ID and ballot requests in & across all states.

PROS:

What would be the advantages of an online real time election system?
First, the election should be completed within 2 days, if not sooner.
Second, the voter would cast his ballot directly into the database, thereby eliminating anybody other than the voter from touching his ballot.
Third, a voters ballot choices would remain unknown to anyone but the voter.
Fourth, since there is only one machine involved, auditing software should be comparatively, making it easy in identifying any other anomalies.

CONS:

There will always be some ding dong who insists on having a paper ballot which necessitates having a batch input system.

HOW TO READ THE DATABASE:

Let’s begin with an analogy in the form of a picture on paper representing an invoice containing a list of purchased items. The top line appears only once & contains information common to all items listed as purchased . The top line is the header, or “master” record. The items listed are “detail” records. Now consider a stack of invoices that all have the same format. They all have the same “master record-type” with the same “detail record-type”.

A database is an electronic file cabinet for all these invoice “record-types”. To be more specific in electronic terms, a “record” is a fixed length string of data broken into “data-fields”, all representing something or having some particular meaning, and a “record-type” is the representation of the collection of all records having a common fixed data content, format & key sort field different from all other records. To look a record-type is the same as looking at the format of a specific record. A record-type is a template or example of what a record looks like. (Note: the word “record-type” is used interchangeably with the word “record”).

Returning to the database diagram, each box represents a “record-type”. You will see boxes around the periphery that have a little short arrow pointing at the box headed by an ellispse, a square or an “x” . These are “External Master Record-Types” which are the basic entree points into the database via their unique id data-fields. The ellispe heading on the arrow means read accessible to all. The square means update accessible to administrators only. The “X” is exclusive to the citizen logon.

You will see that the nation record-type (of which there there is only one for the USA) is directly read accessible by anyone based upon its nation ID. You will also see that each state record-type is directly read accessible by all based upon its unique state ID. The same holds true for the election year and zip code record-types. Another external access point is via each individual citizen’s exclusive login point. Finally, there are three other administrative access points necessary for validating citizen requests.

Outside of the External Master Record-Types, all other record-types are Internal-Detail-Record-Types accessible only through “Link Chaining” which is shown by a link chain line connecting a higher level master box to a lower level detail box. You might notice that each state record is not only accessible as an external master record, but is also accessible via the “Link Chain” from the nation record. By “Link Chaining” I mean there is a link field in each master record-type that points to the first record within a detail record-type, which in turn has a link field that points to the next record within the same record-type, and so on until the last record of that record-type which may or may not point back to the original master records. Note that an internal detail record-type in one link chain can be a master record-type in another chain. Hence, a completely accessible hierarchy is achieved.

Referring to the database diagram, with respect to link chain traversal, the default direction of link chain traversal is always forward from master to the first detail record and from current detail record to the next. if there is no arrow pointing to a detail record-type, it means that the master record is retrievable from any detail record by continuing to traverse the chain to the last detail record which contains the link back to the original master record. However, if there is an arrow pointing to the detail record type, it means the last record in the chain has its next record link null, thereby making it impossible to retrieve the master record of the chain.

To complete the picture, given a nation id of USA, one could directly access the USA record & then traverse the state chain to access all the states within the USA. Similarly, one could access all the counties within a state by first accessing the state record & then traversing the county chain. And so on.

Today’s average browser-to-website user should not find this method of navigation too difficult to understand.