From Dishes to Clatter
There is a moment that happens on a busy service night that most people in a restaurant never see.
A plate arrives at the pass. The kitchen is behind it, hot, loud, running at capacity, operating under a pressure that the dining room will never feel and was never designed to feel. The table is in front of it, expectant, relaxed, paying for an experience that appears effortless.
Between those two realities stands one person whose entire job is to make them compatible.
I spent years in that position. Head waiter. Maître d'. The interface layer between a high-performance production system and the people it exists to serve. I was not in the kitchen. I was not at the table. I was the translation layer, reading the pressure on one side, managing the experience on the other, and making sure that what happened behind the pass never reached the table as anything other than a perfect plate arriving at the right moment.
This is a precise and demanding role. Not because either side is difficult to understand in isolation, but because they operate on entirely different logic. The kitchen measures success in execution: correct temperature, correct timing, correct plate. The table measures success in experience: seamless, effortless, invisible effort. These two definitions of success are not naturally compatible. Making them compatible, in real time, under pressure, every service. That is the job.
What I learned in that position was not how to cook. It was something more fundamental: how to be the reliability layer between two systems that don't fully speak each other's language.
And part of that role, the part that never gets written down but gets passed on anyway, is learning what a standard actually looks like when it's real rather than performed.
I watched head chefs who brought the same precision to a staff meal at the end of service that they brought to the tasting menu. The same knife work. The same attention to every element on the plate. The station wiped with the same care at 3am, after a full service with no one left to impress, as it was set at the start of the night. The clatter of a clean section being reset, knives on steel, boards wiped, surfaces squared, not for the next customer, but because that is how you work.
That is not perfectionism. That is the only way to operate when the standard is genuinely yours rather than borrowed from the occasion. Shortcuts are a habit. Habits don't check who's in the room before they fire. If the standard changes depending on the audience, it was never really the standard.
I also learned the other half of the interface layer role: how to absorb failure on one side without propagating it to the other.
When the kitchen is behind, the table doesn't know. When a plate comes up wrong, the recovery happens at the pass, not at the table. The interface layer takes the hit, finds the solution, and delivers the experience intact. Not by hiding the problem. By handling it at the right layer.
This is error handling. Not as a software concept, but as a discipline learned standing between a kitchen and a dining room on a Friday night.
The standard is for yourself. Not the audience. Not the occasion. That is the only version of a standard that holds under pressure.
These two things, the standard that doesn't change with the audience, and the error handler that absorbs failure at the right layer, became the foundation of how I build software. Not as metaphor. As operating principle.
Act 2: The Festival
From the restaurant I moved into large-scale live events. And if the restaurant taught me about interface layers and error handling at the micro level, festivals taught me the same lesson at a scale that changes everything about how you think.
A large-scale festival is not one system. It is dozens of independent systems, each complex in its own right, each operating at a different scale, each with its own internal logic, all interfacing with each other at the edges, simultaneously, in real time, with no pause button and no rollback.
Consider what runs simultaneously on a single festival day:
- Perimeter security. Managing the outer boundary, processing thousands of legitimate entries per hour while maintaining integrity against the unknown. Too tight and the system seizes. Too loose and everything inside is compromised.
- Production logistics. Trucks, equipment, consumables, timing windows measured in minutes. The ring road that the public never sees, that everything depends on.
- Power infrastructure. Multiple independent grids serving multiple stages, each with its own load profile and failure modes.
- Medical and emergency services. Operating on their own protocols, needing to interface instantly with every other function the moment they are needed.
- Artist liaison. Managing the humans at the centre of the operation, each with their own requirements, their own timelines, their own definitions of ready.
- Crowd management. Reading and responding to the behaviour of tens of thousands of people, none of whom are following a script.
- Multiple stages. Each a complete production operation in its own right, running in parallel, each with audio, lighting, power, crew, and schedule interdependent with every other stage.
Walk the site during load-in and the clatter is everywhere. Forklifts reversing, generators kicking to life, rigging crews calling overhead, radio bursts layering over each other across a dozen channels. It is not chaos. It is dozens of independent systems, each precise within its domain, composing into something coherent through structure and trust.
Each function is staffed by professionals who know their domain. Each operates with significant autonomy. Each makes hundreds of decisions per hour that you will never see and could not have anticipated.
You cannot micromanage this. Not philosophically, physically. The system is too large, too fast, too distributed. You cannot be everywhere. You cannot see everything. You have to trust each function to execute within its domain.
But trust without verification is how cascades start.
So what you build, what you have to build, is a coordination overlay. Not control. Not interference with the autonomy of each function. A layer that sits above the independent operations and gives you signal when something needs attention. Clear escalation paths. Defined interfaces between functions. Checkpoints at the moments that matter. A shared operational language so that when security needs to talk to medical needs to talk to production, they are compatible at the edges even though they are autonomous in the middle.
The site operations manual is not a rulebook. It is a trust architecture. Here are the principles every function operates within. Here is how you escalate. Here is what a handoff looks like. Here is what you do when something breaks before you call it up the chain. Every function has autonomy within that architecture. The architecture exists so that autonomy doesn't become chaos.
This is distributed trust at scale. And once you have built it and operated it, once you have felt what it is like to watch dozens of independent complex functions execute simultaneously toward a single coherent goal, you cannot think about software systems any other way.
Act 3: The Rehearsal Festivals Never Get
There is one thing that makes festivals uniquely hard that nobody talks about.
A festival happens once a year. Sometimes less. The production for this year's event is built on the memory of last year's, on the debrief documents, on the lessons that got written down, and most importantly on the relationships with the people who were there.
The supplier who knows how the power draw behaves on the main stage at peak load. The security lead who remembers the crowd flow problem at gate three. The production manager who carries in their head the timing sequence that isn't written anywhere because it evolved across three years of events and nobody ever had time to document it.
Human trust is the persistent memory of a festival. The relationships are not a nice-to-have. They are the verification layer. They are how the system remembers what the documents don't capture and what the new team members don't know yet.
This works. But it is fragile. People leave. Memory fades. The institutional knowledge that took three years to build walks out the door when the key person moves on.
And you cannot practice. You cannot run the show on a Tuesday afternoon to see where it breaks. There is no staging environment. There is no rollback. The next test is the next event, in front of fifty thousand people, with no undo.
That feeling, when something goes wrong on-site and you know there is no way to rewind it, only manage it forward, is a particular kind of operational stress that stays with you. You made the call, the window closed, and now you live in the consequences until the show ends. Every experienced event professional carries a library of those moments. They are how you get good. They are also exhausting.
Software has something festivals would kill for.
You can rehearse.
Not once. Not annually. Thousands of times. You can run the show in a Docker container at 2am on a Wednesday. You can simulate the failure mode that would happen once every five years and make it happen on demand, this afternoon, and watch exactly how the system responds. You can break every component deliberately, observe the cascade, fix it, and break it again, before a single user ever sees it.
The undo button that live events never had. The staging environment the festival floor cannot offer. The ability to make every mistake in private, cheaply, and learn from it before the gates open.
This is what automated testing actually is. Not process. Not bureaucracy. Not a metric to put in a README. The rehearsal the festival never gets.
And this changes the philosophy of how you build components entirely.
In a festival, you build trust with your suppliers because you cannot control the quality of every component from the inside. You build the relationship because the relationship is the quality assurance mechanism. You know the supplier delivers because you have worked with them across enough events to have seen them deliver under pressure.
In software, especially when you are building the components yourself, you do not have that luxury and you do not need it. You build every component as if it is the only component that matters. Not because someone is watching. Not because it is customer-facing. Because a distributed system is only as reliable as its least reliable part, and you are the supplier now.
And then you test it. Not just the happy path. Not just the integration. The edges. The failure modes. The race conditions. The malformed input. The network partition. The thing that will happen exactly once in production at the worst possible moment. You make it happen in the test suite on purpose, today, so that it is handled before it is real.
You write the test for the failure you hope never happens. Because hope is not an architecture.
This is the philosophy behind the 0k-sync test suite. 662 tests across the workspace, the language bindings, and the chaos suite. Each one is a rehearsal of a failure mode that never reached production. The chaos tests simulate network partitions, relay failures, and concurrent sync conflicts across a distributed three-machine mesh. Not because those failures are common. Because the festival happens once, and the one time it happens, you need to know the system has already run that scenario and knows what to do.
The festival operator builds relationships to carry institutional memory. The software builder writes tests to make institutional memory structural. Both are doing the same thing: ensuring the system remembers how to handle what it hasn't seen yet.
Act 4: When the Nervous System Fails
Underneath every ring, every function, every stage, every interface, holding all of it together, is communication.
Not a feature of the operation. The nervous system of it. The thing that makes coordinated action across a complex, distributed, high-stakes system possible at all.
A bad day on comms is a bad day for everyone.
Not metaphorically. Literally. When the radio dies, or the channel gets corrupted, or a message gets misheard in the noise of fifty thousand people, the operational cost is immediate and physical. You stop what you are doing. You find another way.
You run.
I have run across festival fields more times than I can count. Not because something catastrophic was happening, often because something trivially small needed to be communicated and the channel that should have carried it had failed. A production call that didn't get through. A changeover time that got lost in static. A simple confirmation that never arrived.
And while you are running, you are not operating. The system is still running. The variables are still firing. The crowd is still moving. The stages are still live. Every other function is still executing. But you are crossing a field on foot because the nervous system went down.
This is what compromised comms actually costs. Not just the information that didn't get through, but every operational decision that couldn't be made while you were compensating for the failure. The divergence from operations compounds. One broken radio becomes a delayed production call becomes a late stage changeover becomes a crowd flow problem. The cascade starts small and invisible. By the time it is visible, you are already behind it.
The lesson is not "build better radios." The lesson is: the reliability and integrity of your communication infrastructure is not a secondary concern. It is the operation. Everything else depends on it.
And there is a second lesson that took longer to surface.
On a festival site, radio communications are open. Unencrypted. Everyone on the production channel hears everything. This works, not despite the openness, but because of specific conditions that make openness temporarily safe:
| The Festival | Software Systems | |
|---|---|---|
| Persistence | Evaporates, 8 hours and it's over | Permanent, logged, stored, queryable forever |
| Audience | Vetted, badged, physically present | Global, anonymous, unverifiable |
| Trust | Contextual and visible | Cryptographic or assumed |
| Window | Finite, the event ends | Infinite, the system never ends |
| Failure cost | Recoverable within the event | Permanent, breached data stays breached |
Remove any one of those conditions and the model collapses.
I spent twenty years operating in systems where open comms were safe because the conditions made them so. Then I started building software and realised I had been thinking about the wrong problem.
The question is not how to communicate. It is who can see the communication, for how long, and what can they do with it.
Act 5: Building For It
When you have spent years standing at the interface layer of complex systems, translating between the kitchen and the table, coordinating between production and the crowd, absorbing failure at the right layer so it doesn't propagate to the wrong one, you eventually sit down and ask the question every operator asks when they finally have time to think:
What actually works? And why?
The answers are not clever. They are the same answers the festival floor produces, written down and applied to software.
Write the site operations manual before the stages go up.
On a festival, nothing moves until the operational framework is in place. The escalation paths. The interfaces between functions. The shared language that makes security and medical and production compatible at the edges even when autonomous in the middle. You do not bolt coordination onto a running system. You build it before the system runs.
In software this means documentation before code. Architecture before implementation. The principles every component will operate within, written down before the first dependency is added. Not as bureaucracy, but as the thing that makes autonomous functions composable rather than chaotic.
This is what AGENTS.md is. The site operations manual for an AI-assisted project. Written first. Read at the start of every session. The shared context that means each new session doesn't start from zero, the same way a new shift on-site gets a proper handover rather than a shrug and a "figure it out."
Measure twice, cut once. Not as a productivity tip. As an operational principle learned from systems where measuring once and cutting twice has consequences you feel in your legs on a festival field.
Trust every function. Build the verification overlay in.
You cannot micromanage a festival. You cannot micromanage an AI coding assistant. Both are too fast, too capable within their domain, and too distributed for constant supervision to be practical or useful.
What you can do, what you have to do, is build the coordination layer. The same overlay that makes a festival function, applied to AI-assisted development.
The operations briefing before anything moves. Autonomous execution within the domain. The production manager's radio check at the end of the critical window. The clean handover to the next shift.
That structure, PRE-FLIGHT, IMPLEMENT, VALIDATE, CHECKPOINT, is Jimmy's Workflow. Not a methodology invented at a whiteboard. The festival floor, written down and applied to the terminal.
The 11 Core Principles are the site operations manual itself. KISS, TDD, Documentation Standards, No Shortcuts, Rules Persist. Each one is the distillation of a failure mode that cost something before it became a principle. They exist so that every function, every AI session, every component, every collaborator, operates within a compatible framework at the edges even when autonomous in the middle.
Build the communication layer so it cannot be compromised.
The gate guard at the production entrance does not need to know what is in the truck. They need to know one thing: is this truck authorised to pass?
Authorisation without knowledge. A gate guard who doesn't know what's in the truck cannot be pressured to reveal it. Cannot be compromised by someone who wants to know. Cannot leak what they never had.
The relay in 0k-sync is that gate guard. It routes ciphertext between devices, opaque blobs it cannot read, cannot interpret, cannot betray. No accounts. No key escrow. Keys derive from your passphrase and never leave your devices. The relay sees authorised traffic passing through an interface. It does not see what the traffic contains.
The relay is a dumb pipe.
It cannot betray what it cannot read.
The transport layer uses Clatter, a Rust crate, not mine, but chosen deliberately. A pure Rust, no_std implementation of the Noise protocol framework with post-quantum hybrid support. Classical Diffie-Hellman and post-quantum KEM in the same handshake. True hybrid security: an attacker must break both the classical and post-quantum components to compromise the session.
I didn't name it. But when I found it, the name felt right.
Not because quantum computers are here today. Because the habits you build now determine the systems you ship in five years. The station gets wiped at 3am even when no one is watching.
The Name
Clatter is the sound of a kitchen resetting after service. Every station squared, every surface wiped, the controlled noise of a standard being maintained for its own sake.
It is the sound of a festival site during load-in, forklifts, generators, rigging calls, radio bursts, dozens of independent systems composing into something coherent through structure and trust.
And it is the name of the Rust crate at the transport layer of 0k-sync. The primitive that keeps the nervous system of the system private, resilient, and quantum-safe.
From dishes to Clatter. From the pass to the protocol. From the interface layer of a restaurant to the interface layer of a zero-knowledge sync relay.
The word was there from the beginning, in the kitchen, on the festival floor, long before I knew what I was building toward. The crate already had the name. It fit because the principle was already the same.
No shortcuts. The standard is for yourself. Build the trust architecture first. Test the failure modes before they are real. Make the communication layer structurally private. Absorb failure at the right layer so it doesn't propagate to the wrong one.
Build everything as if it matters.
Because it does.
This Is What Ydun Is
Applied R&D and systems practice. Local-first, privacy-native, documented before it is coded. Not because those are fashionable positions, but because they are the conclusions that twenty years of operating complex systems at scale inevitably produces when you write them down.
The publishing practice that follows this piece goes deeper: the methodology, the tools, the systems, the findings from building in production across Rust, TypeScript, decentralised systems, and cryptography with AI as a genuine development partner rather than a shortcut.
But it all starts here. With a chef at 3am who gives a damn about the sandwich. And someone standing at the pass who was paying attention.
If that resonates, follow along.