Re: ERC Public Hearing Tonight

[Paul E Condon <pecondon@xxxxxxxxxxxxxxxx>]

One point on which I incline toward Hart's position: Deleting records
in a high impact public system is a bad idea. Instead, for each
primary record, i.e. a scanned image record, there should be an audit
trail record. In the audit trail record, there should be timestamped
sub-records of what was done with the primary record. In this
situation, there should also be a file of all ID numbers that were
used to generate blank ballots and fields that are updated each time
that ID# is found in scanning ballots. The goal in this is to be able
to review all cases where someone or some team made a decision to
choose one ballot image over another where there were duplicate ID#s.

On Thu, Apr 21, 2005 at 01:04:55AM -0600, Paul Tiger - LPBC - Outreach wrote:
> Thank you Paul ... now we're hearing some constructive ideas.
> 
> Jay Harbour - committee member and someone who worked closely with the
> systems - stated something similar. During our third meeting we witnessed
> the operations of the scanners. Everyone quickly noted that the scanning
> hardware/software systems were not programmed to deal with ballots with any
> sort of anomaly.
> Jay wanted to be able to reject these ballots and set them aside. The system
> forced the operators and resolution team to deal with the ballots that were
> problematic immediately after scanning.
> Hart stated that for ballot security reasons that the operator would not be
> permitted to delete a scanned ballot from the scanned stack in the computer.
> This could have easily have been done. Even if a ballot manage to be scanned
> twice, a duplicate check would have discovered that. Such a check is done
> both with batches and with the entire election. (done twice).
> 
> Besides Jay's thoughts on simply rejecting and deleting the scanned ballot
> and moving it to another process, I saw another option. (as did others).

Moving whole image records around on disk can get time consuming. The same 
effect can be achieved by keeping the primary image records in files in
the order in which they were scanned, and then developing files of pointers
to those primary records. A pointer will consist of a filename and a numeric
offset from the beginning of that file.

> That is for the scanned ballot to be moved to a temporary database table,
> and then dealt with separately after the auto-resolve ballots had been dealt
> with.
> 
> Paul W mentioned in a meeting with Dick Harris and myself that the Kodak
> scanners are equipped with print head. Ostensibly, we could mark ballots in
> need of manual resolution with a code that would identify them as special in
> some way. 'Unrecognizable'; 'overvoted'; 'damaged'; 'write-in'. Pretty easy
> to sort the rejects at that point - much the same way as Swiss ballots get
> sorted into piles.
> 
> Hart does not employ the use of the print heads; they've refused to alter
> the software, and lay all the blame for the problems with the printer of the
> ballots. Hardly helpful. We also know that they applied TX elections law to
> the operations of our systems. That whole business of not counting ballots
> unless all the pages were present, and not using the computers to resort the
> ballots in page order has noting to do with elections law in CO. It does in
> TX, although no one can understand why TX elections laws would be so stupid.
> This same stupidity was experienced in Orange County.
> 
> The software is fully capable of managing the ballots; storing them in
> temporary tables until resolved; deleting them for re-scan; marking ballots
> with anomalies; etc. Hart just doesn't want to do that. I think that they
> are afraid to admit that their creation is brown - not ready for prime
> time - and open themselves to civil and criminal liabilities.
> 
> Paul C suggests we dump Hart as the software vendor. What a novel idea!
> Hart's caveat for support is that we not change the systems or software.
> Since the support that they've given is so poor, why continue with them? We
> own the hardware and most of the software. Why not roll our own?
> My read of the contract looks like we could modify the Hart software to our
> hearts content, as long as we doing sell that modification or creation. The
> contract prevents BoCo from becoming a competitor to Hart, but not from
> altering our stuff. It is our stuff, we paid for it. All we risk is loss of
> support. WHAT SUPPORT!?
> 
> paul t
> 
> paul
> 
> -----Original Message-----
> From: Paul E Condon [mailto:pecondon@xxxxxxxxxxxxxxxx]
> Sent: Wednesday, April 20, 2005 2:21 PM
> To: cvv-discuss@xxxxxxxxxxxxxxxxx
> Subject: Re: ERC Public Hearing Tonight
> 
> If it is a given that BC will continue to use Hart equipment, then what
> is needed is a new set of scanners with reject hoppers and code that
> records in a control file which ballots have been sent to the reject
> hopper. Then resolution teams only look at the stuff from the reject
> hopper in a second run. Or maybe I misunderstand the various kludges
> in Hart software. To me holding up the whole input stream when one
> item needs to be resolved is a really wierd design decision. Hart
> should be fired and a new software provider hired, and a new hardware
> provider, also.
> 
> Paul C
> 
> 
> On Wed, Apr 20, 2005 at 12:26:40PM -0600, Some Guy wrote:
> > I'd love to here suggestions on how write ins can be efficiently handled.
> > I'm sure the whole committee and the clerk would like to hear that too.
> >
> > So far all I have heard is suggestions to restrict ballot access. AKA - no
> > write ins. That won't fly with me or too many other people.
> >
> > Some Guy
> >
> > -----Original Message-----
> > From: Mary Eberle [mailto:m.eberle@xxxxxxxxxxxx]
> > Sent: Thursday, March 03, 2005 5:24 PM
> > To: Some Guy
> > Cc: Lpboulder; Cvv-Discuss@Coloradovoter. Net
> > Subject: Re: ERC Public Hearing Tonight
> >
> > Will someone please mention the following to the panel? In an election
> > with write-in candidates, every batch of ballots that has even one
> > write-in vote will need input from the resolution team. This approach
> > is not efficient and will definitely slow the counting.
> >
> > I hope everyone saw the article on p. 1 of today's Daily Camera saying
> > that we will have some hand-count checking of the March 8 results.
> > Yeah, team!
> >
> > Some Guy wrote:
> >
> > > The Boulder County Elections Review Committee will have a public hearing
> > at
> > > the Longmont Senior Center this evening at 6:30pm.
> > > 910 Longs Peak - Longmont
> > > 3 blocks west of Main (Hwy 287) on Longs Peak (the 700 block of Main).
> > >
> > > SG
> > >
> > >
> > >
> > > .
> > >
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.308 / Virus Database: 266.9.19 - Release Date: 04/20/2005
> >
> 
> --
> Paul E Condon
> pecondon@xxxxxxxxxxxxxxxx
> 
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.9.19 - Release Date: 04/20/2005
> 

-- 
Paul E Condon           
pecondon@xxxxxxxxxxxxxxxx