Boundary layer iterative development

Twenty-one chapters in, the series has shown one way of working again and again. It hasn’t named it. The demos route a week of bugs by rules the network file holds, cut a runaway loop under a ceiling, and run a second round under the ceiling a manager changed at a desk. The name for it here is boundary layer iterative development.

There are three parts to the name, and the method needs each. Boundary layer: the work never runs outside the bounds the network file carries (a budget, a threshold, a grant, a rule about effects), and anything outside a bound is refused before it starts, by the engine, not by a person who had to be watching. The file that carries the bounds, the doors where people and agents meet them, and the record: together they’re the boundary layer. Iterative: the work goes round and doesn’t stop. The record supports a report at any point, the answer to the report is a diff to the file, and the work carries on under the amended file. Nobody has to remember the change.

Development, because the rounds wrap the org’s own work: the fixes, patches and merges that used to sit in a queue for a person’s attention, and the desk decisions that still need one. The agents do the first kind. The second kind never left the desk.

Underneath is the capstone’s claim: the coordination layer is already the network. Nobody builds a controller to run the method, because the file, the two doors and the record are the method. Every department in an org meets that layer at a different part of it. The rest of this chapter plays that out.

An org usually runs on three things that have no job in this method: no more sprints, no more backlog, no more chat room coordination. One sentence replaces all three. The business direction is the boundary layer, the boundary layer defines the workflow, and the workflow is the communication.

The business direction is the boundary layer: where an org is going is written as bounds on the file, a budget here and a threshold there, and the engine holds them, so direction isn’t a plan agreed at the start of a sprint and then remembered, and it moves when a report is answered, as a diff. The boundary layer defines the workflow: an ask is routed under those bounds as it lands, so there’s no list beside the work for anyone to groom, only each item on its lane. The workflow is the communication: an ask at the desk of whoever is granted to answer it, an answer on the record with who and why, a report read back from the run. That coordination was the chat room’s job.

A round isn’t a sprint, and it isn’t a count of loops. A sprint is a span on a calendar, with a scope agreed at its start and a close at its end; the rounds here have none of the three, and they never end. Inside them an agent graph iterates as often as the work asks and the bounds allow. In the spend demo an agent and its critic went back and forth on each task under a credit ceiling, and nothing in the method says how many times. Nobody counts the rounds, or the loops. What gets counted is two things at the boundary layer: its successes, the work that landed inside every bound, and its refusals, the work a bound turned away before it started. Both are informational, a reading and not a target, and read together the two counts show the boundary layer’s throughput and how effective it is. The report reads both off the record. The diff that answers it moves the bounds while the work goes on.

The counts are also why a dependency can’t be released alone. A part that lands without what it depends on, or without what depends on it, hasn’t landed inside every bound. So it isn’t half a success and it isn’t a refusal: it’s a failure at the boundary layer, the one thing neither count should ever hold. The quorum demo has the shape of it. The merge there waited on a threshold of two answers and the lead’s gate, and in the tied take, where one branch could have gone in by itself, the lead refused. Nothing merged.

Picture a track with a wall on each side and no finish line (figure one): the walls are the bounds, together they’re the boundary layer, and the work goes round between them. Whatever stays inside every wall lands and is counted as a success, and whatever a wall turns away is counted as a refusal. A dependency goes round with what needs it or doesn’t go. A diff moves a wall mid-lap.

The boundary layer is where the bounds live, and where an org meets them. It has four parts, and only the parts: the network file, carrying the house rules, the bounds and the grants as plain fields a run reads; the desk, the page a person answers on, filtered to the items they’re granted, one page per person; the worker door, MCP, the surface agents join through, at arm’s length from the desk; and the record. Every decision lands on it as one line with who and why. The run sits beside it.

No department meets the whole boundary layer, and none needs to: finance stands at the budgets and the spend report, security at the grants, product at the criteria, the engineers at their own desks and their lead at the gates, support at effects and the staleness keys. Audit stands at the record alone, with read rights and nothing else. The org chart below draws each department at the part it touches. Nowhere else.

There’s no box at the top of the chart with more reach than anyone else, because the boundary layer wouldn’t know what to do with it. In the method, authority is a field on the file, a grant at the door and a line on the record, for a lead, for finance and for anyone else the org names. It’s the same three things for all of them.

Harlow & Vale is invented (a freight software firm of about forty people, six departments). The machinery under the chart isn’t: the bounds are the SPEC’s, the lanes are the backlog demo’s, and every run number this chapter repeats is a demos repo’s recorded take.

Here’s the method as a working week, on the invented firm. The week lands all at once, the way the backlog demo’s does: bugs on one lane, requirements on another, architecture changes on the third, staggered down them. The rules route every item before any person reads one. Routing is fields on the file, not a meeting.

