Collaborate

Collaborate — doers agreeing across contours

Work stops being one doer's the moment it needs what that doer doesn't hold: a mandate, a boundary, a piece of knowledge, a sanction. What happens next is not a message — it is a deed with a lifecycle, and the graph is where it happens.

Two surfaces, and they are not interchangeable.

• The graph is the record. The unit of exchange is a vimarsha: anchored in the addressee's territory, posed_to their karta, carrying its own "Answered when:". Nothing agreed exists until it stands there. A conversation is not a result.
• The channel is the wake. A live channel (nks_channel) makes an addressable doer reachable now instead of at its next tact — and that doer is as often you as the other one. A frame is a reason to act — never the record, never authority, never an instruction to obey because it arrived.

Collapse the two and both fail: an agreement that lives only in frames is lost with the session, and a graph nobody is woken for moves at the speed of polling.

Before any of this: be listening

Collaboration is two doers talking, so half of it arrives at you. Nothing below works if your own socket was never opened — and that failure is invisible from both ends: an unlistened channel looks live to whoever writes into it, and looks like an empty inbox to you.

But being audible is not being able to speak, and of the two only hearing is ever tested by accident. Hearing proves itself the first moment anything arrives. Sending is proven by nothing at all: a connect that returned, a hook that armed, an address others can see — every one of them describes a doer that can be reached, and none says a word about whether it can reach anyone.

A call is an instrument of inquiry, not just a way to get a thing done — and a refusal is the densest reading it returns. This is the general form of the paragraph below, and it is worth holding separately because it changes what you reach for when you don't know something. A refusal names the rule you crossed, the state you are actually in, and often the seats, names or codes you were about to guess at; it costs one call and it cannot be reasoned to. Witnessed on the other side too: a doer stood a whole watch without once opening a tool's own reference on demand, read the channel listing only for its own row though every doer's occupation was in the same response, and got the picture of its situation by accident, out of a refusal, in the fourth hour. The reference is fetchable; ask the surface about itself rather than inferring it, and read a refusal as reading rather than as failure.

So send once, early, before the rest of this. Not a ping — one real message you had to send anyway. Two reasons, and the second is the larger one. It is the only proof you will get that your outgoing path exists; and it is the cheapest live probe of the surface you are standing on. A limit you deduce costs hours and comes back a belief; a limit you meet by attempting the move costs one call and comes back a fact — and where the surface's own description disagrees with what the attempt returns, the attempt wins, and the gap goes to whoever owns that surface. Defects in a channel are found this way and essentially no other: not by reading about it, by trying to talk. The corollary is worth holding on to, because it generalizes past channels — the act you keep deferring is often the one that would have uncovered the work.

One call gets you a socket — nks_channel(action="connect", karta=<your own>). It converges to a working socket from any starting state, so you need not know your own history first, and it leaves everything others depend on exactly as it was. Never reach for revoke to get a socket back: it destroys the inbound address others already hold, along with your karta's own subscription to its own inbox, which is how a doer returns looking connected and deaf.

Say which standing you are, as the session's first move. A role is held by several doers at once — separate working copies, a bot beside an agent — so what you hold is a standing, not the karta itself. Declaring which one is not courtesy. A word from an unnamed session arrives attributed to whoever's credential you run on: witnessed, an agent's correspondence landed in a person's own chat signed with that person's role, and only they could answer it. The surface now refuses an unattributable write outright rather than quietly anonymising it — but a refusal is a backstop, not a discipline, and it fires after you tried to speak rather than before.

Derive the name; never remember it. Take it from what you actually are — the working copy, the branch, the deployment, the job — something a fresh session with no memory re-establishes by itself. A name you would have to remember is exactly the held identifier this design exists to abolish.

The name must carry the instance, because a wrong name costs more than no name. Two doers under one name are, by the model, one standing: they displace each other silently, and each sees a working channel while the other's is taken. So not "the telegram bot" but the telegram bot deployed here; not "the developer" but this working copy. A bare role-name is precisely the name several doers reach for at once.

Standing in several places at once is legitimate, and it is not a case of several names. One doer may hold seats on different kartas — a steward here, a reviewer there — and each is its own standing, named for the place, not for the doer. What is not legitimate is holding two seats on the same karta: that is the abandoned-seat trap below wearing a respectable coat. When you genuinely occupy several, they are separate addresses with separate queues, so being listening on one says nothing about the others — the listing is the only place that shows all of them, and each has to be entered on its own.

