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. What is herein is to suggest a solution to that dilemma.
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.
A DATABASE PRIMER:
What is a “database”, you ask? It is an electronic filing organization that provides entree point access to “External-Master Records” which in turn provide navigatable link chains to more “Internal-Detail Records”. It is a piece of electronic infrastructure contained on a serving computer. And just like a geographic infrastructure requires an accessibility map, so does a database.
A database “schema diagram” is a map of the external access to & internal connectivity between “record-types” within a database. Each record-type is represented by a big rounded rectangle, aka, box, in the database schema diagram. The external access to a record-type is represented by a small arrow headed by an oval pointing into the record-type. And internal connectivity between record-types via link chaining is represented by a line between rounded boxes, where the line may or may not be terminated with a directional arrow.
As a side note, think of a “record-type” as a single template or layout representing any number of records consisting of the same record format. If you wish, you can call a “record-type” a “record-template” . A “record” is defined as a fixed length string of data broken into contiguous fixed length “data fields”, with each “data field” consisting of a contiguous fixed length string of textual characters.
Also as a side note, “link chaining” is a method connecting records together wherein the first record is the master record that contains the address location of the first detail record, which contains the address location of the next detail record, and so on. An analogy would be the postman’s route beginning at the first house in a given block which contains the address of the next door house in the block, etc.
Here is an example of what a very elementary database schema map looks like in figure A.
FIGURE A.
So how do we interpret this diagram?
Looking at the very lowest box, it is a detail record-type subordinate to both of the upper two master record-types, because it participates in link chains from both of the upper two record-types as represented by the two lines connecting it to the two upper boxes. In such a master-detail relationship, there are generally many detail records per each master record.
The top 2 boxes are connected by a single link chain which is represented by the line between the 2 boxes, thus making the lower of the two boxes a detail record-type subordinate to the upper master record-type. Both of the upper two record-types are externally accessible via a unique key field as indicated by an arrow headed by an oval pointing into the box. The upper box does not participate as a detail in any link chain. Therefore, it is said to be an “external master” record-type. But the middle box is both externally accessible & participates as a detail in the link chain connecting it to the upper box. Therefore, it is said to be a “hybrid master” record-type.
So we can now see record-type accessibility, hence individual record accessibility, is accomplished in one of two ways:
1) externally via a unique key field, such records being called “external master” records, or
2) internally via link chains which are data fields within each record pointing from one record to the next, such records being called “internal detail” records. There can be any number of different link chain data fields within any record-type.
In addition, you should note that two of the link chains are terminated with a downward arrow to indicate a 1-way dead-end, which means the master record is not retrievable from any detail record in the link chain. You should also note that one link chain has no arrow indicated at either end of the line which means the master record is directly retrievable from any detail record or indirectly by traversing the link chain either way, downward or upward. In other words, it is a 2-way street.
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. But if you still feel uncomfortable with what you have read so far, you can skip to the last section entitled HOW TO READ THE DATABASE at the bottom of this post. We proceed from here to explain the detail workings of the database.
THE OVERALL ELECTION SYSTEM DATABASE:
Here in figure B is a schema diagram of what an overall National Election Database should look like. You should note at the top are numbered sectional identities.
FIGURE B.
(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.
