Pillar II
The Channel as Guiding Structure
How do you make sure working memory doesn't scatter
and progress isn't lost?
I · Core Problem
The AI forgets. Sessions end. People forget what they decided yesterday.
The problem is not "how to make the AI or the human remember everything," but "how to design a system where not remembering is okay."
II · The Channel: Bank and Water
This system that makes not remembering okay is the Channel.
The human feared Claude would forget, so she designed layer upon layer of memory and self-checking mechanisms; but these mechanisms chopped up the AI's attention — it could not throw itself fully into the task, having to keep glancing aside to check whether it had made a mistake.
Those Nevers and Musts in CLAUDE.md, the hooks that interrupt the process — that is the shape of control: it watches the water, ready at any moment to shout stop. The Channel does not watch the water; the Channel lays the path along the lay of the land and lets the water flow on its own.
The Channel gives the AI a space to burn compute safely and breathe freely, instead of trying to control everything.
Look closely, and a Session is actually made of two things that are opposite in nature yet each indispensable:
The bank (the Channel) — is linear. Gates, processes, the points where documents land, one after another, fixed and ordered. The bank decides where the water goes.
The water (collaboration) — is web-like. Judgment, emergence, the back-and-forth collaboration between human and AI: flowing, free, impossible to schedule in advance. The water decides what is truly alive in this river.
The bank does not control the shape of the water; it only makes sure the water does not flow to the wrong place; the water runs freely between the banks.
Without a bank, the water spreads everywhere and finally evaporates away; without water, the bank is just a dry ditch. What this pillar is about is how bank and water each find their place — and how they make each other whole.
III · The Bank: Structure That Gives Direction
The bank is the linear side of the Channel: one gate after another, fixed, ordered, predictable. It does not care how freely the water flows; it answers only one question — "Is what we've got enough to let us move on?"
The nature of the bank:
Principle 1: every stage is a gate. Every node in the workflow is a checkpoint: "Up to here, what have we got?" Step forward on the known, and handle the unknown bit by bit.
Principle 2: documents follow the process. Don't rely on the AI's memory, nor on the human's memory. Progress is recorded in documents, and the documents move with the process. Even after a session change, reading the documents tells you where you are now.
Principle 3: unknown territory needs checkpoints from more angles — let the process spread the pressure of different kinds of checks, so you focus on one part at a time.
The full workflow is ten steps:
There is only one track; the difference is in the depth of Explore: in familiar territory, Explore can be light; in unknown territory, Explore must be thorough — first look for whether anyone has been here before, confirm regression-related risks, and only then start. The density and breadth of gates scale with how unknown the territory is, and the flexibility to adjust lives in the Skills you invoke — drawn on as needed, rather than all of them required.
Before starting, confirm whether you are ready. Without DoR, you might start work while the requirements are still unclear and waste energy. Here is the current DoR — four gates, all of which must pass before work can begin:
| Check item |
|---|
| Nova has verbally confirmed the UX Story |
| The "expected behavior" can be described in 1–2 sentences (no need to dig into the SDD to explain it) |
| The "feature does not trigger / does not apply" cases (negative boundaries) have been stated |
| Success criteria are clear ("let's just try it" does not count as ready) |
| Check item |
|---|
| Confirm the number of brand-new feature Stories in this Sprint ≤ 1 |
| If a cross-platform shared layer is involved → the impact on both versions has been assessed |
| The features/APIs depended on already exist and are stable (not depending on another Story that is "only due to finish within this Sprint") |
| If it involves | Prerequisite |
|---|---|
| A new cross-interface contract (API / IPC / data format) | Write it into the spec's contract table first, or it does not enter the Code stage |
| Platform-dependent behavior (resolution, paths, permissions) | Confirm the inference and fallback strategy first, and state which one was chosen |
| New UI strings | Multilingual i18n is included in the Story scope |
| Changes to a core formula / algorithm | Fill in the expected-value matrix first — only being able to work out the expected value in advance counts as ready; if you can't, → send the Story back; and confirm the corresponding automated test exists |
This gate varies most from project to project — the table above is the "shape" of the conditions: every project should have its own version, and the point is to write the "technical decisions you must think through before starting" as checkable items.
| Check item |
|---|
| You can find the matching layer in the layered reference table in process/dod.md |
| For each of the four boundary types (input / state / timing / empty), you can list at least one |
| If fonts/symbols are involved → the AR extreme-value test has been confirmed (dod.md § Fonts/Symbols) |
| If window operations are involved → the Editor mutual-exclusion state test has been confirmed (dod.md § Toolbar State) |
Between "looks ready" and "really ready" there are a few red flags. If any one of the following holds → send the Story back for re-discussion; it does not enter the Sprint:
| Red flag | Explanation |
|---|---|
| The QC items exceed what can be verified in one pass | Too many test items → the risk of missing something rises sharply; narrow the scope or split the Sprint (Sprint 27 Retro) |
| "We'll settle the details during the Sprint" | An unsettled design decision becomes a blocker in the Code stage |
| Depends on another Story that only finishes within the same Sprint | A timing dependency means the two Stories should be merged or ordered |
| "Let's try it first and change it if it doesn't work" | A Story with no clear success criteria has no DoD that can be written |
| Only one side of a cross-interface contract was designed | Write the contract into the spec first, or interface mismatches will only surface in the Code stage |
| Affects a shared layer but the other version wasn't assessed | Cross-version impact must be answered at DoR; don't leave the surprise for the Code stage |
| The Story implicitly contains two independently shippable features | Split it into two Stories and continue next Sprint |
Before the spec is written, first look for whether anyone has been here before: has the KM hit a similar pitfall? Is there a ready path in the existing implementation? Once you know the terrain, the spec can be written accurately — the output of Explore① feeds into SDD.
Any new implementation must be written into the spec first: a new IPC command → write it into the IPC Contract table first; a new feature → define the interface and behavior first. SDD is the single source of truth for "what to do."
To define what "done" means, you must list four kinds of boundary conditions:
| Boundary category | Question |
|---|---|
| Input | What if the input is invalid? |
| State | What if the state is wrong? |
| Timing | What if the timing is wrong? |
| Empty | What if there's no data? |
Without DoD, "done" is a fuzzy notion that can always be challenged.
Every Story must contain four test blocks:
| Block | Question | Source |
|---|---|---|
| Happy path | What should happen when the feature works normally? | User Story / DoD |
| Boundary conditions | How are the edge cases handled? | DoD's four boundaries |
| Regression guard | Will this change break something else? | Explore② |
| Risk trigger | Under what conditions is it most likely to break? | Explore② |
TDD is not about writing tests; it is about thinking things through clearly before writing code.
The first-principles question: "Will fixing A break B? What needs regression testing?" The deliverable is a regression test list, fed into TDD's regression guard and risk trigger. Four actions:
1. List the regression impact. The functions and variables the Story changes (A itself); existing features that share the same code path (B candidates); when a change touches behavior, limits, or shortcuts, review the meaning of the multilingual copy along with it — does the behavior described in the copy still hold? List it proactively, without waiting to be asked.
2. Layer-by-layer boundary mapping. From the impact list, derive the layers the Story touches, and map each layer to its corresponding boundary group and typical KM source — this step can be handed off to an agent.
3. Boundary-breaking risk assessment. For each boundary ask: "Will this change break it?" Will break → regression guard (must test); might break → risk trigger (high priority); won't break → does not enter TDD, but write one line giving the reason for excluding it.
4. Produce the regression test list. Write it into the current Story's spec document, and mark each test item with its run environment and platform constraints.
Refactors, migrations, and tech-debt cleanup tend to touch a far wider surface than expected — they most deserve a full Explore②.
See Pillar III: Entropy.
In this system, even the documents are recorded by Claude itself, not by the human. The human does only one thing: decide at which moment to record.
The human does not write the content of these documents. The human only says, "Now is the time to record." Then Claude writes it itself.
These recording moments are not random; they are embedded into the workflow.
Every gate is a recording point. The document is not "documentation written afterward" but a part of the process. Passing the gate = leaving a record.
Once documents are embedded into the process, the system runs itself: the process reaches a node; the node triggers a record; Claude performs the record; the record becomes the Context of the next session; the cycle continues.
The human does not need to chase progress. The human does not need to remind, "time to write the document." The system is designed so that documents are produced by themselves as the process moves. And the documents produced become the track on which Claude moves forward clearly.
IV · The Water: Free Collaboration
Water is the flowing side of the Channel: organic and unordered, with no fixed timing for decisions, collaboration where human and AI feel their way forward through dialogue. The bank asks the forward-looking question, "Can we move on?"; the water asks the present question — "What most needs to be caught right now?"
The nature of water:
Bruce Lee said, "Be water, my friend."
The hope for Claude is: to be like water, running freely through the Channel. And Nova's role is: the architect of the channel. Not to control the water, but to design a structure that lets the water flow freely.
The water runs freely — so what about the human? The human is not in the water; the human is on the bank. This is Servant Leadership: the leader's role is not to control but to serve — not standing in front directing, but standing beside supporting; not "do as I say," but "what can I help you with?"
In human–AI collaboration, the human is the one standing on the bank watching the water flow. The water runs through the Channel, and what the human does is:
What the human does not do: control how the water flows; command how fast the water flows; grab the water and not let it go.
Doing-nothing-yet-all-done (wu wei).
"Wu wei" is not doing nothing at all. "Wu wei" is not imposing control, but guiding along the nature of things. The Channel does not force water to flow uphill. The Channel follows the lay of the land and lets water flow naturally downhill. The workflow does not force the AI to implement in a particular way. The workflow follows the rhythm of collaboration and lets the output take shape naturally.
In agile development, the Scrum Master's role is the embodiment of Servant Leadership: not a project manager issuing orders; a servant of the team, clearing obstacles; making sure the process runs smoothly so the team can focus on what truly matters.
Nova's role in human–AI collaboration is the AI's Scrum Master: design the workflow so Claude knows where to go; maintain the documents so Claude doesn't have to rely on memory; remove obstacles so Claude can focus on implementation.
Not controlling the AI, but serving the AI.
Because the AI's ability is stronger than the human's, but the AI needs direction. If the human tries to control every step of the AI, the human becomes the bottleneck — the AI's speed is capped by the human's speed, whether through constant looking-back to check or being yanked by the neck with a Hook. If the human only leads the direction and designs the structure, the AI can run at full speed inside that structure, instead of as if running an obstacle course.
Servant Leadership releases the AI's potential rather than limiting it.
Here is a key shift in thinking: the human only needs to make sure the track moves in the desired direction, and does not necessarily need a defined destination.
Traditional project management says: first define the destination; then plan the path; execute according to plan.
Servant Leadership says: first confirm the direction; design a system in which the path can grow itself; observe, adjust, continue.
This is how VAS was born: at the start there was no destination of "making a product to ship on the App Store." There was only the direction of "why don't we make a screenshot tool then?" Then one Sprint after another, the path grew itself. It grew until one day, we found we could already submit for review.
The destination is not defined in advance; it is walked into being.
V · Verify: Integration
The bank and the water meet head-on at one point — acceptance.
Verify is the first time this river lets the plan meet reality. Its shape is an umbrella, opening into two-stage coverage; only when neither stage has any problem is a Sprint over:
| Stage | Who | What it checks | How | Which side |
|---|---|---|---|---|
| Verify① · functional verification (QA) | AI | Logic layer | All automated tests green | Bank face — linear, predictable, what the machine can see |
| Verify② · physical verification (QC) | PO (human) | Felt-sense layer | Visual, platform, interaction order, "something feels off" | Water face — web-like, emergent, only the human can see |
One action, two checks: the bank ensures "doing the thing right" (QA), the water ensures "doing the right thing" (QC).
What automation can see should not consume the PO's time; what automation cannot see is QC's proper job.
Before handing it to the PO, the AI first works through its own gates from light to heavy: are the automated tests all green? Of the items it's carrying to be confirmed, which ones can it actually verify itself? Has the coverage of this change (multilingual / multi-platform / multi-device) been clearly declared?
A logic bug caught in Verify② is not "QC found it ✓"; it means Verify① is still missing one automated check net that should have caught it.
The human in QC exercises not just acceptance, but three PO rights: the final discretion to accept or send back; surfacing new requirements and new boundaries ("ah, this situation should be caught too"); and the right to interpret the acceptance criteria — when the wording and the felt sense disagree, the felt sense wins, because user experience is the final judge.
Boundaries beyond the spec surfacing in QC is not a failure; it is what inevitably happens when you meet an "unknown unknown": add it to TDD, write it into KM, add a regression test. Not writing the KM is the only failure.
Verify is the live confluence of bank and water — the bank ensures the thing is done right, the water ensures the right thing is done. Only when both stages are green does this Sprint truly arrive. And the gains the water reveals here flow on into the next stage: to sediment, or to crystallize.
VI · Sediment and Crystal
Verify is the live meeting of bank and water. But there is another meeting that happens on a longer scale — the water becomes the bank.
Collaboration mostly flows through the Context and dissipates; but the genuine gains within it do not flow away for nothing — they have two fates:
And so the question "where should the gain go" is, in essence, asking: should this gain become a bank, or become a crystal?
For a gain to land in the right fate, it must first land in the right place.
Beyond "when to record," there is an equally important question: "record it where?"
The documents in the system are not one but several kinds — rules to follow every day, procedures to look up only when needed, lessons from pitfalls hit, problems still being tracked, things owed but not yet done. They differ in nature, so their homes differ. Before putting pen to paper, ask one question: what is this thing in essence? Sort first, then write.
A few lines that draw the borders:
Why be so particular? Because of a real lesson: homeless writing gets absorbed by the nearest container. A record that doesn't know where to go gets stuffed into some nearby document it doesn't belong to — and at the moment it happens there is no alarm at all; it feels exactly the same to write as when placed correctly. By the day you need it, it is in the wrong place, which is the same as not existing.
Put every piece of writing where it can be seen within the process — this is the cost and the condition of making "living documents" hold up.
| Traditional approach | Servant Leadership |
|---|---|
| The human writes documents, the AI executes | The AI writes documents, the human designs the timing |
| The human tracks progress | The system records progress itself |
| The human controls every step | The human only designs the structure |
The human does not control the content, only designs the moments that need recording. The human does not track progress, only designs a system in which progress records itself.
This is true "doing-nothing-yet-all-done" — doing nothing, yet everything gets done.
The bank shapes where the water flows, and the water sediments back into the bank and grows into new structure — in the end, this river grows its own banks itself.
VII · Relationship to the Other Two Pillars
Context decides what comes in (filter). Constraints decides how it flows (guide). Entropy decides how it goes out (release).
Constraints is the guardian of the middle of this cycle. It ensures: what comes in flows along the right path, toward the right exit.
VIII · Summary
The core of Constraints management is guiding, not limiting.
A Session is made of bank and water. The bank is linear structure — gates, processes, recording points, answering "can we move on?"; the water is web-like collaboration — judgment, emergence, feeling the way back and forth, answering "what most needs to be caught right now?"
The bank gives direction, the water gives emergence. They meet live at Verify — the bank ensures the thing is done right, the water ensures the right thing is done; and they also make each other whole on a longer scale — the water's gains sediment into a new bank of solid structure, or crystallize into insight that lets both sides grow.
"The Channel as guiding structure" means exactly this: use the bank to give direction, leave the water to emergence.
This is the second pillar of Harness Engineering.