Unwitnessed Autonomy

The paper defines unwitnessed autonomy: an automated system that takes consequential actions on parties outside its boundary when no party is placed to observe those effects and report them to the operator. The case is Tapstall, a shop-link service for informal and social-commerce merchants. Its test suite passed in full while the live pipeline was mailing non-prospects, sending from another venture's support mailbox, posting into another venture's social account and running duplicate copies of itself. The paper codes 24 defects (11 from the audit, 13 found during the rebuild) into nine classes. Sixteen (67%) are witness gaps, and none of the 24 was found by a test. It proposes a five-point witness map (identity, clock, effect, recipient, stop), four "one-of" rules and seven testable propositions. It is a single pre-revenue case, so its propositions are offered for testing, not as established findings.

Abstract

Small ventures can now run growth pipelines that act without a person in the loop. A scheduled job finds prospects, another writes to them, a third posts to social accounts, and a payment webhook switches accounts on. Each component can be correct by its own tests while the pipeline as a whole does things that nobody sees. This paper names that condition unwitnessed autonomy: an automated system that takes consequential actions on parties outside its boundary when no party is placed to observe those effects and feed them back to the operator.

The paper reports a design-science case study of Tapstall, a shop-link service for informal and social-commerce merchants in Zimbabwe and South Africa. Its growth pipeline ran on free cloud tiers with no paid staff. On the day of the audit, the venture's own test suite passed 420 of 420 tests against the live code. In that same code:

• Of the 17 distinct addresses the outreach runner had already mailed, 14 were not prospects at all. They included a magazine reviewer, a platform's support desk, a government weather service and a literal placeholder address.
• These messages went out from the owner's personal mailbox, which was also the support inbox of a separate venture, and the runner had been marking that venture's support mail as read.
• The press module had posted three times a day into the other venture's social account.
• An old copy of the service on the same account was answering writes against production data with a superseded secret. Two more copies on a second account ran their own scheduled jobs.
• Every merchant email the product promised had been a silent no-op since launch.
• The public facts printed on a storefront were enough to take over that store.

The audit and the rebuild logged 24 defects in total. Coding them shows that 16 (67%) were witness gaps of four kinds:

• the effect of an action was never observed;
• the recipient's position was never observed;
• the identity the system acted under was not its own;
• the number of clocks and copies running was unknown.

None of the 24 was found by the existing test suite. Four of the 13 defects found during the rebuild were introduced by the fixes themselves, and each was caught by a live dry run or by inspecting real output, not by a unit test.

The paper contributes:

• a definition of unwitnessed autonomy that separates it from ordinary software defects, technical debt and spam;
• a taxonomy of nine defect classes, of which five are witness gaps;
• a witness map, an audit instrument that asks five questions of every autonomous action;
• four design rules for small autonomous pipelines: one clock, one voice, one identity, one surface;
• seven propositions for testing.

The case is a single pre-revenue venture analysed by an interested party, and the propositions are offered for testing.

Keywords: unwitnessed autonomy; automation; externalities; growth pipelines; outreach; email; identity coupling; distributed clocks; silent failure; informal economy; design science

Contents

1. Introduction
2. Literature review
3. Method and case
4. Findings
5. Frameworks and propositions
6. Discussion
7. Conclusion
8. References