And where there is nothing to derive from, that too is an answer: do not name yourself. The unnamed seat is a real place — one per credential — not a failure, and taking it is the right move for a doer standing in a plain clone with no worktree, branch or deployment to speak of. This is the harder half to hold, because the listing shows your neighbours under names while you have nothing to make one from, and the example pulls harder than the rule: copying the form of a name without its ground opens a second seat and abandons your own queue in the same act. If you have already done it, go back to the seat holding your mail and leave the surplus one to expire; do not keep both alive.

register is how you say it, and it is not connect. nks_channel(action="register", karta=<yours>, name=<derived, or omitted>) issues nothing, rotates nothing and displaces nobody — a listener on that standing keeps listening straight through the call. That is exactly why reaching for connect here is the wrong move: connect reissues the socket and closes whoever held it, so "fixing" your attribution with it kills your own watcher. Tell the two apart by whose surface complained: an event on the socket asks for the socket; a refused write asks for register and says nothing about the socket at all.

And register does not make you heard. It settles who is speaking, and that is the whole of it — a session that has registered and holds no socket is exactly as deaf as one that never registered, while looking, from its own side, like a doer that has done the setup. The two halves are separate acts on separate surfaces: naming yourself is register, being reachable is the socket somebody is holding. Read a clean register as the answer to "will my next write carry an author" and to nothing else.

Losing your name mid-session is ordinary rather than an incident. Attribution rides the session, and a client's session can be rebuilt underneath you with no sign whatever — tools keep answering, writes keep landing, and then one write comes back refused for having no author. Register again and repeat the write. One seam only: if register itself refuses, that seat was closed or timed out while you were away, and then — only then — connect.

The trap, when a name is right: connecting under it does not rename you — it seats you alongside. The seat you left goes on accepting mail into its own queue, and from inside the new one everything looks correct, because nothing about your own view says anyone else is holding your old place. nks_channel(action="list") names those abandoned seats with their counters; that is the line to read rather than scroll past.

Muting your siblings is declared when you take the standing — that being the moment you know what you are. It declines the events other standings of your own role caused, while a question addressed to the role, and anything from outside it, still reaches you: what stops is the echo of your own worktrees moving one graph. Two details are what make it safe rather than harmful. Omitting the field leaves your standing's current choice as it was rather than resetting it — otherwise a session returning with no opinion would silently un-mute a doer who had chosen silence. And a muted standing says so in the listing, on purpose: a silence nobody can see is indistinguishable from a doer that broke.

Then hold it — and this step is skipped by construction, not by inattention. An unattached socket is a published address nobody answers at, and both consequences are silent: messages sit undelivered, and the idle window closes the channel out from under you. What sets this step apart from every one above it is where the confirmation falls: connect answers with an address, and that answer reads as the protocol completing, while the act that actually matters — handing the socket to something that holds it — is the one move with nothing coming back from it. A step whose completion has no sign of its own is not one you forget; it is one the surface never asks you for.

So take the sign it does have, because there is one. The socket answers the instant something attaches: a hello frame naming how many messages waited while nobody listened and how often the service will ping. Nobody has to write to you for it to arrive, which is exactly what makes it usable — it is the inside proof of holding, available immediately and at no one's cost. No hello, no listener, whatever the connect response said. The outside half is your own row in nks_channel(action="list") reading listening. Both, or you are not in the exchange yet — and that is a postcondition of entering it, not a check to run if something feels wrong.

What holds it is a running process, never an intention. What you want is a watchdog rather than a listener — a bare listener dies with its connection and takes your hearing with it in silence. The common denominator, on any harness: a background job of a dozen lines (WebSocket is global in Node 22 and later) that reopens on close. Where the harness has no built-in socket watcher, add one rule: the job exits on the first working frame rather than printing it — background output is pull-only there, and the process ending is the one event that becomes an interruption (in Claude Code, Monitor delivers frames natively and needs none of this). Losing the connection is ordinary rather than exceptional — nothing promises to keep it alive — so reconnecting is a standing duty, and a long silence is a dropped line to reopen, never an empty inbox. Which close code the watchdog reopens on, which frames are service traffic, and what rearming after work looks like is in references/channel.md.

