Modern data feels weightless because it arrives as a spreadsheet row, a JSON file or a value in a database. It copies silently, travels at network speed and appears in interfaces that hide almost all of its making. Even the word encourages the illusion: data, something given.
Alexey Pomigalov’s Nightingale article tells a rougher story. It moves through a marked bone, an administrative tablet from Uruk, Jacquard loom cards, the US census tabulation system and a relational database used to study rock-art signs.1 DataArt’s Retrospect project organises a related history around processing, representation and interfaces, insisting that computing is not only a succession of machines but a succession of decisions about how to make the world manipulable.2
The question is not “did the computer exist before the computer?” That would turn every act of counting into digital prehistory. The sharper question is: what happens to information when it has to be fixed in matter, handed to another person, sorted by an imperfect machine, and checked before it produces a decision? Older processing chains give today’s cloud pipelines a visible anatomy.
Counting is not processing yet
Nightingale begins with a hypothesis about marks and cycles. It discusses a bone with 29 notches, often associated with a lunar calendar, and offers a reading attentive to women’s roles in counting and preserving observations.1 That attribution should not be hardened into certainty: the object and its interpretation remain debated. What is solid for our purposes is the possible function of a mark: externalising memory so that a present observation can be compared with earlier occurrences.
A mark is not yet a database. It becomes useful when a group knows what it means, in which order to read it and which action it permits. A notch can count a day, a birth, a delivery or an animal. Without a shared convention it is a trace; with one it becomes a record.
The same distinction exists in a data warehouse. A column called status is not information simply because it has a name. We need to know who writes it, when, which values are allowed, what absence means and whether “cancelled” describes a decision or an input error. Data is not only a value. It is a value plus a reading protocol.
The move from trace to register creates work. Someone must decide what deserves counting, repeat the observation, record exceptions and preserve order. That work is often called preparation and therefore treated as secondary. It determines what a later machine or analyst can see.
The tablet that imposes columns
The Uruk example is more concrete. Nightingale describes a proto-cuneiform tablet dated around 3300–3200 BCE and associated with accounts of grain and malt.1 The Louvre presents the emergence of writing as connected to administrative needs: recording quantities, goods and exchanges in a society too complex to rely only on people’s memories.3
An accounting tablet does more than preserve a number. It divides a situation into units: a product, quantity, supplier and recipient, perhaps a date or responsible person. The material imposes a format. Clay preserves marks but makes revision difficult. An error cannot be corrected like a spreadsheet cell; it has to be scraped, amended, remade or left as a visible layer of correction.
That rigidity has an advantage. A tablet does not update silently. Corrections, contradictions and traces remain part of the object. Modern databases are more convenient, but they can make a transformation disappear: a migration overwrites a value, a script replaces an identifier, a column is renamed, a table is recalculated. Old material does not guarantee truth; it makes operations harder to hide.
The tabular format that feels natural to us is also a historical decision. Putting information into rows and columns creates a relation between positions. Units become comparable because they occupy the same kind of cell. A spreadsheet does not discover a structure; it asks a problem to enter a structure that humans and machines can read.
The Jacquard loom: when pattern becomes instruction
Nightingale connects Jacquard’s punched cards to the history of programmable calculation.1 The useful claim is not that Jacquard invented the computer. It is that a textile pattern could be described as a sequence of material instructions separate from the mechanism that executed them.
A chain of cards encodes which warp threads should rise. The loom reads the chain and produces repetition. The drawing is no longer only in the worker’s hand or in the finished fabric; it also exists in a physical score that can be stored, transported and reused. The card separates program from machine.
That separation changes the shape of error. A wrong punch is not only a local defect: it can produce an anomaly every time the pattern repeats. Correction means finding the card, the column and the relationship between a hole and a mechanical movement. Debugging already exists, even if it has not acquired the name.
Cards also transmit knowledge. The Smithsonian’s collection history shows how punched cards became a general data-processing medium well beyond textile control.6 You do not pass on only a textile; you pass on a reproducible sequence. Reproducibility does not remove labour. Someone prepares the cards, aligns them, finds breaks, repairs chains and checks whether the resulting pattern matches the intention. Automation moves the gesture rather than making it disappear.
Hollerith and the census as a transformation chain
Hollerith tabulation makes this logic spectacular because it processes people at state scale. The Smithsonian describes a system composed of a punch for entering information on a blank card, a tabulator for reading and adding it, and a sorter for organising cards before further analysis.4 The Census Bureau explains the electrical principle: holes allow pins to complete a circuit and trigger counting.5
The mechanical detail deserves more attention than the legend of the fast machine. A card is not an old file; it is a contract between several gestures. One person reads a form, chooses a category and punches holes. The machine reads a hole pattern. An operator sorts the cards. Another pass counts them according to a different combination. Each step can introduce, preserve or amplify an error.
The output therefore depends on the whole chain, not just the tabulator. A reliable machine can produce a false statistic if the form was ambiguous, a response was misclassified or a deck was mixed. Human checking can catch an implausible value before publication. Processing is not a black box; it is a sequence of translations.
Cards make the sequence visible. They can be counted, moved, dropped, sorted by edge, stored in boxes and compared physically. The failure may be logistical before it is electronic. The medium is simultaneously memory, interface, unit of work and quality-control object.
The system also creates a political possibility: faster counting enables broader administration, but the category selected on the form becomes a statistical reality. A population is not only measured; it is cut into the boxes available. Processing power arrives with a design responsibility.
The work hidden behind the machine
Tabulation is often narrated as manual labour replaced by electricity. That is misleading. The machine automates some operations but creates a workshop of preparation, feeding, sorting, correction and maintenance. Labour is redistributed between people and machines, and some tasks become harder to see.
NASA offers a precise parallel. At Langley, before electronic computers, computer meant a person who calculated. The mostly female teams read measurement films, performed calculations, plotted curves and checked results.7 They used slide rules, magnifying glasses, Marchant or Friden machines and worksheets. The result was not a line emitted by a machine; it was a chain of readings and checks whose steps had to remain interpretable.
This history is not only a feminist correction to computing history. It shows a quality architecture. The computers knew which data to inspect, how to handle cases, when to request a check and how to present a result to an engineer. Their expertise was embedded in methods, tables and team habits, even as “subprofessional” classifications and limited promotion undervalued it.7
When electronic machines arrived, some human computers became programmers. This was less a disappearance than a layer change: instead of executing every operation, they wrote instructions, prepared data and checked outputs. Processing knowledge moved into code, but the need to interpret results remained.
From punch cards to data pipelines
The comparison becomes useful when we stop looking for visual resemblance. A modern pipeline replaces the card with files, messages and distributed tables. Jobs, partitions and keys replace the sorter. Schema tests and dashboards replace the checked worksheet. But the core logic persists: data must be captured, encoded, moved, transformed, checked and interpreted.
What changed is the visibility of operators. The cloud makes it feel as if data travels directly from sensor to model. Between them, people clean, recode, merge, annotate, monitor tasks and respond to anomalies. They are rarely drawn in the pipeline diagram, just as the people who fed and sorted cards are absent from the heroic photograph of the tabulator.
Modern speed and scale make errors harder to locate. A badly sorted deck could be found in a box. A distributed transformation can create millions of inconsistent rows before a summary chart changes enough to attract attention. Materiality did not disappear; it moved into disks, message queues, schema versions, quotas and energy bills.
Old chains give us a simple design rule: each transformation needs an owner, a trace and a way to repeat it. If a file is cleaned, keep the raw version or document what was lost. If categories are merged, preserve the mapping table. If a model is trained on annotations, know who decided ambiguous cases. Reproducibility is not only code; it is an archive.
Rock art and the database as reading instrument
Nightingale ends with Genevieve von Petzinger’s work, which used a relational database to compare geometric signs across 146 French rock-art sites.1 Von Petzinger’s own project documents the comparative catalogue of recurring signs behind that analysis.8 The value is not the simplistic claim that caves have finally been decoded. It is what a data system enables: comparing distant observations once they have been normalised and indexed.
But the database does not speak alone. Someone defines what counts as a sign, decides whether two shapes are the same, records site, period and context, then interprets repetition. A relational structure opens a question while posing it: which patterns exist in the world, and which become visible because a taxonomy made them comparable?
That ambiguity is familiar to dataset teams. A classification enables comparison while eliminating differences. A database is always a proposition about what deserves to be separated or joined. Structured data is not false because it is structured; it becomes dangerous when the structure that produced it is forgotten.
Material is not nostalgia
The history of punched cards is not a model to copy. It is a useful friction. A card, tablet or worksheet reminds us that information has a medium, cost, speed, operators and failure points. Digital interfaces made these properties more flexible, not less real.
When a pipeline is drawn as an arrow from “data” to “insight,” several workshops are probably missing. Who chose the categories? Who transcribed the form? Who repaired the impossible case? Which copy is authoritative? Where is the last readable version? How will anyone know what the column meant six months from now?
Older processing practices do not show that humans were better than machines. They show that every automation rests on a distribution of labour and a material capable of preserving — or erasing — its steps. Data is not only what a system computes. It is also the trace of how a society chose to make the world countable.