The word “computer” makes a machine sound like the subject of calculation. Before it named a box, computer was a job: a person responsible for producing numerical results through a method. That older definition is not a vocabulary footnote. It forces us to look at how a result is made, not only at the device that displays it.
RYBN.ORG’s Human Computers begins with that friction. The collective describes the work as media-archaeology research into the relationship between computing and labour organisation, moving from Wolfgang von Kempelen’s Mechanical Turk automaton to Amazon’s service, where human workers perform tasks used in artificial-intelligence systems.1 The project also invokes Gaspard de Prony’s computation factory, where mathematical work was divided into specialised steps.
RYBN offers an artistic and political interpretation: what we call automation can be a new distribution of human labour, made less visible by an interface. That is the project’s position, not a raw historical fact. It becomes valuable when set against NASA archives, crowd-work platforms and research on annotation.
A computer was a person
At Langley in the 1930s, the National Advisory Committee for Aeronautics recruited women with mathematics degrees into a “computer pool.” NASA’s history of Virginia Tucker describes her arrival in 1935 with four other women and the later growth of a department that trained hundreds of computers.2 The Smithsonian’s history of human computers places this gendered division of technical labour in a wider institutional pattern.4
Their work was not the figurative “helping hand” of popular history. They read wind-tunnel measurements, performed calculations, plotted curves and checked results for aeronautical and aerospace research. Slide rules, tables, magnifying glasses, Marchant or Friden machines and worksheets limited speed, but they also made method visible. An error could be located in a film reading, calculation line, graph or addition.
NASA describes a chain in which computers processed test data, returned results to engineers and developed methods specific to aeronautical research.2 Some wrote data-reduction handbooks; others moved into programming when electronic machines arrived. The shift from manual operation to program was not a deletion of knowledge. It changed where the knowledge was stored.
The history is also a history of hierarchy. The jobs were classified as “subprofessional,” with limited opportunities for promotion. Black women recruited from 1943 onward were initially grouped in a segregated section, the West Area Computers.2 Their work could be central to research while being administratively devalued. That contradiction is not an accidental blemish; it is part of the organisation.
At the Jet Propulsion Laboratory, NASA similarly describes women who performed hundreds of thousands of calculations before becoming some of the agency’s earliest programmers.3 We should resist the clean story of a natural march toward code. Their expertise did not simply get replaced by silicon; it helped make the transition possible by turning calculation procedures into executable instructions.
Calculation as a chain of gestures
RYBN reaches back to Gaspard de Prony, who organised the calculation of logarithmic tables through a division of labour inspired by manufacturing: people performed specialised repetitive stages rather than each completing the entire reasoning.1 Even without accepting every historical implication, the form is useful for understanding what automation cuts apart.
A result is rarely one operation. Data has to be prepared, a convention selected, a calculation performed, an anomaly detected, a value copied, pieces assembled and a result presented. An electronic machine concentrates some stages in a processor, but the others return around it: input, cleaning, documentation, maintenance and output review.
Division can increase throughput. It can also destroy the overview. A person encoding a value may not know which decision depends on it. Another person checks quality without seeing the origin of the problem. The system gains speed and loses context.
Modern pipelines have the same structure. A model “learns” from data that has been selected, split, annotated and filtered. Each action is described as a technical stage, but each contains judgement: what counts as a pedestrian, when is a text toxic, are two answers equivalent? A classification decision can become a column, then a training signal, then a behaviour described as automatic.
Mechanical Turk: an old fiction becomes an interface
The first Mechanical Turk was a chess automaton presented as a machine even though a human player was hidden inside the cabinet. RYBN uses that story to reach Amazon Mechanical Turk.1 Amazon officially describes the service as a marketplace connecting requesters to an on-demand human workforce for categorisation, moderation, collection, analysis and image annotation.5
The difference matters. Amazon does not claim that an operator is hidden in a cabinet. It exposes the work through an API and calls it a Human Intelligence Task. The interface does something subtler: it turns situated activity into a standard unit that can be assigned, measured and retrieved like a machine result.
A task can be tiny: identify a car’s colour, transcribe a clip or compare two answers. Small size makes distribution easy, but can also separate a worker from the purpose. A requester receives a result; the person producing it may not know which system it will enter.
The platform can request multiple answers to check quality or identify bias.5 That does not make truth automatic. It turns human disagreement into a statistical procedure. Consensus can help for a simple category and fail on an ambiguous one. Quality depends on wording, pay, available time, worker profiles and how conflicts are resolved.
Annotation is not a disposable prelude
Research by Clément Le Ludec, Maxime Cornet and Antonio Casilli on annotation between France and Madagascar gives the debate a more precise basis.6 Their study draws on interviews with data workers and companies, as well as two AI systems. It shows that annotators do not merely click: depending on the organisation, they generate data, evaluate outputs, discuss instructions and develop expertise tied to a project.
The research is useful because it does not reduce the issue to “AI takes jobs.” It describes a division of labour and its outsourcing. Tasks essential to systems sold as intelligent are assigned to people who remain outside the product presentation. The authors show annotation as repetitive, underpaid and geographically displaced while still requiring attention and judgement.
This connects to research on invisible crowd work. A study measuring time spent on unpaid activities around tasks — searching, reading instructions, waiting, handling rejections or understanding an interface — shows that the price displayed for a microtask does not describe the full working time.7 The click is the counted part. The work required to become able to click remains outside the count.
The system performs a strange conversion: the more a task is divided, the more measurable it looks; the more measurable it looks, the easier context is to ignore. A company can pay per image and forget the time spent understanding a category. It can count an annotation without counting training, visual fatigue or the dispute over an edge case.
RYBN’s protocols are not neutral best practice
The RYBN project connects human-computer history to six self-defence protocols.1 They should be treated as artistic and political gestures, not as a method validated by an experiment. Their function is to move the viewer’s position: if a system wants work to disappear, what might a participant do to recover legibility, time or power?
A protocol can be an instruction, a détournement rule, a way to document a task or a way to reveal the relation between interface and body. The format is strong because it proposes actions rather than an abstract moral. Its limit is that a situated artwork does not automatically become a policy for a platform, workshop or team.
The distinction between individual protection and collective change is essential. Advising a worker to manage time better does not fix low pay. Teaching someone to recognise data collection does not grant the right to refuse a task. A self-defence tool can help a person understand a constraint without removing it.
The IRZ reading must therefore keep two planes separate. RYBN offers an interpretation: computation is an organisation of gestures, and automation can repackage human dependency as an invisible service. Historical and sociological sources allow us to check who worked, how, under which status and through what controls.
Materiality against the cloud
RYBN’s project belongs to media archaeology because it refuses the story that each new interface erases the previous one.1 The Mechanical Turk, calculation offices, de Prony’s tables and data annotation do not share one economic regime. They share a difficulty: the system wants to present a clean result while production is made from bodies, tools, delays, fatigue and conventions.
DataArt describes computing history through processing, representation and interfaces.8 The triad connects a calculation table to a platform. Labour’s material is not only the person entering a value. It is also the form that imposes a category, the screen that creates urgency, the score that ranks an answer, the format that removes nuance and the archive that preserves or erases a decision.
We can connect this cautiously to permacomputing. Permacomputing is not just “use less electricity”; it asks about lifetime, repair, resources and limits. Applied to data labour, it raises a practical question: can an infrastructure that outsources annotation preserve the knowledge of the people who produced it? If the subcontractor changes, does the expertise leave with the team?
The question is material. An instruction does not exist only in a document; it exists in pay, interface, quality control and the ability to challenge a task. A platform that records clicks but not disagreements produces a poor archive of its own operation.
Learning with bodies, not against them
Recent work on participatory annotation suggests another path: treat annotators as collaborators who can discuss categories, revise instructions and produce situated knowledge.9 This does not dissolve every asymmetry. It changes the status of error. Disagreement is no longer only an answer to discard; it can show that the data model is too poor.
The history of human computers points in the same direction. Langley’s computers were not interchangeable relays between a formula and a sheet. They knew instruments, measurements, methods and how results were used. Their work was embedded in a research environment. Making them visible is not only assigning retrospective credit; it is recognising that a computation chain needs situated understanding.
Digital interfaces often seek the opposite. They want a task clear enough to give to anyone, anywhere, quickly. Standardisation is convenient for production, but narrows the places where someone can report a bad category. The worker becomes the final component of a system that refuses to show its own hesitation.
What human computers reveal now
The common point between a NASA computer and a platform annotator is not that they do the same work. Their contexts, pay, status and technologies differ radically. The common point is more precise: an organisation converts human judgement into a standard step in information processing, then risks forgetting the expertise that makes the step reliable.
Human computers show that calculation has always been collective. Platforms show that the collective can be fragmented until it becomes invisible. RYBN adds a question of form: what happens when that invisibility is represented, replayed or diverted in an artwork?
The answer is not to reject automation. Punched cards, tabulators and computers enabled volumes of work that could not otherwise be handled. The answer is to reject “the machine did it” when the phrase prevents us from looking for the human choices around the machine.
A computable system is a system that has distributed its decisions. Who chooses categories? Who pays for correction? Who owns the data? Who can challenge an instruction? Who receives credit when the result becomes a product? RYBN’s protocols do not answer for workers, and they are not empirical proof. They make the questions harder to erase.
The most useful definition of computer may therefore be the simplest: someone who helps an organisation produce a result by following and interpreting a procedure. As long as systems need data, they will need people to prepare, correct and make sense of it. The problem is not that those people exist. It is that the system keeps operating as if they were only an interface detail.