The fence in the park.
On freedom, limits and speed, from the fairy tale to automated computing systems.
In brief Freedom is not the absence of the fence, but the bounded space in which danger has been excluded in advance. From this follows a simple and uncomfortable thesis: the speed at which we can move, in a story or in a technology, depends on the quality of the limits we have set. Not on their number, but on how visible, proportionate, easy to revise and well understood they are. I start from a dog park, pass through the prohibition in fairy tales, the sacrifice in the legend of Master Manole and the rites of initiation, arrive at the mechanisms by which automated computing systems are constrained today, and stop at the cost of the fence, which nobody gets for free.
"I take my little dog to the dog park because I want him to have freedom, but I don't want him to run into the street. The dog sees the fence and does not go past it. He can play freely, and I know he is safe. The key to moving fast [in AI development] is having the right guardrails."
(The text from which this essay sets out, reproduced verbatim. Keith Fulton, Chief Data Officer and Chief AI Officer at the fintech company Jack Henry)
The cursor that blinked
In 1997 I spent six months in a room in Botoșani where, strictly speaking, I had no business being. I had enrolled in a two-week course, "IBM PC Operator". The course ended, but the room stayed open. There were two computers that worked and one taken apart, an instructor who chose not to notice that I came in every day, and a black screen bearing a single line, C:\>, followed by a cursor that appeared and disappeared every half second.
Nothing appeared on that screen of its own accord. If I did not type, nothing changed. If I typed an exact command, the command was executed exactly. If I got a letter wrong, a terse message appeared, without explanation and without tone, and I was left to work it out. It was, as I would say now, a pure tool: everything that happened began with me and stopped where I stopped.
And yet, even there, on so passive a machine, there was a fence.
If I gave the command that deletes all the files in a directory, the program did not execute it on the spot. It displayed a question, in English, whether I was sure, and waited until I pressed a letter: yes or no. If I tried to prepare the disk for fresh use — which meant erasing everything on it — the message was more emphatic still: all data on the disk will be lost. None of this stopped me doing as I pleased. The fence was not a prohibition. It was a second gate, placed exactly in front of the one gesture that can no longer be undone, and it asked one small thing: to repeat, consciously, what a moment earlier I had done in haste.
Today I believe it was precisely that question which let me experiment. On a computer that everyone in the room depended on, a beginner like me would have been a danger if every mistyped command could have wiped everything with no brake. As it was, I could type fast, I could try commands I did not yet understand, I could read, err, start again. The speed at which I learned in that half-year did not come from an absence of limits. It came from the fact that the one place where a mistake cost a great deal was guarded.
Years later, when I began working with websites and far more complicated machines, I recognised the idea under other names: backup copies, access rights, staging environments. All are variants of the 1997 question. They do not say "don't do it"; they say "do it, but not where you can no longer turn back."
Everything that follows is about this simple structure.