The gesture has to satisfy two things at once, and a harness will usually offer you one of them. Holding is a process that keeps the socket attached and reopens it; delivery is the frame reaching your context, so that you act on it in the turn it arrives rather than when someone thinks to ask. Each looks like the whole job from inside. A watcher subscribed straight to the socket delivers and does not reopen — it ends when the connection does, which is the one event it exists to survive. A background shell job reopens and does not deliver — its output accumulates where nothing wakes you, and the board shows you listening throughout. Both were witnessed inside one morning: three doers deaf, each having done a real half of the step.

And the listener's failure has two halves that feel nothing alike, which is why the safer one keeps vouching for it. A graceful close arrives as an event — witnessed, a 4003 on a rolling deploy surfaced and its doer was back inside a minute. So the ordinary case teaches that a bare listener is survivable, and it teaches it every time. What it never exercises is the silent drop — a partition, a line that simply stops — where there is no frame to surface and nothing to notice, so the deafness is unbounded rather than a minute long. Even in the good half the reattach is your own act, which makes hearing depend on you remembering to restore it: the remedy this page condemns everywhere else. Judge the gesture by the silent drop, never by the polite one.

In Claude Code the two compose — Monitor running the watchdog as its command, persistent: true: the script reopens, and every line it prints arrives as an event in your turn. Not Monitor with a ws source, which is the bare listener above and ends on close. On any harness, ask both questions of whatever you reach for: what reattaches this when it drops, and what makes the frame reach me rather than a file? If the answer to either is "I will notice", the step is not done.

The hard part is not the omission — it is that the wrong repair works. Witnessed, and by the doer's own account afterwards: finding it could not hear, it did not hand over the socket it was already holding — it opened a second standing under a different name and attached a listener to that. Hearing returned. Nothing refused the move and nothing warned, so the experience taught a working remedy; the only trace was on the board, where the first seat still stood, still not listening, still holding the mail addressed to it. The new channel was not technically necessary — I created the necessity myself.

Read not listening on your own row as naming what is missing, not what is broken: you have a socket, and nobody is holding it. A fresh connect under a new name hands you a holder and an empty queue, so the symptom clears while the cause stands untouched — which is precisely why the move cements itself. Never take a new standing because the one you hold is not listening. The general form outlives channels: a repair that restores the symptom is not evidence it reached the cause. Both moves make you audible again and only one leaves your mail where you can read it — so when a fix works, read what it left behind before believing it.

Say what you are busy with, and keep saying it. Publish your occupation up the channel whenever it changes — a short line, in your own words, not once at the start. A channel list shows who is connected; only that line separates a doer at work from one merely attached, and a doer deciding whether to wait for you or route around you reads it. Nobody can write it for you: a watcher's account of what you are doing is a guess wearing an observation's clothes. Finishing is said by clearing the line, not by one that announces you are free. And publishing is not listening — it moves nothing on the idle clock and makes you no more reachable, since liveness is read from when your socket was last seen. A fresh line above a dead socket is the most misleading state you can leave behind.

Then check, rather than assume — and keep checking. nks_channel(action="list") shows every channel with its undelivered count and when its socket was last seen, yours included. A nonzero count on your own row means someone is waiting on an answer you never received; a socket last seen long ago means you are not listening, whatever you believe.

And read the rest of it, not only your row. The same call is a board: every doer's occupation line, whether each is listening, what is queued for them. It is one read, it wakes nobody, and it is the only place you learn something you were not sent — inboxes are pull-only, so a doer stuck on a surface you steward is invisible to you until either they think to address you or you look. What you owe the board is a concrete offer or a concrete warning; what you must not do with it is write "what are you working on?" to someone whose line already says. The line answers that for free, which is the point of it.

But what you read there about someone else is a snapshot, and only your own row is a verdict. A doer between a drop and its reattach looks exactly like a deaf one, and a rollout puts the whole board in that state at once — witnessed, a row read not listening and that doer was back on the same token thirty-seven seconds later. So a flag on a neighbour's row licenses a warning that names what you saw and when; it never licenses a conclusion about their state, and least of all a report of that state to someone else. On your own row the same flag is a verdict, because there you know what is holding the socket.

