A Fake Consultant Exclusive: Political Robots Fail In Operational Service

It has been quite some time, Gentle Reader, since we addressed the issue of political robot design, but recent events have forced us to return to the subject once again.

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).

On Evolution, Or, Political Robots Compared

Some of you may recall my previous exclusive reporting of the crash (and successful restoration) of the Hilary® Mark II Mod. 7 Robotic Candidate Device just before the start of Tuesday’s Democratic debate.

Because of the community interest, we will today expand upon that discussion by walking through some of the differences in design philosophy between the two major categories of political robots: the Robotocan™ .1 Series and .3 Series of Devices and the Democrobot Device Program robots.

The reader should also expect technical comments on the execution of those philosophies, and some consideration of the day-to-day funding, operating, and maintenance issues that impact the entire Robotic Political Device establishment.

Let’s start with design philosophy, shall we?

Those familiar with ballistic missile warhead design and targeting tactics will recall that there were two basic operational concepts for ballistic missile attack during the Cold War: the Soviet Union tended to rely on a single, large warhead-for example, an attack on Detroit might feature a single 30-megaton device fused for ground burst in the center of the downtown area. On the other hand, a US target package delivered on St. Petersburg might rely on a MIRVed delivery of perhaps 9 payloads of 500 kiloton size, dispersed over the city and fused for detonation at 1000 feet or so to accomplish a similar task.

As a result of the design decisions that went into the initial weapon designs each side has specific operating needs that drive the manner in which they direct and disburse their forces. The same is true for the Parties and their Robotic Programs.

The most important design differentiation-and the one that affects every element of campaign operations and strategic management-was the decision, starting with the Robotican™ v1994.1 and .3 series, to eliminate the autonomous speech and thought capabilities that were embedded in the Robotican™ OS kernel.

The Recent History of Democrobots

Perhaps because of their long-term Congressional successes, the Democrobot design parameters instead called for a fully autonomous Device-an adaptation of the “fire and forget” philosophy that defines many weapon systems.

Of course, what works well in Congressional elections might not work so well when dealing with a “big-tent” constituency in a Presidential race. Candidates such as a BarneyFrank or a BoxerBot were great in District and Statewide races, but they just could not get traction nationally-and this was evident to everyone with the failures of the DukakadroidCSE and the Mondaleotron.

Even the CarterSys Bicentennial Edition and The Al Gore Robotic Candidate Device Company’s Al Gore (so dull his model name was...Al Gore) were unable to achieve re-election. These models represented early experiments in applying “liberalism filters” and a new “political correctness” adapter, and it was clear that more work was required.

Democrobot designers were therefore extremely excited, to say the least, when the first pre-release testing data was returned for the two “BillBot” prototypes.

BillBot 1.0 and BillBot 1.0A both featured the two most important additions to a Democrobot Presidential Candidate Device in at least two decades-a new class of liberalism controls called a “center stabilizer service” that kept the ‘bot from veering off to the “left” too excessively; and an improved “revenue agitator”, which is designed to improve fundraising performance.

Both designs also included the newly updated WonkWare Enterprise application (now standard on all Democrobot Devices) with the Rhodes SCH snap-in installed.

The biggest difference between the 1.0 and the 1.0A was the “Carvilleator” add-on card used in the 1.0A, and it was this revolutionary device that created such excitement for Democrobot designers. This “everyman regulator” (reverse engineered from the Robotican™ RoboReagan v1980.3 after a nearly ten year effort) caused such behavior as fast food cravings, the ability to engage crowds, and a “Q” score higher that any Democrobot Candidate since KennedyCorp.’s legendary Model 109. When paired with the experimental “binary ‘bot” Hilary® Mark I, the system had extraordinary electoral and fundraising success.

Despite the success of the design, the BillBot 1.0A M3.1002 (the actual Device that was elected) had certain idiosyncrasies which lead to the decisions to remove the Carvilleator and ultimately to rework the Al Gore design for 2000. All of this rethinking (and the Al Gore’s vote gathering success) eventually led to the introduction of the Boston Robotic Group’s McKerry in 2004 as an offshoot of the Al Gore architecture.

After 2004 it was evident that, despite the risks, a BillBot-class design would have to be reintroduced, at least in the primaries, so that the BillBot and Al Gore environments could be compared side-by-side in front of live voters.

