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. There is a legend down in the lower left corner.
FIGURE B.(Too small? On your phone, expand it. On your computer, right click and open image in new tab.)
The database can be seen as divided into four sections:
1. The left section represents the user logons & their online requests records for access & update permissions to the appropriate records in the database.
2. The middle-left hand side represents the administrator control section which provides the tools required for validating voter-ids, aka, approved system-user-ids, and setting up appropriate levels of update permissions for lower level logons.
3. The middle-right section represents the government’s organizational hierarchical levels from the top-down and associated election data.
4. The right section represents the linkages from a citizens’s request to:
a. a government office based upon his submission of a candidate requests, 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.
Section 1 – USER LOGONS:
The left-hand side of the database map represents that part of the database that contains all users’ (including all administrators’) logon records which identify all users. Anybody can create a user logon record with password, regardless of citizenship. In creating a logon, the user must submit his birth date & his full 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. For privacy reasons, access to any 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.
Even though a user or would-be administrator has created logon, it does not mean he has update-permission to any part of the database other than his own logon area. He will not have a voter-id, herein called an approved system-user-id. Without an approved system-user-id, any user is strictly limited to his logon section of the database & has no access to any other section of the database. It should be noted that drivers licenses & social security numbers in & by themselves are insufficient proof of citizenship, because such numbers are granted to citizens and non-citizens alike. Therefore, a method of separating the wheat from the chaff is required.
To gain update-permissions , the user must submit a one-time request to an administrator with proof of citizenship. His request record(s) will be stored underneath his logon. Each new request record will be linked into a new-request-queue to be accessed & processed by an administrator.
Upon submitting his first request to an administrator, a unique system-user-id record will be created using his birth date concatenated with the last 4 digits of his social security number assuming that combination does not already exist. The new system-user-id record will be flagged with a permissions-level status of 0 (meaning he has no update permissions) & placed in the new request chain for an administrator to validate his citizenship.
The first one-time request must include proof-of-citizenship which can be done in-person or online. Proof-of-citizenship includes the submission of a passport-id or medicare id number or a birth certificate or naturalization papers, plus a photo. If the user fails to qualify as a citizen, his newly created system-user-id will remain assigned to permissions-level = 0 , meaning he has no update=permission to the rest of the database. Otherwise, he will be given a higher permission-level depending upon the nature of his request. The permissions-level numbering is as follows: 1 = non-administrator, 2 = precinct administrator, 3 = city administrator, 4 = county administrator, 5 = state administrator, 6 = federal administrator. This, in effect, is how a voter-id is assigned. 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.
There are three types of a user requests, any of which can be the first one-time request. All requests subsequent to the first must be validated by the assigned permissions-level in the first one-time request record.
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.
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.
In the middle-left section of the database schema is the area which provides a unique system-user-id number to specifically identify each and every US citizen. In section1, we have spoken of how a user is qualified, or not, to gain update permissions to the database.
To recap, we note the following:
First, we note that the focus of this section is upon a “self assigning USER-ID” record, also called a “system-user-id” record.
Secondly, we note that “system-user-id” can be qualified by the assignment of an update-permissions-level number to separate non-citizens from citizens & regular citizens from administrators.
The permissions-level numbering is 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
What we have not talked about is what the administrators are able and unable to do, which is what this section 2 is really all about. So from here, we add the following.
Any given administrative level may create in section 3 the master id header records for the entities one level below it & provide that level with a single backdoor administrator logon. Therefore, the feds can create state-id records, the states can create county & district id records, and so on. However, any administrative level cannot alter any of the detail records added by the administrative levels above or below its own level.
When it comes to servicing a user request, the following applies. Any administrative level in any state can service any user’s request 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.
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.
We begin with the feds, because they are the keepers of the database & have ultimate authority regarding citizenship status. Federal administrator logons will include employees within the Federal Election Commission, the US State Dept, the Medicare Admin, or the Social Security Admin. These are necessary, because they will have first knowledge of changes in citizenship status.
In addition, the database would be initialized & maintained on a federal computer. Original access will begin with a single backdoor logon having permissions-level 6. This logon will be able to give level 6 permissions to other real user logons as previously discussed. All federal administrators must be proven citizens & have level 6 update permissions. if the feds wish to qualify their administrators, the can attach a letter code suffix to the permissions-level number.
The first level 6 logons will begin updating Section 3 of the database by creating the single National-ID record and any State-ID record as a detail record. As each State-ID record is created, a single backdoor level 5 logon to 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.)
And if the feds were really nice, they might even initialize system-user-id records 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.
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 he specified a combination of birth date and last 4 digits of social security number that conflicts with an existing system-user-id. Again, put an automatic notification 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?
In any case, after initializing the State-ID records, the feds should have nothing to do with updating records in section 3 less than their own permissions level & absolutely no records in 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 & put a notice in the state’s work list.
We now turn to the state administration level 5 processes. With respect to updating records in section 3, the following holds. In the same fashion as the feds created their State-IDs with a single backdoor administrative level 5 logon, so each state should do the same for the counties, and each county should do for its cities, and each city should do for its precincts. 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.
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:
The middle-right part of the database represents the governmental hierarchy. In the governance of our national elections, the smallest entity is a precinct within a zip code, which is within the governance of a city, which is within the governance of a county, which is within the governance of a state, which also governs congressional districts & is within the governance of the feds. This organizational level structure is reflected in the left side of the database diagram where each level is tagged with an update-accessibility level-indicator. The very top-level is the federal government which is tagged as update-accessibility level-6. Proceeding down through the levels, each lower level gets tagged with the next lower level indicator. As a consequence & as previously noted, 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. To be perfectly clear, this level indicator will be used to flag organizational administrative areas of the database & to grant update permissions of those administrative areas to those user logons indicating the same level indicator.
Section 4 – TYING USER LOGONS TO THE GOVERNMENT ORGANIZATION & ELECTION RECORDS:
The middle-right part of the database diagram deals with the people logon accessible record-types. As previously stated, any individual, regardless of their level, (federal, state, county, city, precinct or voter) should be able to create a logon in order to make an online voter-id/candidate/voter ballot requests. However, just because they have a logon does not mean they can access or update any other part of the right hand side of the database. Where it may be possible for a person to create multiple logons and create multiple requests, the database will contain administrator tools to help curtail any one single person from obtaining more than one means of having access to the right hand side of the database. Furthermore, upon creating their logon, it will be tagged with an accessibility level = 0 to indicate the logon has no valid Voter-ID and will not have access to any record in the right hand side of the database other than the logon & candidate/ballot request records.
With respect to the citizen logon level indicator, level-1 will indicate the citizen voter or candidate has a valid & current Voter-ID. Level-2 will indicate the citizen is a precinct only administrator. Level-3 will indicate a city only administrator. Level-4 will indicate a county & district administrator. Level-5 will indicate a state administrator. And level-6 will be a national or federal administrator. Administrators will have update accessibility to their own level and the next lower level, but only read accessibility to any other level above or below.
A CASCADING INITIALIZATION OF THE ORGANIZATIONAL HIERARCHY:
STATE RESPONSIBILITIES:
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.
COUNTY RESPONSIBILITIES:
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.
CITY RESPONSIBILITIES:
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.
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.
This brings us to the creation of a candidate-link record by the appropriate level administrator. And how do we determine that?
The office record should have a field that identifies its level.
CANDIDATE/BALLOT REQUESTS:
I have previous mentioned these record types before without being specific.
A CANDIDATE REQUEST will call out the specific Nation-ID, 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.