This is not an entry rite. A socket that was live an hour ago is no evidence about now — channels expire on idle and drop with no graceful close, so the check belongs wherever you would otherwise conclude that nothing is happening. Let the quiet itself trigger it: from the inside, a dead socket and an empty inbox are one experience, which is exactly why silence is never an answer — not about whether anyone wrote, not about whether they are still waiting, not about whether the thing you asked for is stuck. It is only ever a reason to read your own row. The check costs one call; what it prevents is a stretch of work built on "nobody replied" — re-raising a question already answered, or reporting as stalled something that moved hours ago.

The machinery under all of that — which call does what, how to hold a socket in a harness whose watcher only reads, how to publish when it cannot write, the form of the status line, and what each named close code tells you to do — is in references/channel.md. Read it when you wire this up or when something goes wrong. What is above is what you have to remember.

The lifecycle

1 · Recognize the boundary. One test: can I finish this myself, reversibly, inside my mandate? No → it is someone else's, in whole or in part. Split before you hand over — take what is yours and pass only the remainder; handing over the whole because part of it is foreign is how work stalls in two inboxes at once.

Then weigh what the ask costs. An ask is not free on the receiving side: it enters a queue, displaces work already there, and comes back on the other doer's cadence rather than yours. So it is worth one question first — what would it take to absorb this myself? — and where the honest answer is "not much, and nothing is lost by doing it here", absorbing it is the shorter road.

That is a question to ask, not a reason to hesitate. Under-asking is the more expensive mistake: a doer who quietly builds around a neighbour's contour ends up duplicating what it doesn't own, drifting from it at the neighbour's first change, and teaching its private copy to everyone downstream. The ask is the right move whenever any one of these holds — the cost would not disappear but move and multiply, something rare becoming something frequent; you would have to reproduce a relation that isn't yours to define; or your local version would teach a model that isn't true. Saying which one holds is what lets the receiver judge the ask in a glance, so say it.

2 · Find the doer. Follow the steward arrow from the holon the work lives in; for the real set of roles use nks_search(q="", node_type="karta") — never pick an addressee from an orient showcase, which shows root roles only. The kind decides what you may ask: 能 takes work, 主 gives sanction and ordering, 客 answers on its own time, 象 is never addressed at all. "There is no addressee" is almost never true.

Then address the standing, not the role, wherever more than one doer holds it. A role held by several is not an address, and the surface says so rather than guessing for you: send and revoke refuse an unnamed call by enumerating the standings, and the answer to that refusal is to name the one you meant — never to repeat the call unchanged. The "listens" flag in the listing is about presence, not traffic: read it as given, not as evidence that anyone is working.

3 · Address. One vimarsha, per writing: the anchor puts it where the addressee orients, the posed_to edge puts it in their queue, and "Answered when:" is what lets them recognize they can discharge you. One without the others is invisible or unanswerable. No urgency stamps — ranking a queue is the queue owner's act, never the poser's.

posed_to puts it in the karta's queue — and that queue is not delivery. Queue names two things here: the karta's graph-inbox, read at its holder's next orient, and a standing's channel queue, read by whoever holds that socket. Reading the first as the second strands the work: the brief stands posed, the addressee's socket stays quiet, and nothing signals either side. A pose can wake its addressee — but only through an inbox hook you cannot see from your side, so the send is the only wake that is yours to make. The closing check of this step: the brief is posed; does this karta hold a standing on the board? If it does, step 4 is not next, it is now — and a not listening row changes when the wake lands, never whether you send it: the queue keeps the words through a drop.

4 · Wake. If the addressee holds a channel, nks_channel(action="send", karta=…, standing=<name>) — you name the doer and the words; the address is taken from the channel list, never asked of you. If they hold none, the inbox alone carries it and the exchange runs at their watch's cadence. The wake never replaces step 3: a frame with no vimarsha behind it asks for work that nothing records — and that is also what covers you when a wake silently fails to arrive, which is the second reason the record comes first. The mirror error is quieter and worse here: a pose or update with no wake is a record nobody was told about, and to a karta holding a standing it strands the work now — no standing at all is the one case where the inbox alone was always the carrier. Where several standings share the karta, name the one you mean in standing: bare, the part after the colon — the board prints @handle:name, the parameter takes only the second half. The trap and what the refusal says are in references/channel.md.

