----- Original Message -----
Sent: Friday, December 10, 1999 10:26
AM
Subject: Re: Logging Scanner Jams (was:
Audit trail improvement suggestions)
Excuse me while I play the devil's
advocate here.
Is this "jam event record"
something we want to have displayed or recorded at all?
Yes
If there is a problem with the
count totals between the AccuVote display and the ballots in the Ballot Box,
why do you want to so quickly use it as an excuse?
Jams are
the only excuse we've got for these inconsistencies. Remember that that
the totals are being compared not just to the number of ballots in a ballot
box, but the number of signatures on the roster as well - plus the ballots are
numbered on the stub. They know how many voters were given ballots and
voted without too much doubt.
What would you do if there was no
jam event recorded and yet there was still a mismatch between ballots in the
box and the counter on the AccuVote?
Depends on whether its high or low. Realize that most
sites don't do anything if the count is less than 3 or so off. They
mostly look at the ones that are off by 3+ or so. Again, its not just
the Counter on the AccuVote, its the # of ballots, the AccuVote report, and
the signatures on the roster.
What would you get from a jam event
record? That a jam happened?
You get an explanation that human error was the factor and
explanation for the discrepancy rather than "the AccuVote isn't
counting" right.
But who was at fault: the poll worker or the machine?
The Pollworker. That's the whole point. It gives
you a chance to show that X number of times there was a potential that the
pollworker didn't handle it correctly.
How do you know if the mismatch was caused by that
jam.
Again, that's the whole point, you don't know, you never
know what really happened, but if we can show that there were instances where
the pollworker could have mishandled the ballot, then they do less
"fingerpointing" at the AccuVote itself.
Would they call into question the
results of an election if a unit showed multiple jams yet the ballots totals
matched the counters?
No, they'd just assume the pollworker handled the jams
correctly, or they would recount the precinct.
I understand it would be great to have the detail for troubleshooting,
but do you think they would find the fault due to the poll worker when they
have a machine that could be perceived as "at fault" instead?
Of course. The
"culture" out there believes that pollworkers can barely get their shoes on in
the morning. It's assumed that the pollworker is at fault. No
administrator wants to believe its the AccuVotes fault.
I think less info is better under these
circumstances.
Dear Devil, you
may want to attend more elections and be the one trying to explain the reasons
for strange AccuVote behavior. What the folks in the field - Sorry,
what I'm saying - is that "jams are our friends" when it comes to
explaining anomolies.
What kind of interpretation would someone make when seeing that
detail?
Example
"Oh, look here! The paper
tape shows it jammed during the day. The machine must be responsible for
the error in the totals."
Quite the opposite in the real world. Its "Oh, look
this explains that the pollworker didn't read the display! Those
pollworkers never listen to us in training!"
If we provide this "jam event
record" as an excuse, wouldn't it throw doubt onto the integrity of the
machine and its programming.
See above.
I believe it is better to
leave answers for these unsubstantiated anomalies to the discretion of
the election supervisor.
That's why you're the Devil's very own advocate in
McKinney! But we like you anyway.
Outside of the "O" level ROMS, when
a ballot is processed into a Ballot Box by the AccuVote, it is
counted. If a reader takes a ballot, it
accurately scans that ballot and deposits it into the Ballot
Box.
Now you're damaging your own credibility by making these
sweeping statements.
If there is any problem with the
reader (i.e., hung or failed Self Test), it will not process the ballot into
the Ballot Box.
So even the Devil's team has strong degrees of faith.
I come more from the Kierkegaard side of the family, faith is a daily affair,
and depends on the circumstance and the ROM level. I can point to any
number of "can't happen" events that turned out to be true (ballots being put
in the emergency bin, and ending up in the write-in bin, passed ballots,
etc.)
Play out an election night scenario
in your head with these kind of questions arising. Now imagine there is
nobody there from Global to explain the information provided.
It's my dream come true.
Let's not consider every
user's request as an absolute. Perhaps the user is just as
much in the dark about the ramifications of that request as we
are.
The problem here is that I agree with the user, but not for
the same reasons. Jams are our friends guys. They give us all
kinds of room to explain things. The problem comes more from the
scenario where a Global person says, "Well, there were probably jams" and the
pollworker can't remember whether there were or not. Repeat after me,
"J-A-M-S A-R-E G-O-O-D".
Ian
----- Original Message -----
Sent: Thursday, December 09, 1999 8:26
PM
Subject: Re: Logging Scanner Jams (was:
Audit trail improvement suggestions)
I think the statistical approach would be adequate, although
the log with a
date and time stamp would be the preference.
I
think that saving these for the 2.0 release is OK in the sense that
we
might be able to "sell" the upgrade, vs having it be required.
However, it
might mean the AV would have to be recertified in many
states. Not good.
Other thoughts?
----- Original Message
-----
From: Guy Lancaster <glanca@dieboldes.com>
To: Kerry Martin
<kerry@dieboldes.com>
Cc: <rcr@dieboldes.com>
Sent: Thursday, December
09, 1999 8:40 AM
Subject: Re: Logging Scanner Jams (was: Audit trail
improvement suggestions)
> Some form of logging
scanner jams has been brought up
> before and I think that I spoke
with Steve about a month ago
> about it. This may also be
related to Jane's RCR: Print
> Vote Centers Activity of Oct 27,
1999.
>
> The problem, as Monica stated, is that the
officials need
> statistical support when trying to resolve
discrepencies
> between the number of ballots in the ballot box and
the
> number recorded by the Accu-Vote. I can see three
possible
> ways of providing this, each with pros and
cons.
>
> 1) Add a stats counter for the number of jams
experienced
> since the counters were last cleared. While we're
at it, we
> could have separate counters for counted and returned
ballot
> jams. This would be my preference since it provides
the
> required statistics while consuming the minimum of
>
resources. However it requires a memory card format change
> and so
would only be available in major new releases such as
> the upcoming
version 2.0. These statistics would appear on
> the audit
reports and could be uploaded for reporting by
> GEMS.
>
>
2) Print a log entry on the internal printer for each jam.
> This
could be selectively enabled and disabled from GEMS'
> Accu-Vote
parameters and would not affect the memory cards.
> Downsides include
having to prevent the tape from jamming
> while it's locked in the
printer compartment and having to
> count the entries on the tape to
gather the statistics. The
> upside is that it would provide a
timestamp on each entry
> which could help with resolving the
problems.
>
> 3) Record an entry in the audit log for each
jam. This one
> scares me a little because we have limited space
on the
> memory card for the audit log and currently we allow
for
> about 400 entries. The purpose of the log is to
record
> critical operations such as inserting the memory
card,
> powering on the unit, the starting and ending of
counting,
> printing reports, and a few others. Although
possible, it
> is very unlikely that we would overflow the audit log
with
> these entries. Events like jams are far less
predictable
> and a problem with a machine could cause a large number
of
> jams. Should the log overflow, the oldest entries are
lost.
>
> Some would suggest that we increase the
size of the audit
> log or dynamically allow it to grow to use
available memory
> card space. The latter is technically
difficult especially
> if we want to record events starting from the
beginning of
> the download operation as we do currently.
Allocating more
> space for log entries comes at the expense of less
space for
> ballot information and counters which will affect
those
> counting absentee ballots. It seems less of an issue
for
> 128K memory cards than for 32K but once we decide to log
>
jams, we have to allow for it in all systems.
>
> My
suggestion is to add support for optionally printing a
> jam log
message in the next 1.94 release. For version 2, we
> would
continue to support this plus add statistics counters
> for
jams. Unless people feel both that it is critical that
> we
record the time of each jam and that managing the printer
> tape is
not acceptable, I would avoid adding this to the
> audit
log.
>
>
Guy
>
>