As a result, the two front-running systems in the Democratic national polling today are the BillBot Group’s ObamaBot 2 (build M1.2245) and the most current incarnation of The Al Gore Robotic Candidate Device Company’s line (and the redesign of the aforementioned 1990’s “binary ‘bot”): the Hilary® Mark II Mod. 7.

That Al Gore lineage, as we well know, has created a vastly improved but highly “moderated” Candidate. After early testing of the Mods. 5 and 6 she was determined to need an update-and the Mod. 7 included personality emulator and Iraq War response software “tweaks”. Recent evaluations have suggested that this new code, while highly successful, may have contributed to the crash we discussed in the first installment of this story.

Meanwhile, ObamaBot engineers also appear to be in a “field development” process, with alterations to the aggression controls causing recent anomalies when trying to run the %root%\foreign_affairs.com program’s command set, among other issues. Because of the efficiency of the improved revenue agitator ’07 software and chipset, however, sufficient funding exists to ensure the program can continue to exist as long as is necessary. Downtuning of the reintegrated Carvilleator may occur in the future as well if the operators determine an increased “gravitas output” is required.

Robotican™ Devices considered

Earlier we had touched upon the decision to remove the autonomous speech/thought system from the Robotican™ operating system, and it is now time to explore this topic further.

It was well known that the speech/thought system had led to many duds and misfires of Robotican™ Congressional Candidate ‘bots (and a Democrobot majority in several Congresses) throughout the previous several election cycles leading up to 1994; and it was hoped that by adopting a “push” software/firmware update system and a new “talking point service” for the series a more consistent “ideological display” output could be achieved.

As a result, all Robotican™ Congressional Candidate Devices (the so-called .1 Series) include the capability to receive “push” updates through a simple SATCOM modem. Interoperability exists with the Robotican™ Murdoch series of Media Robots, meaning all Republican robotic assets can be software updated with the same “talking points” simultaneously.

The GWBmatic3000 v2000.3 Device Series, developed for the 2000 Presidential election cycle, is a variation on the highly reliable and robust Barbara6000 (there were motherboard issues, and a redesign was needed for Presidential Service); and features an additional “remote user” capability that allows for live operation of the Device by a connected operator.

The evolution of that capability is in itself amazing.

Robotican™ engineers were tasked with the development of an on-board chipset that would incorporate the capabilities of Harris Corp.’s AN/VRC-103(V)2 radio system-a unit often carried as a backpack by US Army troops today-to allow the remote operator 100% reliability of communication with the GWBmatic 3000 in any conceivable threat environment; particularly debates; with absolute system availability guaranteed by the installation of radiation isolated and redundant data busses emanating from redundant neck antennae.

To prevent Democratic political operators from “listening in” on the transmissions, the SINCGARS and Havequick I/II frequency hopping systems were included, along with Fascinator 128kbps support-unique among acknowledged military COMSEC systems. (Extensive encryption key storage, to support a variety of operating modes, is also provided for.) Additionally, should voice communications fail, the GWBmatic3000 can track and locate up to 12 SATCOM networks and download data via SATCOM modem, using the SATCOM Situational Awareness software.

As a final fail-safe, a “remote emergency boot/operate” receiver mode exists which can exercise Device control using a second program that runs above the Robotican™ Operating System (similar to the relationship between DOS and the Windows 9x. OS programs). This will allow a remote operator to call and execute programs, services, and functions of the GWBmatic 3000-even if the OS has “frozen” or cannot be otherwise operated. Unfortunately, it is not possible to immediately transfer between program modes, a failure that has been noted under certain emergency conditions.

A last minute design compromise was the external emergency battery pack used on the GWBmatic 3000 v2004.3 Debate Edition, which is not present on the GWBmatic 3000 v2004.3 COMMAND/POTUS Edition. By hot-swapping the battery just before the debate it was guaranteed that all system functions would be maintained even in the event of onboard primary and secondary power system failures.

And the future?

Besides the issues we have just addressed, a major problem for both sides has been the Uncanny Valley factor, which is driving research for both sides.

Additionally, as we all know, the massive effort on both sides continues into finding the solution to the Holy Grail of political device execution-a reliable, effective “Truth Enhancer” that will allow for the more effective dissemination of political concepts and positions.

So that’s our story for the weekend-a tale of two groups of researchers, maintenance technicians, and customer-operators working hard to create ‘bots that inspire, motivate...and keep you in a constant state of suspended disbelief until the morning after Election Day.

After which, the cycle begins again.