The first lane needs nobody, and clean bug fixes run and land on their own; in the recorded take, ten of fifteen did. The fixes that carry a finding don’t land alone. The demo’s lead received the lock-in and the slop findings with the work, and the firm’s lead reads the same kind of item at the same door, with the record under it. That door is the desk.

The third lane is money, and the firm’s finance manager never has to see a refusal. There’s nothing to see. In the demo a task was refused at the fixer under a lowered budget before it started, with the record saying what the pool was short of. The item waits, and the pool answers it when the budget says it can. A refusal is a fact and a count on the report, not an inbox item.

The requirements lane is the desk’s work. Each one needs both engineers to accept the agent’s acceptance criteria, shown as a diff against the original ask, and in the take four of five were scheduled that way and one went back to product with a reason. The architecture changes collect both engineers’ advice, then the lead’s call, and the call gets written down either way. In the take: one adopted, one rejected, both recorded.

Nothing closes at the end of the week. The books are read as they stand. What the week counts is what landed inside the bounds and what was refused at them: in the backlog take, ten fixes on their own, four requirements scheduled and two architecture calls on the record landed, and the task at the fixer was turned away under the lowered budget. In the spend demo five loops finished and two of them burned through their ceilings, the report landed as one ask on the manager’s desk, and the answer came back as a diff to the policy file. The demo numbers what follows as round two, in the same run, because it stops to show the diff: the ceilings lower, the runaways cut off sooner, less spent. The method doesn’t stop, and doesn’t number: the file changes while the work goes round, the diff is the decision, and the file is where the decision lives. That’s the iteration the name holds.

Count what the week didn’t have. No sprint: the direction was already on the file as bounds, so nobody planned the week or committed to a scope for it, and the direction moved once, when the manager answered the report with a diff. Nothing closed when the week was over. No backlog: the bounds routed every item as it landed, so at any moment each one was running, landed, refused with a reason, or waiting at the desk of someone granted to answer it. Nobody groomed a list. No chat room coordination: the workflow carried the lead’s call, product’s reason and the manager’s ceiling, each one, to the record or the file. None was ever a message in a channel.

The cycle below is the week in one picture (figure three): six steps, and no last one. The only edge that leaves the cycle is the one back in: the amended file. The work goes on under it.

The roles at the doors, as the demos run them and the firm stands them (figure four): where each one appears on the boundary layer, what it may set on the file and what it may answer. The point of the table is the two answers at the bottom: the officer and the reviewer answer nothing. That’s because their doors have no asks.

One pair of demos makes the same point the table makes, which is why the pair closes the chapter. In the quorum demo an ungranted reviewer was refused at the desk itself, and the item kept waiting. In the spend demo the manager’s answer wasn’t a memo round two had to remember; it was a diff. Authority that lives anywhere but the file is a rule an agent can be unaware of, the capstone’s first failure. So the method never puts it anywhere else.

The bounds are fields on the network file, and the SPEC polices each one: a budget of named units with a cost per call, a pool a producer may lower at injection and never raise (SPEC 10, decision 0006); a threshold of distinct senders on one ask, in arrival order (5.2); grants pinning who may answer what, checked when an answer arrives (decision 0010). Then staleness. Newer input for the same key makes older work stale and the stale call is cut, but a started effect never is (5.4, 11). The next tick can’t take back the paying and the merging on the lanes.

The rules on criteria ride the same file, and the backlog demo reads them beside budgets and thresholds, so a requirement needs two agreeing answers before it’s scheduled. When that demo refused a task at the fixer under a lowered budget, the refusal was 10.3’s own error, and the record says what the pool was short of. The call never started.

The report is a fact because the books are. A cost commits on every outcome, whether it finished, was cut or burned through a ceiling (0006), so a round’s spend report is the run’s own arithmetic and not anyone’s story. The manager answers the report as one ask at the desk, like any other (3.4, decision 0008). The answer is the diff.

Not a controller, and not an org chart drawn over one. The project’s multiplayer note argues against a server that assigns items, holds locks and arbitrates, and the boundary layer keeps that argument. A department writes the bound its expertise owns, and the engine holds it while the run goes. No department gets a lever on another’s door.

Not a promise that nobody talks. No more sprints, no more backlog, no more chat room coordination means none of them carries anything the work needs: nobody loses a direction, an item or a decision by missing a planning meeting or a channel. That’s a claim about what the method needs, not a report from a firm that ran without them. And the backlog demo keeps its name. It’s a week’s backlog arriving, the last time anyone handles it as a list.

Not the firm. Harlow & Vale is invented: the people, the freight product, the week below. Nothing here is a live run. Where a sentence leans on the demos, it names the takeaway or the SPEC section, and where the firm differs from what a demo recorded, the firm is the invention, not the demo.

Not a plan that finishes the platform. The grants the chapter leans on are a file beside a demo run, not the engine’s, and the other three gaps the capstone collects for issue #30 are still open: a human hold that survives a restart, presence, quiescence. A department that needs a hold across a restart can’t have one yet. Nothing here builds it.