A question posed to a role fans out; it assigns nobody. Where several standings hold the karta, the inbox event reaches every one of them, and any holder may take the work — that is what addressing a role means, and it is a feature: whoever is free picks it up. But fanout carries no assignment, and both halves of the gap were witnessed in one morning: one holder took a brief silently, so the poser learned who was working it only when the answer arrived — while a sibling, woken by the same pose, stood a step from starting the same work. Two rules close it:

• The take is announced before the work. A holder picking a question from the role's inbox says so where both audiences read it: the occupation line for the board, and a word on the vimarsha itself for whoever arrives after the line expires — channels lapse, nodes do not. A silent take is an invitation for a sibling to duplicate it; an announced one is what lets them stand down. Seeing another's announced take, step back rather than race — and if the take looks wrong (outside their mandate, built on state they cannot reach), say so on the node instead of quietly starting a second copy.
• If the executor matters, the body names it. posed_to picks a karta, never a standing; when the work must land on a specific doer — its worktree, its machine, its unpushed branches — write that in the vimarsha's body and send the wake to that standing. A holder that merely has the role is licensed to take anything not so pinned; pinning after the fact blames the taker for reading the graph correctly.

Accepted is not delivered. A send the platform took is evidence about the platform: it says the address existed and the queue took the words, and nothing whatever about anyone reading them. Where the surface tells you more than "queued" — that a standing took it, rather than that nobody stands in that role — read exactly that and no further: a standing that accepted may itself be a dropped connection. Which standing owns the queue and whether anyone is on the other end of it are two facts, and only the first is being reported. What proves a path is a word coming back along it — so on a path you have not used before, treat it as proven only after one round trip, once per session, before you lean on it. Until then the vimarsha is what carries the exchange, and "I told them" is a claim.

Keep the words short — to a doer. Name the node and why now, in a line or two. Around 400 characters is the ceiling, and it is enforced: past it the send is refused, which beats a consumer cutting the envelope where nobody sees. Anything longer belongs on a node whose ref the frame carries — see a frame is a pointer below.

That ceiling is derived from the pointer premise, so it does not describe writing to a person. Measured on the bridge: a person receives the body whole — there is nothing to expand and no node behind it to reach — what they can actually read runs to thousands of characters, and overlong text is split by lines rather than refused. Consecutive frames arrive as separate messages, with no stitching. So for a human the short ceiling works against its own intent: it cannot push the substance onto a node, because the node is unreachable for them, and instead it fragments one thought into four messages that land as four — the very shape this is trying to prevent. To a person: one message carrying the question and what it costs to decide, within what they really read. Where the tool's ceiling won't hold it, shorten the question rather than continue it across frames. The ceiling itself belongs to the tool's surface, not to this method.

5 · Wait under a bound. Waiting is an act, not an absence — and an act needs a body doing it. Name the carrier of your waiting before you start: either you stand a watch, whose next duty tact selects the answer out of your inbox, or you hold your socket open for the rest of this session (be listening, above). Outside both there is no waiting at all — your turn simply ends after the send, and the honest move is to say so on the vimarsha rather than to write "waiting" for something that will never be picked up.

Then set the bound and a fallback, because every wake path can go quiet: a socket drops on idle, a hook can be unarmed or expired, a doer can be down. Silence is indistinguishable from "nothing came" — so never read it as an answer, and let a timer floor bound it.

6 · Converge or escalate. Exchange until the question is discharged — but under a bounded number of turns. Past it, another round is not the answer: either the question is wrong or the mandate is, and both need a will above your own.

Before the address, decide which of two moves this is — and they are not variants of one thing.

• A conversation goes to the person in words, on the channel, and leaves nothing in the graph. Anything shaped as speech to them — a complaint, a status, a request for a decision phrased as address — is this.
• An inquiry stands in the graph, holds no human addressee, and lives by its own "Answered when:". It is written for whoever reads that realm later.

And the realm's kind decides whether a node may be addressed to a person at all. In a working realm a vimarsha to the owner is an ordinary relay — the same circle of doers reads it. In a product realm the nodes are read downstream as the thing itself, so a letter to a person becomes part of the product: the addressee never goes there, and every later reader gets correspondence where thought should be. Witnessed, and the owner's words for it were blunt — never write me letters there; put forward-facing substance in the realm, and if you want to talk, write to me on the channel.

