The Spreadsheet Was the Constitution
Modern software is quietly conscripted into constitutional work: recording rules, defining authority, preserving institutional memory, and settling disputes.
A co-op thought it was using a spreadsheet. In fact, the spreadsheet was its constitution.
This essay argues that much modern software is quietly conscripted into constitutional work: recording rules, defining authority, preserving institutional memory, and settling disputes. Yet productivity tools lack many of the properties older constitutional materials accumulated over centuries: tamper-evidence, adoption moments, witness, succession, canonical versions, and intelligibility to future strangers.
By contrasting Wikipedia’s governance infrastructure, The DAO’s brittle smart-contract constitutionalism, and the ordinary spreadsheet practices of small institutions, the essay names a missing design layer in software: rules that are binding but revisable. It proposes answerable infrastructure — software that treats some edits not as updates, but as acts an institution may one day have to justify.
A small co-op I once helped used a shared spreadsheet to decide how their weekly stock orders were placed. There was a column for each member, a formula at the bottom that summed the contributions, and a quiet convention — never written down — that you did not change another member’s entries. The spreadsheet ran the co-op as much as the by-laws did. Probably more. When two members fell out, the dispute that ended their working relationship was not about money or principle; it was about whose edit had overwritten whose, and whether the version history could be trusted. The artifact had become a constitution, and nobody had noticed when it happened.
The Category Mistake
This kind of slow conscription — software designed for one purpose ending up doing the work of another — is not an accident, and not a story about a small co-op picking the wrong tool. It is the predictable consequence of a category mistake that runs through most modern software, and through the discourse around it: the assumption that a productivity tool and a constitutional material are the same kind of thing. They are not, and the difference is older than any of the software involved.
The terrain is well-mapped. Lessig has argued for two decades that code regulates behavior the way law does [1, 2]; Doctorow has extended the argument into the political economy of platform decay [3]; the CSCW tradition, going back to early work on groupware [4], has documented the ways software lands inside groups and quietly rearranges them. Ostrom’s account of the institutional patterns small groups develop to manage shared resources [5] describes practices that assume materials with properties most software does not provide, and networked-production theory supplies the political backdrop [6]. What the literature does well is name the phenomenon: software is governance infrastructure whether or not it is sold as such. What it does less well, and what I want to take a turn at, is the materials — to ask not what software regulates, but what it is made of, what its predecessors were made of, and why the difference matters for design.
What Paper Knew
By constitutional material I mean the substrate on which a group writes down the rules of its own life: the by-laws, the minute book, the signed agreement, the witnessed vote, the canonical copy in the safe, the registrar’s ledger, the seal pressed into wax. None of these are software. All of them are technologies. They were not designed to be constitutional; they accumulated the properties that suited governance over centuries of selection, in much the same way medical instruments accumulated sterility or kitchen knives accumulated handle ergonomics [7].
Paper records did not start out tamper-evident. They were made tamper-evident, by inks that bled when scraped, by bound volumes whose missing pages announced themselves, by signatures whose forgery was a known crime, by seals whose breakage was visible from across a room. The minute book did not start out with the property that you could re-read it ten years later and know what was decided; the conventions of minute-taking were honed for that purpose by generations of clerks whose institutions depended on them. Bowker and Star’s account of classification infrastructures is, in part, the story of how mundane materials accumulate the social and epistemic properties their users come to depend on, often without those properties being named [8].
The properties I want to foreground are six. The list is mine — a careful taxonomist might carve differently, or add others — but it is the one the design argument that follows will turn on. A constitutional material is tamper-evident: alterations announce themselves, even when they cannot be prevented. It supports a canonical version: there is one real copy, and everyone in the institution knows where it lives. It admits an adoption moment: a perceptible act — a signature, a vote, a seal, a read-aloud-and-corrected minute — at which a draft becomes binding. It accommodates witness: third parties whose presence at the adoption moment makes the act legible later, when the principals are dead or unavailable. It survives succession: the material outlives any particular person, and the chain of custody by which it has passed from one generation to the next is itself part of the record. And it permits review by future strangers: someone with no context can return to it years later and reconstruct what happened, because the conventions of the material are stable across that time.
These six are not features of paper as a chemical substance. They are deposits left by centuries of institutional use. An institution running on paper inherited them whether or not it understood them. An institution running on a shared spreadsheet inherits almost none of them, and inherits, in their place, properties that paper did not have: silent revision, vendor authority, automatic edit logs that may or may not be admissible, a canonical version that is whichever copy the server happened to broadcast last.
This is not a complaint about software. Spreadsheets are excellent at the work spreadsheets were designed for. Almost none of that work is constitutional. The mistake is in the moment of conscription, when the spreadsheet stops being a spreadsheet and starts being the place where a group writes down its rules — and nothing in the tool, the marketing, the documentation, or the ambient discourse marks that moment as one a designer should have designed for.
The Conscription
The pattern, in my experience and in the literature, is consistent. A general-purpose tool is adopted for a narrow purpose. It works well enough at that purpose. The narrow purpose adjoins a slightly broader one, and the tool stretches to fit. The broader purpose adjoins something close to governance. By the time the tool is doing constitutional work, no one has chosen for it to.
A few mechanisms recur. The most common is codification of the previously informal: practices that lived as conventions, with all the slack conventions allow, become hard constraints once they are encoded. The co-op’s convention “you don’t change another member’s row” had texture in practice. You could fix a typo if the row’s owner was on vacation. You could update an order on someone’s behalf if they texted you. You could rearrange rows when the layout changed and tell people afterward. When the convention was translated into the spreadsheet’s permission system, the texture disappeared: the system had two settings, edit and no-edit, and could not tell the difference between vandalism and a friend covering for someone. The encoded version was tighter than the convention; tightness is not the same property as faithfulness.
Alongside codification, the tool reshapes the cost of operations asymmetrically. In the co-op’s spreadsheet, adding a row was a click; removing one would break the formula at the bottom and was therefore not done. Old products accumulated as ghost rows with zeros. The co-op had decided, at various points, to stop carrying particular items, but the spreadsheet had no place to record those decisions other than the zeros themselves. Adding a new member was a new column; removing a departed member would have required rewriting the formulas, so departed members’ columns stayed too. The order of the columns became a fossil record of every person who had ever joined the co-op, in the order they had joined. Without anyone deciding, the layout had become a roster. Seniority had become a function of column position — a constitutional fact the institution had never voted on.
Meanwhile, the tool produces archives no one chose to keep. Chat logs, edit histories, access logs, drafts, suggestions, comment threads. In the co-op’s case, every comment ever made on a cell was preserved, and the cell’s comment thread was visible to anyone who hovered over it. A heated exchange from a difficult month — about a member who had under-contributed and another who had said something unforgivable about it — was still legible the next year, after the two had reconciled. No one had decided to keep it. No one knew how to remove it without losing the cell’s revision history, which the treasurer had come to depend on. The Drive folder was the archive, and it was an archive whose retention policy nobody had set.
Underneath all of this runs the slowest and most consequential mechanism: the redistribution of power between the institution and its vendor. The vendor controls the features, the pricing, the default settings, the data formats, and the continuity. When Google changed the default sharing setting at some point in the spreadsheet’s life and the link became, for an afternoon, more permissive than the co-op had intended, the co-op’s privacy practices changed too — until somebody noticed. When the version-history UI was redesigned, the evidentiary practices that had evolved around the old UI became unreliable in ways no one could catalogue. This is the structural backdrop to Doctorow’s argument about platform decay [3]: bargaining position drifts, slowly at first, then all at once, in the vendor’s direction. The vendor’s default was the amendment, and no one had voted.
None of this requires bad intent. It is what happens when general-purpose tools become load-bearing parts of structures that needed bespoke ones, and when no design tradition exists for the bespoke version.
Why the Gap Stays Invisible
Most institutions do not notice they are using software as constitutional material until something forces them to. A trust breaks. A founder leaves. A vendor changes a default. The board is asked to prove that something happened. At those moments, the spreadsheet’s edit history is consulted, the chat log is searched, the shared folder is audited — and the institution discovers, sometimes too late, that the material on which its life had been recorded did not have the properties it had come to assume. The failure mode is not catastrophic; it is forensic. The records are there, mostly, but they cannot do the work the institution has come to need from them.
The invisibility has a structural cause. Productivity software is sold, reviewed, and benchmarked on a different axis than constitutional material. The thing being optimized is the speed of getting things done — and the friction of constitutional material is, exactly, the kind of thing that gets in speed’s way. A tool that asked “are you sure?” before every edit, that required a witness for every adoption, that produced a canonical export of the day’s decisions, would lose every productivity benchmark to a tool that did none of those. The market sorts on speed. Institutions sort on something else, but they buy on speed.
Star’s observation that infrastructure becomes visible upon breakdown applies here with unusual force [9]: as long as the spreadsheet does what the co-op needs, no one asks whether the spreadsheet is the kind of thing that should be doing it. The conditions for that question are usually conditions in which the answer comes too late.
There is a related point about who is in the room. Constitutional materials, in their paper era, were typically chosen by people whose job was governance: clerks, registrars, lawyers, secretaries of associations. Software, in its modern era, is chosen by whoever has admin access to the workspace. The role that used to think about constitutional materials has, in most small institutions, no software equivalent. The IT person is not the registrar. The founder is not the clerk. The choice is delegated by default to whoever signed up for the trial, and the constitutional consequences are inherited later by people who made no decision at all.
Wikipedia, the DAOs, and the Layer Between
It is worth dwelling on the case where the conscription did not happen, because the institution and its constitutional material were built together. The clearest example I know is Wikipedia [10, 11].
Wikipedia’s governance lives, by deliberate design, in software the institution itself controls. The talk pages, the article histories, the protection levels, the request-for-comment process, the arbitration committee’s records — these are not productivity features bolted onto an encyclopedia. They are constitutional material, designed as such, evolved through long argument inside the community that uses them. The fact that anyone can re-read a 2007 dispute about the deletion of an article and reconstruct what happened, who argued what, and how the decision was reached, is not an accident of MediaWiki’s logging. It is the deliberate output of a design tradition that took its constitutional role seriously, often before the people maintaining it had a vocabulary for what they were doing.
The cost was substantial. Wikipedia’s governance software took years to evolve, and parts of it remain awkward. The community paid for it in arguments, forks, exhausted volunteers, and a technical debt that other projects, working from off-the-shelf tools, were spared. What it bought, in return, was a constitutional material that has survived two decades, multiple generations of editors, the departure of its founders, and the rise and fall of every adjacent platform. The records of 2007 are still readable in 2026, by strangers, in a form the strangers can mostly understand. There is no shared spreadsheet about which one could say the same.
Wikipedia is not the only attempt. There are deliberation tools designed with constitutional weight in mind from the start — Loomio, Polis, the various decision platforms built for civic and cooperative use — which serve specific institutions well at modest scale. There are also the governance experiments built on blockchains: DAOs whose rules live in smart contracts, voting systems that record their adoption moments on-chain. Both deserve attention, but the blockchain experiments are worth dwelling on, because they carry the constitutional ambition farther than any other software tradition has, and the place they break is instructive.
The clarifying case is The DAO. In April 2016, an investment vehicle of that name was deployed as a smart contract on the Ethereum blockchain. By late May, more than eleven thousand participants had contributed ether worth roughly $150 million at then-current prices, making it one of the largest crowdfunding events in history. The contract specified, in code, the rules by which the DAO would solicit proposals, accept votes, and disburse funds. By every formal property the previous section enumerated, this was constitutional material in its strongest possible form. Cryptographic tamper-evidence was complete; witness was global and continuous; succession was guaranteed; the canonical version was provably the canonical version. A team of clerks could not have produced a more rigorous constitutional record if they had worked for a century.
On 17 June 2016, an attacker exploited a recursion bug in the contract and began draining the funds. The contract executed exactly as written; within hours, several million ether had moved out of the DAO’s main address into a child contract the attacker controlled. By the rules of the constitutional material, the transfers were legitimate. An open letter circulated shortly afterward — signed, or claimed to be signed, by the attacker — arguing that the funds had been acquired “legally” under the contract’s terms, and threatening legal action against anyone who tried to seize them. The argument was difficult to refute on the constitutional material’s own terms. The contract said what it said. It had executed.
What happened next is the part the essay needs. The Ethereum community debated for weeks whether to do anything. A faction calling itself “code is law” argued that the constitutional material had to be honored: reversing the transfers would be a far more serious breach of the institution’s principles than letting the attacker keep the funds. The larger faction argued that the institution — meaning the people, not the contract — had not consented to what had happened, and that the contract’s execution was therefore not legitimate in any sense the institution recognized. On 20 July 2016, the larger faction prevailed. The Ethereum blockchain was hard-forked at block 192,000 to move the funds in the DAO’s address to a recovery contract from which the original contributors could withdraw. The minority who refused to fork carried the original chain forward as Ethereum Classic. The institution preserved itself by abandoning its constitutional material.
The interesting point is not that the contract had a bug. Bugs are universal and uninteresting. The interesting point is the structure of the response. The institution had no way to disagree with its constitutional material from inside it. The only available revision was a fork. A fork is a much heavier act than a revision; in a paper-era institution, the equivalent would be drafting an entirely new charter rather than amending the old one, and persuading the membership to ratify the new charter while the old charter still bound them. The DAO’s design had assumed that the rules and the institution were the same thing, and that nothing else was needed. When the rules produced a result the institution rejected, the design supplied no machinery for the institution to override the rules while remaining the same institution.
This is the same failure as the productivity-tool failure, in a different direction. Productivity software treats the relationship between rules and institution as a non-issue because there are no rules to speak of; the spreadsheet that ran the co-op had no concept of binding state. DAO software treats the relationship as a non-issue because the rules are everything; the smart contract that held the DAO’s ether had no concept of an institution that might disagree with its execution. Both designs assume away the layer where most institutional life actually happens — the layer where rules are real but revisable, where the institution is bound by the rules but not identical to them, and where the act of changing the rules is itself a constitutional act. Wikipedia’s governance has this layer, and that is what it is for. Most other software does not.
I do not think every small institution can or should build its own MediaWiki. The cost is not transferable. But the example tells us that the gap I have described is a design gap, not a property of software in general. The space between Wikipedia’s gradualism and the DAO’s automation is largely empty, and that emptiness is where most small institutions actually live.
Designing for Constitutional Weight
Designing software as constitutional material is not a checklist of features; it is a sequence of design moves, each with a tradeoff most products would prefer not to take. The moves are easier to see through one concrete interaction.
Picture the co-op deciding to change its order policy: from a maximum of three orders per member per week to one. In a spreadsheet built for constitutional weight, the change would not happen at the speed of a keystroke. The proposing member would mark the cell as a draft, attach a question to it phrased explicitly enough that it could be answered yes or no, and stop. In every member’s view of the artifact, a banner would appear:
+----------------------------------+
| ADOPTION PENDING |
+----------------------------------+
| Q: Limit weekly orders to 1 per |
| member? |
| |
| Change: F2: MAX_PER_MEMBER 3->1 |
| |
| Proposed by Barish, 2026-04-12 |
| |
| Signatures (2 of 2 needed): |
| [ Sign as Carmel ] |
| [ Sign as Eagon ] |
| |
| Reverting requires the same |
| procedure. |
+----------------------------------+Until two members sign, the cell shows the old value. After they sign, the cell shows the new value, and below it — visible on hover, exported with the file — a record of the question, the proposer, the signatories, the timestamps, and the prior value. Subsequent edits to that cell are flagged as post-adoption changes. Reverting requires the same signing procedure. The interaction is slower and more awkward than autosave. The awkwardness is the point: it is the interface translation of a witnessed adoption moment, designed so that the act of binding costs more than the act of editing. Five design moves, each present in the sketch, are worth naming.
Make the cost of binding higher than the cost of editing
Most software treats every state change as the same gesture; the constitutional move is to introduce a gradient. A click should not feel the same as a signature. The two-signature requirement in the sketch is one shape of the gradient; a longer drafting period is another; explicit witnesses is a third. Generic confirmation dialogs are not a shape — users learn to dismiss them, and dismissed friction is no friction at all. The friction has to be meaningful, which usually means that what costs more is the thing that the institution wants to be expensive: not the keystroke, but the act it represents.
Answer the question of which version counts before any feature work
Most software ducks this. The canonical version is “whichever the server broadcast last,” and the question of what happens when two clients edit the same cell at the same time is a conflict-resolution UI. For constitutional material, the question of what counts has to be answered at the data layer, before the UI has anything to render. The local-first research tradition [12] has worked out one set of answers — CRDTs, version histories with explicit merge points, content-addressed storage — that productivity software has not yet absorbed. Other answers are possible. The work of choosing one is non-optional.
Integrate witness into the artifact, not into a parallel audit log
Most software treats audit as a feature for compliance: a log file accessible to admins, separate from the record of what happened. The constitutional move is to make the witness part of the record itself. The two signatures in the sketch are not in an audit log; they are the binding of the change. Without them, the change does not exist in the artifact’s authoritative state. The witness and the act are the same record, and removing the witness would mean removing the act, which would be visible as such.
Design the export
Software’s relationship with its institution is mediated through what the institution can carry away. Most software treats export as a feature, often a poor one — a CSV missing half the structure, a PDF rendering of what was on the screen. For constitutional material, export is not a feature. Export is the form in which the institution leaves the tool, and the form has to preserve everything the tool’s death would otherwise destroy: the adoption records, the signatures, the version history, the conventions by which strangers will read it. This is the ground that local-first software is most directly working on, and the ground productivity software has the strongest incentives to neglect.
Design for the tool’s death
An archive is constitutional only if a stranger can return to it later and reconstruct what happened. The conventions that allow this — naming, structure, format stability — have to be more durable than the tool itself. Designing for review by future strangers means designing for the conditions in which one’s own tool is no longer running. Designing for those conditions means accepting that the tool’s role in the institution is bounded. Most software roadmaps do not accommodate this comfortably.
A working name for the stance is answerable infrastructure — software that knows it might be answered to. The five moves are not exhaustive, and they overlap. They share a posture: the tool acknowledges that some of its records are load-bearing for a group whose life depends on them, and accepts the design constraints that follow. The adoption banner above is one rendering of that posture in a single product category. Other categories will need other renderings. What the renderings share is the recognition that the institution is the user, that the institution has a future the tool may not be part of, and that the artifact has to make sense to that future without the tool’s help.
The Tension That Doesn’t Dissolve
A tension runs straight through this kind of design, and pretending it dissolves would be the kind of move I have spent the essay arguing against.
The friction of constitutional material is not waste. It is what makes the act binding. The signature is slow. The witnessed adoption is awkward. The read-aloud-and-corrected minute is, by modern standards, a tedious meeting practice. These frictions are not bugs that paper failed to optimize away in five centuries of trying. They are the constitutional content of the material, made physical. Remove them and the property goes with them; the smooth fast unanimous click is, exactly, not a vote.
Software design has spent forty years removing precisely this kind of friction, and the removal has been celebrated as good design. There is a real, structural tension between great UX and constitutional weight, and the tension is not resolved by clever interface tricks. A tool that adds friction at the right moments will lose, in any side-by-side demo, to a tool that adds friction nowhere. The market does not reward weight; it rewards the appearance of effortlessness, even — especially — at moments where effortlessness is the wrong property.
The honest responses are narrow. One is to be clear about which moments inside a tool are constitutional moments and to add weight to those specifically — to recover the older intuition that not all clicks should feel the same, and that some clicks should feel like signing something. The other is to accept that some tools should not try to be productivity software at all, and that the tradition of constitutional material — slow, formal, careful, deliberate — has things to teach the small handful of tools that take governance seriously, even at the cost of feeling old-fashioned. Neither response will save a startup’s growth metrics. But the goal here is not arguments that are good for growth metrics; the goal is arguments that are good for software, and good for the institutions software has been quietly conscripting for the past two decades.
A Working Stance
The hardest part is that the choices that matter most are invisible at the moment they are made. A default about who can edit, an unstated retention policy, a quiet change in a third-party API — these settle into the institution’s bones long before anyone names them as policy. By then they are the institution.
I want to return, briefly, to the co-op. After the dispute, the surviving members tried to fix what had broken. They wrote a rules document — in Google Docs, on the same Drive — that named the conventions the spreadsheet had been silently encoding: who could edit whose row, when one member could update another’s, how to retire a column when a member left. The document was thoughtful. The spreadsheet did not know it existed. The document could be edited without affecting the spreadsheet; the spreadsheet could be edited without consulting the document. Within a year the two had drifted, and the next conflict surfaced the drift. The institution had recognized that it needed constitutional material and had produced some, in the only form the productivity-tool ecosystem made available: another document, in another folder, with the same problems as the first. The recognition was real; the materials were not equal to it.
Going back to paper is not the answer. The convenience of software is too real, the institutional dependence too deep, and the paper version of bureaucracy had its own failures, exclusions, and capture by those who could afford clerks. What we can recover is the attention that craft paid to its own constitutional role: that the choice of material was a constitutional choice, and that some choices accumulated the properties governance needed and others did not.
The notaries, registrars, town clerks, and archivists of the paper era are mostly gone, and software has not developed equivalents. There is no profession whose job is to ask, of a productivity tool a small institution is about to adopt, whether it is the right material for the institution’s life. The lack is not a market gap. It is part of why the conscription proceeds invisibly: a profession would have created vocabulary and forced choices into the open. Without one, the burden falls on designers, and on the few users who notice the conscription as it happens.
The ambition is small: software that knows it might be answered to, and that leaves the institution something to answer with. The spreadsheet was the constitution, and the co-op did not know. Next time, perhaps, the tool will.
References
-
Lawrence Lessig. 1999. Code and Other Laws of Cyberspace. Basic Books. cite
-
Lawrence Lessig. 2006. Code: Version 2.0. Basic Books. cite
-
Cory Doctorow. 2023. "The 'Enshittification' of TikTok". Wired. cite 1, cite 2
-
Jonathan Grudin. 1994. "Groupware and social dynamics: Eight challenges for developers." Communications of the ACM 37, 1, 92-105. cite
-
Elinor Ostrom. 1990. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge University Press. cite
-
Yochai Benkler. 2006. The Wealth of Networks: How Social Production Transforms Markets and Freedom. Yale University Press. cite
-
Henry Petroski. 1992. The Evolution of Useful Things. Vintage Books. cite
-
Geoffrey C. Bowker and Susan Leigh Star. 1999. Sorting Things Out: Classification and Its Consequences. MIT Press. cite
-
Susan Leigh Star. 1999. "The Ethnography of Infrastructure." American Behavioral Scientist 43, 3, 377-391. cite
-
Joseph M. Reagle. 2010. Good Faith Collaboration: The Culture of Wikipedia. MIT Press. cite
-
Andrea Forte, Vanessa Larco, and Amy Bruckman. 2009. "Decentralization in Wikipedia governance." Journal of Management Information Systems 26, 1, 49-72. cite
-
Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. 2019. "Local-first software: you own your data, in spite of the cloud." In Proceedings of Onward! 2019, 154-178. cite