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 has not been made available by now is an absolute crime. So what would an online real time election system database look like?
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”. A database “schema diagram” is a map of the accessibility & connectivity of “record-types” contained within the database. Think of a “record-type” as a single template representing any number of records consisting of the same record format, a “record” being defined as a fixed length string of data broken into contiguous fixed length data fields, each data field consisting of a contiguous fixed length string of textual characters. Record-type 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.
3) A record-type that is accessible either way is a “hybrid master” record-type.
SECURING THE VOTE VIA AN ADMINISTRATOR MINI DATABASE:
Here are two versions, A & B, of the same Voter-ID section of the overall election system database shown in C. They represent two possible configurations of what could be called the basic administrators mini-database that appears within the far right side of the overall database, C.
This mini database provides a cross-reference system entirely necessary for use by administrators at those levels of government concerned with citizenship identification, specifically election administrators, social security administrators, medicare administrators, & US State Dept administrators. It provides the ability of these various government agencies to uniquely identify and maintain the identity of citizens as distinct from non-citizens.
A.
In version A, you can see two different record-types represented by the two big boxes with rounded corners, ie, an upper external master header record-type connected to a lower detail voter-id record-type. The header record-type is a single master record & externally accessible given its voter-id = 0. It is the “head” or “master” or beginning of a sorted link chain. Via the line connection from this single master record to the lower level detail voter-id records, this master record 0 allows access to the entire list of other voter-id records in voter-id number sorted order. You should note that additionally each individual voter-id record is externally accessible given its unique voter-id number. This makes the lower level record a “hybrid master”. So every detail voter-id record is a naked hybrid master record as well, because there is no indicated master to detail record-type indicated below it. Regardless, it should be clear that any given detail voter-id record is also directly accessible given its unique voter-id number and indirectly accessible by going through the sorted list of voter-id records.
B.
Every voter id record should be validated at least every 4 years by either the US State Dept, the Medicare Admin, or the Social Security Admin. As such, the voter-id record must also specify reference to a passport id, a medicare id or a social security id. Any one of these 3 federal departments should have the ability to flag the voter id record with a status flag, ie, active, dead, expired, etc. In addition to these data fields being included in the voter id record, the record should include an expiration/ renewal date.
Version B shows two connection lines that replace the single line in version A. This is two allow administrators at different levels to communicate, specifically between a more local election administrator & a more distant federal administrator who has access to citizenship records. The need for two link chains (as indicated by the two connecting lines) is to separate new voter-id requests initiated by a local administrator from those voter-ids that have already been validated by one of the 3 federal agencies.
“But”, you ask, “Why not use just one link chain between the two record-types & simply flag the voter-id record as new or approved?” Answer- Do you really want to go through Africa to get from LA to New York? I dont think so. Having two link chains expedites the feds job of identifying new voter-ids requiring their approval, where just one link chain would not queue them to look at specific records. In approving a voter-id record, all they need do is zero out the voter-id record’s new link field and plug in a new link in the approved link field. Furthermore, when an approved voter-id record becomes expired, it automatically goes back to the new voter-id chain from the approved voter-id chain.
THE OVERALL ELECTION SYSTEM DATABASE, C:
Here is a diagram of what an overall National Election Database should look like. Can you find the administrator mini database/ You will see a couple of other record types I’ve included below the basic structure.
C.
(Too small? On your phone, expand it. On your computer, right click and open image in new tab.)
So how does one read this diagram? (If you feel comfortable with what you have read so far, you can skip to the next section called THE ORGANIZATIONAL HIERARCHY.)
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.
THE ORGANIZATIONAL 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.
Clearly, the record-types in the left hand side of the database diagram illustrate this organizational hierarchy of our election systems. The hierarchy is structured as relational levels with 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. This leaves levels 1 & 0 representing the individual citizen level.
TYING PEOPLE TO THE ORGANIZATION &
RECORD ACCESS PERMISSIONS:
We note here that anybody can query any level in the organizational hierarchy of left hand side with read only permissions once that side of the database is created by the administrators. However, we remain left with the task of identifying those administrators in the first place.
The right hand side of the database diagram deals with the people record-types. 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 candidate/voter ballot requests to an administrator in the current or next level up.
At first, each citizen logon will be tagged with an accessibility level = 0 to indicate the citizen logon has no valid Voter-ID and will not have access to any record in 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.
We now ask who must have what to have or request update access to the appropriate portions of our organizational hierarchy in our election system database. Every federal, state, county, city, & precinct election administrator must be a citizen with a current and valid Voter-ID. Also, every candidate & voter must be a citizen with a Voter-ID. In other words, this system is by & for US citizens only, and they must prove their citizenship to an election administrator in order to get their Voter-ID recorded in the database.
This can be done by submitting their proof of citizenship in person or by submitting proof of citizenship to the online system via a candidate/ballot request. Proof of citizenship is a passport or medicare card, naturalization papers, and/or a birth certificate, along with a picture. Drivers licenses do not count.
HOW TO GET A VALID VOTER-ID FOR YOUR LOGON:
Depending on the level of the request, the appropriate administrator would be able to confirm whether or not the requester has a current Voter-ID. If the requester does, then all the administrator has to do is create candidate or ballot record linkable to the request. But If the requester does not have a valid current Voter-ID, then he must submit proof of citizenship in his request. With this information, the administrator must check to verify it is okay to assign a new Voter-ID to the requester and then create candidate or ballot records linkable to the request. It should be that simple.
Of course, not every body may have a cell phone or computer. In this case they must go into the county registrars office to apply. And if they can’t do that, then a ballot notary is required.
FEDERAL DATABASE RESIDENCY & ADMINISTRATIVE RESPONSIBILITIES:
The database would be maintained on a federal computer, where the feds might initialize Voter-ID records from a cleaned version of the State Department’s passport system allowing only citizen records to be used, non-citizen records being excluded. In addition, the feds would initialize the Nation and State ID records for each state , these being fixed entities. And for each State ID, the feds would create backdoor level-5 sign-ons with passwords to be used by the state for its administrative duties. This is reiterated in the following.
A CASCADING INITIALIZATION OF THE ORGANIZATIONAL HIERARCHY:
Original access will begin at the national level-6. For database initialization purposes, a backdoor administrator level-6 logon will be provided to create the National-ID record. And from this backdoor level-6 logon it will be possible to change any level-0 logon to another level-6 or level-5 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-6 administrator will create the State-ID records, along with creating a backdoor level-5 administrator logon for each state.
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.
EARLIER POSTS:
The Real Threat: https://www.aaarrrg.com/wordpress//?p=3161
The Virtual Precinct: https://www.aaarrrg.com/wordpress/?p=2632