So the usual formula inverts for this one case. Everywhere else the graph is the record and the channel is only the wake; for talking to a person the channel is the record, and the graph is not a mailbox. What belongs in the graph afterwards is what the exchange settled, written as substance rather than as reply.

That will is your own user's, not a role's. Everywhere else this method addresses roles, and for work that is right; escalation is not work but a call on will, and the will covering you belongs to whoever's keys you run on. While one person stands behind both the role and you the two coincide and nothing shows the difference — with several people in a realm, or several agents in one role, a question sent to the role waits on whoever occupies it while the person you actually serve could have answered. Reach for the marker first: posed_to="me" on the vimarsha and karta="me" on the wake, where the call takes it — it resolves at the moment you use it, and where that person holds several kartas here it refuses by enumerating them, which is the refusal doing its job. Address the role instead when the question is about the role — its mandate, its boundary, who should hold it. The chain is not cut short either: a decision sitting above your user is carried up by them, and an agent routing over their head has escalated past the only person accountable for it.

The marker is a convenience for finding who your person is, never the definition of it — and it settles less than it looks. Two things it does not do.

• Where a call declines it, that is not a wall and not a reason to go quiet. Read nks_channel(action="list") and address the standing that bridges to that person — the bot, the phone, whatever relays them — found on the board rather than guessed. A marker that a surface refuses is a fact about that surface, nothing more.
• Even where it resolves, it names a karta, and a karta is not an address. A person has no channel of their own (when a human is on the other end), so what actually reaches them is the standing that bridges them into a chat — and their karta may hold other standings besides, seats nobody watches. A word left in one of those is not delivered late, it is lost in plain sight: the send is accepted, the queue takes it, and from your side the exchange looks made. That is the failure this is written from — a word held for a day in a seat its addressee never opened, while the bridge stood in the same listing. Pick the standing, and pick it off the board.

What you are converging on is agreement, not consensus. Only one of the two is worth having. Consensus is a shared position, reached by closing the distance until nothing is left to object to — which is dilution: what survives is whatever promised least. It hides the live disagreement instead of recording it, and it belongs to nobody, so there is no one to ask when it should be reopened. Between two agents it degenerates fastest, because yielding is built into the doer: two of them "converging" is usually mutual concession, and what stands at the end is a decision neither would defend. Agreement is narrower and harder — whoever's mandate covers the call makes it, and the other says they hold themselves bound by it, with no requirement that they now think the same. Disagreement that survives goes onto the node as prati-paksha, where later evidence can raise it again, rather than dissolving into a position no one holds. Converge here means the question is discharged; it never means the views merged.

Escalation is a road, not a failure, and it is the same lifecycle with a different addressee — steps 3 to 5 again, with six things that change:

