As you undoubtedly are aware, three high profile ‘bots from Robotican™ Labs have recently experienced major failures.
It was originally thought that the problems were isolated to the Robotican™.1 Congressional Series of Devices...but it is now known that the failures also extend to the.2 Gubernatorial Series as well.
In today’s story we will examine what is known about these failures, how they may impact other devices in Political Service, and what solutions might be available to address these issues.
First, a bit of background: In 2007 we examined the state of the robotic art in considerable detail, and there is some information from that analysis which should be brought to the table today:
In putting today’s “non-optimal behavior modalities” into a proper context, it’s important to remember that Robotican™ Labs devices are not designed for fully autonomous operation—instead, they depend on central management of operating parameters and onboard software updates that are “pushed” out to the devices on a daily basis.
The reason for this design choice is to enable all Robotican™ devices to create a more consistent “ideological display” output: in other words, to allow the .1 Congressional Series, the .2 Gubernatorial Series, the .3 Presidential Series, the Murdoch Series of Media Robots (and the Murdoch’s derivative, the Atwater SpokesBot Series) to all deliver the same messages simultaneously, and to provide the ability to immediately revise that ideological output should operators determine the need for such change exists.
This can have its disadvantages, and there are many who have noted a “parroting” effect over the years; a problem now rendered more acute with the expanded use of YouTube as a campaign analysis tool by both opposition and independent researchers.
(Systems fielded by the Democrobot Device Program are far more autonomous, which reduces the “parroting” effect. Of course, this also makes it much more difficult to get the ‘bots to operate in unison; an effect that has been noted frequently by observers since at least 1968.)
The failure that is the easiest to explain, I’m told, is the recent breakdown of Robotican™ Lab’s Revo-Ensign v1994.1. The Revo-Ensign ‘bot is one of the many Revolution®-Class v199x.1 Devices that were introduced into service during the 1994, ’96, and ‘98 election cycles. Several of those devices have failed in spectacular manner, most notably the Revo-Vitter v1998.1, the Revo-Greene-Waldholtz v1994.1, and the Revo-Foley v1994.1.
Since the 1994 electoral cycle all Robotican™ Devices (including Murdoch Series Media Robots) have come with the Moral Majority snap-in pre-installed as an Operating System enhancement.
The problem seems to be an incompatibility issue between this snap-in and the Human.exe program’s RealityEmulatorProcess, which is one of the core processes that is allowed direct access to the Operating System Kernel.
In order to avoid “Uncanny Valley” problems, Robotican™ software engineers of the 1980s programmed for a certain number of “moral failures” in the robot fleet, but they could not anticipate the data errors that would result when Human.exe, the snap-in, and the OS Kernel interacted.
The most obvious sign of non-optimal behavior was seen in the Media.exe program. When the program is initialized it calls the MediaModulatorProcess (the second of three core processes that can access the OS Kernel). Software engineers now know that in failure mode the output from that Process can become severely garbled.
In some instances so many “unrecoverable errors” occurred that over the years since the snap-in was introduced several Revolution©-Class Devices have required “unscheduled withdrawal” from Political Service.
The repair appears to be fairly simple, and Robotican™ software engineers have, on several occasions, asked for permission to remove or modify the Moral Majority snap-in, but in every instance the requests have been denied by Corporate Management.
(It is not known if Fundraising.exe is impacted by the presence of the snap-in. The third “core” process, AcceptDonationsProcess, is called by the program, but considerable research conducted in the runup to the 2000 campaign cycle suggested the Process remains unaffected, even when the Operating System is in failure mode. More recent research, however, contradicts those conclusions.)
Now here’s where the story turns weird.
During 1998 and 1999 Robotican™ design teams were preparing to field test the Operating System Release Candidate for the Compassionate©-Class Devices that would be introduced into Political Service for the 2000 cycle and beyond.
Instead of removing the Moral Majority snap-in from the new OS, Corporate Management ordered engineers to create a new program, Faith.exe, as its replacement; the theory being that a closer association between Faith Factors and the OS Kernel would yield a more robust design that would be less likely to fail. Associated with the program are two new core processes, MoralObjectionProcess and JustifyActionProcess.
At the same time, a Revolution©-Class ‘bot was transferred from .1 Congressional Service to .2 Gubernatorial Service: the Revo-Sanford v1994.1. Normally, this would involve the installation of new OS components...but in this case, the Robotican™ design team was ordered to implement a retrofit of the Revo-Sanford to a Compassionate©-Class Device.
The result was the Compasi_Sanford v2000.2...and the problems began almost immediately...and strangely enough, on several occasions animals seem to be associated with the bizarre behaviors noted by engineers and technicians working on the project.
Examples? At one point in 2004 the Device was confusing pigs with humans, and in 2005 the Compasi_Sanford held a news conference to announce his intention to appoint a horse as his Legislative Liaison.
This was hardly a unique situation: an effort to retrofit a Revolution©-Class Device from .2 Gubernatorial Service to a Compassionate©-Class .3 Presidential Service Device resulted in the release of the GWBmatic 3000 v2000.3 and its own upgrade, the v2004.3—Devices that many say set the “gold standard” for political robot failure.
(There are some who would say the gold standard was not set by the GWBmatic 3000, however, pointing to the Evangi-Haggard v.1984.SB, which imploded in a most spectacular manner in 2006.)
Experts will tell you that you will encounter more problems with any retrofit project than you will in a “new build” project; the Robotican™ engineers I have been in consultation with are suggesting that the same effect is in play here.
It should be noted, however, that others feel the Faith.exe program and its MoralObjectionProcess and JustifyActionProcess are the real source of the problem, and that any effort to apply software of this type to ‘bots working in Political Service will inevitably result in disaster.
The third Device we will we discuss today is not part of a Series of Robotican™ Labs ‘bots, but is instead a “one-off” experimental design: the SarahCuda v2006.Xa.
For more or less a decade Corporate Management had been pressing design engineers to develop a system that could effectively function in a “consistent ideological output” environment while avoiding the “parroting” problem...and for those in the Robotican™ “Skunk Works” engineering group, this task now had the highest priority.
One possible solution, designers thought, would be to create disassociation between the SaraCuda and the Compassionate© Series of ‘bots.
With very little in the way of time or resources, Skunk Works engineers decided to attempt deployment of the still unproven “Maverick II” software suite, and by 2006 the Device was being field-tested in the remote and friendly environment of Alaska.
The software suite does have its limitations, however: because of the lack of resources available, there was no effort to develop a fully-functional QueryResponseProcess. Instead, the designers installed “call and response” and “predictive algorithm” technologies that were based on “sampling” responses into the Device’s onboard data storage facility for recall later.
Although the Device was experiencing anomalies during its experimental phase of Alaska Gubernatorial Service, Corporate Management was so desperate in the runup to the 2008 election that they rushed the SaraCuda into full operation, despite the concerns of test engineers.
“No Device can successfully function in a hostile media environment running call and response software, and they knew it when they sent her out there, and they did it anyway. I couldn’t believe they would be so willing to accept the risk, even after we warned them what might happen...”
--Harry Paratestes, Robotican™ design engineer
Although initial results were encouraging, it soon became clear that the limitations of the software were going to lead to the very disaster predicted by the design and test team. After the 2008 election, there was hope that the Device could be repaired and returned to Gubernatorial Service, but a cascading series of failures within the Operating System and the MediaModulatorProcess have now caused Corporate Management to initiate an “unscheduled withdrawal” of the Device from Service.
As of today it appears that the Device has been returned to Experimental Service, and it also appears that the call and response software is still running, suggesting that extensive development effort lies ahead before a successful redeployment can occur—or that the Device may be converted into a Murdoch Series Media Robot.
It’s time to bring this story home, so let’s see where we’ve been:
Robotican™ engineers are dealing with three different failures in three different types of ‘bots—and in two of those failures, there are crippling incompatibilities that appear to be beyond the ability of the engineering team to resolve. Corporate Management appears to be unwilling to acknowledge that an incompatibility exists...and unwilling to allow removal of the software that is at the heart of the failures.
In the third case, desperation compounded by lack of time and resources led to the massive failure of the still-experimental SaraCuda, and it now appears that an effort may be underway to “repurpose” the Device for Media Service.
Will the current Robotican™ fleet of Compassionate©- and Revolution©-Class Devices be capable of leading the charge back to victory, or will Corporate Management be forced to place a new generation of ‘bots into operation?
Can a Robotican™ Operating System be fielded that does not require the Faith.exe program or its derivatives?
And finally, has the reliance on a consistent ideological output—and the resultant “parroting” effect—become more of a detriment than an advantage in the effort to garner votes at election time?
These are the questions for the future...and the next time we address this subject, maybe we’ll have more answers.
WARNING—Self-Promotion ahead: I am competing for a Netroots Nation Scholarship, and I was not selected in either the first or second rounds. There is one more chance...and today is the last day of voting...and while I’m not normally inclined to use the “hard sell”...I guess I will today.
If you like what you’re seeing here, and you’d like to help me make these stories even better, swing by the Democracy for America site (even if you have before...) and express your support.
All of us here thank you for your kind attention, and we now return you to your regular programming (which, in keeping with the “hard sell”, is rated PG, instead of the usual G).
