OLD POST: REPLACED BY
https://www.aaarrrg.com/wordpress/?p=3984
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 right section represents the user logons & their online requests records for access & update permissions to the appropriate records in the database.
2. The left hand side represents the administrator mini database which provides the tools required for validating logons, assigning voter-ids and setting up appropriate levels of update permissions for lower level logons.
3. The middle-left section represents the government’s organizational hierarchical levels from the top-down and associated election data.
4. The middle 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 right-hand side of the database map represents the user logon & identity part of the database & any requests they make. For privacy reasons, access to this section is restricted to the individual logon and any administrator. This is to protect a person’s voting record, as well as his profile. No other individual should be able to view how another person votes or have access to items used to identify the person.
Anybody can create a user logon with password, regardless of citizenship. In creating a logon, the user must submit his birth date & state drivers license number or social security number. But it should be noted that drivers licenses & social security numbers by themselves are insufficient proof of citizenship, because such numbers are granted to citizens and non-citizens alike. Therefore, merely creating a logon does not automatically grant a voter-id which is required for obtaining access with update permissions to any other section of the database. The user without a voter-id number is strictly limited to their logon section in the database.
A voter-id number can be obtained by submitting a request to an administrator in person or online, with proof of citizenship. Proof of citizenship includes a passport or medicare number, a birth certificate or naturalization papers, along with a picture. Such a request can be in the form of asking for: a) a voter-id or b) a candidate setup or a c) ballot setup, or d) administrator permissions . And until an existing administrator approves the request, that person’s logon should not have any access or update permissions beyond their current status.
Once a voter-id is obtained, the user’s logon request is linked to the the current year’s existing election data applicable to his request as a candidate or his ballot request. For as long as he has his voter-id, he will not have to resubmit his proof of citizenship. If he makes any changes to what he submitted, including his birth date or drivers license, he may have to request a new voter-id number.
Section 2 – THE ADMINISTRATOR MINI DATABASE FOR SECURING THE ELECTIONS.
Do you see the administrator mini database section on the far left? There you will see 3 record types connected similar to what was described previously in figure A , but with the elimination of the link chain between the top two boxes & the addition of a 2nd link chain between the top and bottom boxes. One of these top-to-bottom link chains is for new voter-id requests, & the other is for approved voter-ids. And what was the middle box hybrid master has become a pure external master noted as the “Birthday Chain Master” tying in to the lower voter-id detail record. The purpose of that record is to link together all voter-id records that have a common birth date making it possible to prevent two different voter ids being granted to the same person having two different logons. It also helps to identify potentially dead persons. It should also help to prevent the same person from voting in two different states during the same election.
In the far left-hand section of the database schema is the voter-id database, aka, the administrator mini database, which provides a unique number to specifically identify each and every US citizen. As previously stated, anyone can create a logon, citizens and non-citizens alike. But, based upon proof of citizenship submitted either in person or online, the assignment of a voter-id to a citizen person’s logon is critical in allowing that user’s logon to have update-accessibility to any portion of the election system database appropriate to that person’s level of responsibility.
Only citizens can approve voter-ids for other citizens. Please note that even all election administrators must have validated voter-ids tied to their logons, regardless of their governmental level of responsibility. But to begin, we must assume that all election administrators do have valid voter-ids tied to their logons & will discuss later how they acquire administrative level permissions. But for now our focus is upon the management of a voter-id database containing all voter-id records.
Of first concern is who are the logons that will be allowed to access & manage the voter-id database. Because of their immediate closeness to the voting public, obviously all local state election officials will have update-access to the appropriate state organizational level within the database & as flagged in their logon by the update-access-level-indicator, aka, the “administrative-level-indicator”. Precincts will be assigned to administrative-level-2. Level–3 is for city, level-4 for county & level-5 for state.
What about levels 0 & 1? They are levels assigned to non administrators, ie, joe public, by the higher-level folks. When a user first creates his logon, it will be forced to level-0 which denies him from accessing any part of the election system database. Upon his request to an administrator & being approved as a citizen, he is given an active voter-id & his logon level will be changed to level-1.
Any of these state levels can accept a voter-id request and begin, if not finish, the approval & activation of a validated voter-id. With the exception of being able to assist a level-0 request, each level will be confined to its own level. So state administrators will not be able to override county, city or precinct administrators.
State governments should not be updating their voter rolls based simply upon a DMV request. Nor should states be issuing ballots without a would-be voter request. Only via state election administrators at the various state levels should be permitted to give out ballots in electronic form to people who have voter-ids. And if a would-be voter does not have a voter-id, he should be able to request one of the local state election administrator at the time he applies to be a candidate or in requesting a ballot. The local state administrator should be able to assign the next voter-id number available, & create a new preliminary voter-id record containing the following data: 1) a record status flag initialized to pending status, 2) mandatory data including the requester’s logon id, birth date, & drivers license & 3) data fields including passport id with flag, medicare id with flag, & social security id with flag should be defined and filled in if possible. Then the local state administrator should attempt to validate the requester’s citizenship. If the local administrator cannot validate the would-be voter’s citizenship, then he should link the preliminary voter-id record in a voter-id validation request chain to be reviewed by the feds who will approve it or reject it by tagging the record with an approved or rejected flag.
Federal administrator logons will be assigned to level-6 & include employees within the Federal Election Commission, the US State Dept, the Medicare Admin, or the Social Security Admin. These are necessary because any one of these federal agencies can validate the authenticity of a preliminary or existing voter-id record. In addition they should be validating each and every activated voter-id every four years.
Upon approval by at least the local state administrator or one of the federal agencies, the would-be voter’s logon will be updated from level-status 0 to level-status 1 and his new voter id will be updated in his request record. When the voter dies, his logon will return to level-status 0.
Having identified the election administrators & their logons, what does their online real time voter-id system database schema, aka, the administrator mini database, look like?
Section 3 – THE ORGANIZATIONAL HIERARCHY:
The middle-left 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.
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.
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.
EARLIER POSTS:
The Real Threat: https://www.aaarrrg.com/wordpress//?p=3161
The Virtual Precinct: https://www.aaarrrg.com/wordpress/?p=2632