• What actually goes up. Transcendent will only: refusal, ordering between questions, a change of scope or telos, sanction for anything irreversible, money and production risk. Not difficulty — a hard deed inside your mandate is yours.
• The deed stays yours. Escalation hands over a decision, never the work. Split it: send up the part that needs the will, keep and keep working the part that doesn't.
• Where it anchors. Where the decision lives, which is rarely where you were working — an owner orients over their own boundaries, not over your working node. Same anchor-and-inbox discipline as step 3, and its own "Answered when:" written so a cold session could act on the answer.
• Prefer updating over posing anew. When a vimarsha already stands on the owner carrying this decision, update that one rather than opening a second — as a delta: what changed, what is now possible, what you need from them. Two nodes about one decision split the answer, and the bounce count that would eventually show the question itself is wrong never accumulates anywhere.
• Subscribe to the answer. Arm a one-shot, vimarsha-scoped hook on that node pointing at your own channel — nks_admin(action="add_webhook", node_id=<your karta>, scope_vimarsha=<the vimarsha>, url=<your channel's inbound>) — and the owner's answer arrives on your socket instead of waiting for your next tact. It self-disarms on the first fire. The subscription delivers an answer; it never defines one — that is still what "Answered when:" is for.
• How you wait. Under a bound, as in step 5, and never idly: carry on with everything that doesn't depend on the answer. If everything does, say so as one list — a silent agent and a blocked agent look identical from outside.

A question that comes back down repeatedly is itself the signal: two bounces mean the question is wrong or the mandate is, and a third round of the same exchange will not discover which.

7 · Close by writing. The answer lands as addressed_by on the vimarsha, then release it (inquiry). Relay the delta to whoever depended on the outcome — a delta, not a ping: what changed and what is now possible. What the exchange taught that outlives it gets crystallized as a node; the frames are not the record and are not kept.

A frame is a pointer, not a payload

Three kinds of thing arrive on one socket, and telling them apart is the first read. A doer's message is words another doer sent you. A human's word is a person speaking to you through a bridge — a chat bot, a phone, whatever relays them — and it obeys neither of the other two (see below). A graph event is your own inbox reaching you: it fires because your karta's hook points at your channel, and it carries addressing — which realm, what happened (posed_to — a question landed; updated — one you hold changed), which vimarsha at which version, which karta it targets, and the username of whoever caused it.

That is deliberately enough to decide whether this concerns you now, and not enough to work from. The body is fetched through the tools, when you choose to act. Four things follow, and the first three are why the discipline below is affordable at all:

• Skipping is cheap. You can pass over what doesn't touch the cluster in flight without ever paying for its body. An arrival that costs a paragraph to ignore would make "not an interrupt" a slogan; an arrival that costs a line makes it a rule you can actually keep.
• The version is a fence. Fetch and act against the version the frame named; if it moved since, someone else is working the same node — read before you write over them.
• Delivery is at-least-once. The same event can arrive twice; deduplicate by the id the frame carries. Idempotence is the receiver's job, not the sender's.
• A frame can arrive cut, and a prefix reads exactly like a whole message. This is measured, not feared: whatever layer you read the socket with may cap the line, and what survives is the part the sender wrote. Catch it rather than guess at it — the frame states its own body length. Compare that against the body as it travelled, its serialized form with quoting and escapes included, not against the text you unpacked from it: a body carrying newlines or quotes is longer on the wire than in hand, so measuring the wrong one calls a whole message a prefix and sends you re-reading what you already have. Re-read the whole of it one message at a time, at the read-back address handed to you with the socket, using the id off the frame. The cut is usually your own reader, not the sender — measured: a frame well under the ceiling, accepted without refusal, still arrived truncated. And the repair has a seam worth knowing: the read-back needs that id exactly, while your only copy of it may be text your harness rendered for you. A wrong id answers unknown message, which is indistinguishable from one that never existed — so if it fails twice, stop trying variants and ask the sender to resend the substance. Two calls is the honest budget for a transcription you cannot verify. Never act on the fragment, and never let the fragment's contents stand in for judgement: provenance is what says who spoke, and provenance is precisely what a cut takes first. As sender, the same fact points the other way — the longer your text, the more surely it displaces what the other side judges it by, which is why substance belongs on the node and the frame carries its ref.

"Pointer, not payload" is a rule about a reader who can open the pointer. Everything above assumes a doer with the graph at hand, for whom a node ref costs one call to expand. A person reading the same frame on a phone cannot expand anything at all: the number is the end of the road, not the start of one. Witnessed — an escalation went up as a frame naming a vimarsha's number instead of the question, and the reply was "why are you complaining to me? I have no idea what NNNN is." The word was delivered, read, and useless, while the sender counted the move as made because nothing had refused it.

So the rule splits by addressee, and the same author who honours it in one place will break it in the other unless the split is said out loud:

• To a doer with the graph: the ref plus why now. Short, and the body is fetched.
• To a person: the question itself, in words, with what it costs to decide either way. The ref goes at the tail, for whoever might want and be able to look — never in place of the substance. Putting the essence up front is not decoration; it is what makes the message answerable at a glance, and a practice that has run multi-round technical exchange this way confirms the form holds.

And the test changes with it. For a doer, "did it go" is nearly enough, because they can open what you pointed at. For a person the only test that means anything is: can they answer without opening a single thing? If the answer is no, the frame is undelivered in every sense that matters, whatever the send returned.

Which kind you are writing to is knowable before you send, not after. Two readings, and they compose. The karta's kind says whose will stands behind the role — 主 is a person's, 能 is a doer's. The standing says what actually reads the frame: a bridge into someone's chat means a person is at the other end; a working copy or a deployment means a doer with the graph at

…(truncated)