Idea. Who may access a document must be a pure function of a set of signed certificates, so every replica computes the same answer, in any order, with no referee.

Why it matters. Without this, two of your own devices can disagree about who may edit, and there is nobody to settle it.

Context assumed. Local-first: every device holds the whole document and edits merge. Public keys sign things.

Metaphor. A bag of signed notes. Pour it out in any order; the answer is the same. Breaks at: how the answer is computed from the notes (that is unit 2's wiring).

Misconception. Permissions are a table somewhere, and granting access means editing a row.

Visual language. The bag; two devices side by side showing the same answer.

Target length. 70 to 90 seconds.

Check question. Why can Keyline not store "Carol may edit" as a fact that gets updated?

Script:

In local-first software, every device holds the whole document. Edits merge whenever devices meet. So who is allowed to edit? (Screen: two devices, one document, a question mark.)

With a server, that is a table, and the server decides. Here there is no server. Each device has to decide alone. (Screen: a server with a table fades out.)

And they all have to agree. If your laptop says Carol may edit, and your phone says no, one device keeps her edits and the other throws them away. (Screen: two devices disagree; Carol's edit lands on one, bounces off the other.)

Keyline never stores the answer. It computes it, every time, from a bag of signed notes. The notes are called certificates. (Screen: a transparent bag of signed notes.)

There are two kinds. A delegation: Alice says Bob may edit this document. A revocation: Alice takes that note back, naming it by its hash. (Screen: one green note, one red note pointing at it.)

Notes are only ever added. Nobody edits one. Nobody deletes one. Merging two bags is pouring them together. (Screen: two bags pour into one.)

The answer depends only on which notes are in the bag. Never on the order they arrived. Same bag, same answer, on every device. (Screen: the bag is shaken; both devices show the same answer.)

That is the whole constraint. No clocks. No order. No referee. Just the bag. (Screen: the bag alone.)

Idea. A delegation is not a proof you carry. You hold authority only while an unbroken chain of live delegations runs from the subject to you, and the verifier finds that chain by searching the whole set.

Why it matters. This is the one design decision the rest of Keyline follows from: late binding, cascade, revival, and order independence are all consequences.

Context assumed. Unit 1: certificates, the bag, same answer everywhere.

Metaphor. A wall socket and daisy-chained power strips. You have power if current reaches you. Breaks at: levels (unit 3). Direction is stated once at beat 4: current runs from the socket outward, the reverse of a cord.

Misconception. A certificate is like a ticket or a key card: valid on its own terms when you present it.

Visual language. Socket, strips, cords, current as a moving line; a UCAN-style ticket with a chain printed on it for contrast.

Target length. 100 to 120 seconds.

Check question. Bob signs a delegation to Carol while Bob himself has no access. What happens when Bob is later given access?

Script:

In most systems, a credential is a ticket. You show it at the door, and the door checks the ticket itself. The ticket carries its own proof. (Screen: a ticket with a chain printed on it, checked at a door.)

A Keyline delegation carries no proof. It says who signed it, who it is for, what it is about, and how much power. That is all. (Screen: a note with four fields and no chain.)

So how is it checked? Picture the document as a wall socket. Each delegation is a power strip, plugged into another strip. (Screen: a wall socket; power strips chained outward.)

You have power if current reaches you. It flows out of the socket, through every strip, to your device. Not because your strip says so. Because current arrives. (Screen: current flows from the socket out to a device, which lights.)

Bob can plug Carol in before Bob has any power. Her cord just sits there, dark. The moment someone plugs Bob in, Carol lights up. Nothing is re-signed. (Screen: Carol's cord into Bob while Bob is dark; Bob plugged in; Carol lights.)

Unplug Bob, and Carol goes dark. Her certificate did not change. It is not revoked. It is dead. No current reaches it. (Screen: Bob unplugged; Carol dark, cord still drawn.)

Plug Bob back in, and Carol returns. Same certificate. Same signature. (Screen: Bob plugged back in; Carol lights.)

Junk is harmless. A ring of strips with no path to the wall carries nothing. Anyone can sign anything. Only routes matter. (Screen: a loop of strips floating, dark.)

A certificate is never valid or invalid on its own. It is live or dead, in the context of the whole bag. (Screen: the bag, with lit and dark notes inside.)

Idea. Your power over a subject is the maximum over routes of the minimum power along each route. Levels clamp, they never reject.

Why it matters. It explains why delegating more than you hold is not an error, and why a second route is insurance.

Context assumed. Units 1 and 2.

Metaphor. A breaker on each strip caps what flows through it; two cords to the wall and you get the better one. Breaks at: real breakers trip, these only cap. Say so.

Misconception. Delegating a higher level than you hold is rejected or is an attack.

Visual language. Breakers labelled relay, read, edit, admin; two chains to one device.

Target length. 70 to 90 seconds.

Check question. Alice holds Read and delegates Admin to Carol. Dan holds Edit and delegates Edit to Carol. What is Carol's power?

Script:

Power comes in four levels. Relay, read, edit, admin. Relay carries content it cannot read. Admin can act on the wiring itself. (Screen: a ladder of four levels.)

Every strip has a breaker, set to its level. You never draw more than the weakest breaker on your chain. (Screen: a chain of strips, each with a breaker dial.)

Alice has edit. She writes admin on Carol's certificate. Not an error. Carol gets edit. (Screen: Alice's breaker at edit; Carol's note says admin; Carol's lamp shows edit.)

Why not reject it? Alice might be given admin tomorrow. Then Carol's certificate, unchanged, carries admin. A certificate states a ceiling, not a fact. (Screen: Alice's dial turns to admin; Carol's lamp rises to admin.)

Two chains? Carol is plugged in through Alice at edit, and through Dan at read. She gets the better one. Edit. (Screen: two chains into Carol; the brighter one wins.)

Minimum along a route. Maximum across routes. (Screen: the rule, as a title.)

The second chain is insurance. If Alice's chain breaks, Carol still has read through Dan. There is never one brittle proof to lose. (Screen: Alice's chain cut; Carol dims to read, stays lit.)

Idea. A subject bootstraps its own authority by signing exactly one certificate to a root role and then destroying its signing key, so its identity is permanent and its authority lives elsewhere.

Why it matters. It answers where the first wire comes from, and sets up the one thing in Keyline that can never be rebuilt.

Context assumed. Unit 2. The setup fact that every node, including a document, is a public key is stated at beat 1.

Metaphor. The socket wires itself and then there is no electrician to call. Spoken at beat 5. Breaks at: a real socket can be rewired.

Misconception. The creator's key is special, or the document belongs to whoever made it.

Visual language. A document box with a key icon; one cord to a box labelled Owners; the key shatters; a second small key for Owners that also shatters.

Target length. 80 to 100 seconds.

Check question. Who can sign a second root edge for a document?

Script:

Everything in Keyline is a public key. People, devices, groups, documents. The graph does not know which is which. (Screen: four boxes, all with the same key icon.)

So a document has a key, and a key can sign. Where does the first wire come from? The document signs it itself. (Screen: the document box signs a note.)

At creation, the document's key signs one delegation, to a fresh key called Owners. Owners' key signs the creator in. Then both private keys are destroyed. (Screen: cord from socket to Owners; cord from Owners to the creator; both private keys shatter.)

The document's public key is its identity. That is permanent. Its authority now lives somewhere else. In Owners. (Screen: the socket stays; a glow moves to Owners.)

Why destroy the keys? Whoever held the document's key could rewire the socket. Destroying it makes that first edge the one thing nobody can replace. (Screen: a hand reaches for the socket and finds no key.)

That is a trade. Everything below the root can be rebuilt. The root itself cannot. (Screen: the tree below Owners flickers and rebuilds; the root edge stays fixed.)

And the creator is just the first member of Owners. Nothing about their key is special. (Screen: the creator plugs into Owners like anyone else; a second owner joins.)

Idea. A certificate's subject is a scope. About a document, it helps you reach that document and nothing else. About a role, it is membership, and it carries whatever the role reaches, now and later.

Why it matters. This is how fifty documents and ten people stay sixty certificates instead of five hundred, and why adding a document re-issues nothing.

Context assumed. Units 2, 3 and 4 (a role is minted the way a document is).

Metaphor. A role is a strip that gets wired into many sockets. Plug into the strip and you get every socket the strip is ever wired into. Breaks at: nothing new.

Misconception. A group is a list of people stored somewhere, or a special object type.

Visual language. Members as a wide strip; supplies as cords from sockets into it; memberships as cords from people into it.

Target length. 90 to 110 seconds.

Check question. Members is supplied into a new document tomorrow. What has to be re-issued for Alice to use it?

Script:

Ten people. Fifty documents. One certificate per person per document is five hundred. Every new hire is fifty more. (Screen: a grid of cords filling the screen.)

Keyline has no group object. A role is just another key. Mint it, have it sign Dan in as admin, and throw the private key away. (Screen: a strip labelled Members; its key shatters.)

Two kinds of certificate hang off a role. A supply: Dan gives Members edit over the document. A membership: Dan puts Alice in Members. (Screen: cord from the socket to Members; cord from Alice into Members.)

Alice's power over the document is the smaller of two things. What Members has over the document. And what Alice has in Members. (Screen: two breakers in series.)

A certificate about the document helps you reach that document. Nothing else. A certificate about Members is a membership. It carries everything Members reaches. Now, or in the future. (Screen: Alice's cord highlighted; every socket Members touches lights through it.)

New document? One supply. Every member has it at once. Nobody re-issues anything. (Screen: a new socket wired into Members; all members light.)

Someone leaves? Take back one membership. They are out of all fifty. (Screen: one cord unplugged; fifty sockets go dark for that person.)

A membership is a promise about the future. Whatever Members is wired into later, every member reaches it. Each at their own level. (Screen: Members wired into something new; every member's lamp lights at its own level.)

Idea. A revocation names one delegation by hash and deletes nothing. Everything that depended on it dies implicitly, because liveness is recomputed from the whole set.

Why it matters. It is why a revocation means the same thing on every replica even though replicas have seen different certificates.

Context assumed. Units 2 and 5. Dan may revoke Alice's membership because he issued it; unit 7 gives the general rule.

Metaphor. Unplugging one cord. Everything downstream goes dark; nothing downstream changed. Breaks at: nothing new.

Misconception. Revoking removes a person, deletes certificates, or has to list what it cancels.

Visual language. A hand unplugging a single cord; downstream strips going dark with cords still drawn; a red note in the bag next to a green one.

Target length. 70 to 90 seconds.

Check question. Dan revokes Alice's membership. Is Carol's certificate revoked, dead, or live?

Script:

A revocation says: I take back that certificate. It names one delegation, by its hash. Not a person. Not a key. (Screen: a red note pointing at one green note.)

Nothing is deleted. The delegation stays in the bag forever. The revocation sits beside it. (Screen: both notes in the bag.)

Dan takes back Alice's membership. One certificate named. But Carol's membership was issued by Alice. Unplug Alice, and Carol goes dark. (Screen: a hand unplugs Alice; Carol's lamp goes out.)

Carol's certificate was not revoked. Nobody named it. It is dead. There is no route to it. That is the cascade. (Screen: Carol's cord still drawn, dark.)

Why not list everything the revocation cancels? Because Dan's device may not have seen Carol's certificate yet. Two devices would write two different lists. (Screen: two devices, two different lists on the same red note.)

So a revocation names one thing. One hash. One signature. The same meaning everywhere. (Screen: one red note, identical on both devices.)

If Carol had a second route, through Dan, that route is untouched. Carol keeps her access. (Screen: a second cord into Carol stays lit.)

A revocation unplugs one cord. Whatever goes dark, goes dark because of the wiring. Not because it was named. (Screen: wide shot: one unplugged cord, a dark subtree.)

Idea. Every well-signed revocation is accepted. Its effect is scoped to where its signer stands: their own hop, their own signatures, or any route through a node they hold admin over. The set of nodes you hold admin over, plus your own node, is your admin reach.

Why it matters. Admin is not a rank. It is a set of rooms, and knowing which rooms tells you exactly which cords you can pull, and which you cannot.

Context assumed. Unit 6.

Metaphor. A key to a room lets you pull any cord that runs through that room, however far downstream it goes. You have no key to rooms above you. Breaks at: nothing new.

Misconception. Admin is a rank, so an admin of Members can cut the supply that feeds Members.

Visual language. Dashed rooms around strips; a keyring; cords running through rooms. All revocations are unplugs.

Target length. 110 to 130 seconds.

Check question. Bob is an admin of Members. Can he revoke Dan's supply of the document into Members?

Script:

Any well-signed revocation goes into the bag. The question is never whether it is valid. The question is what it covers. (Screen: a red note enters the bag, no gate.)

First: your own strip. Carol invited Eve. Carol can unplug Eve from her own strip. That cuts routes through Carol, and nothing else. (Screen: Carol's strip; she unplugs Eve's cord from it.)

Second: your own signatures. If you signed a certificate, as giver or receiver, you can kill it on every route. When your key leaks, you can cut everything that names it. No one to ask. (Screen: a note with two signatures; either party unplugs its cord.)

Third: admin. Admin over a node is a key to that room. You can unplug any cord that runs through your room, however far downstream. (Screen: a keyring; a dashed room around Members; Eve's cord far downstream unplugged.)

Your rooms, plus your own strip, are your reach. Admin in Owners, and Owners is admin over Members? Then you have a key to Members too. (Screen: Bob's keyring gains a second key.)

What you cannot do: cut the cord you stand on. The supply that feeds Members runs through rooms above you. Your revocation of it does nothing. (Screen: a hand reaches for the supply cord; it runs outside the room; nothing happens.)

A revocation that touches none of your rooms, and none of your signatures, is a no-op. Not an error. Just inert. (Screen: a red note in the bag, greyed, no effect.)

Admin is not a rank. It is a set of rooms. Your revocation power is exactly the cords that run through them. (Screen: keyring over the floor plan.)

Idea. Admin reach is computed as if no revocation existed, so it only ever grows. That is what lets two concurrent revocations land the same way on every replica.

Why it matters. Without it, removing a moderator would un-ban everyone they banned, and two devices could disagree.

Context assumed. Unit 7, and the order rule from unit 1.

Metaphor. First draw the map with every cord plugged in, then make the cuts. Breaks at: nothing new.

Misconception. A removed admin should lose their revocation power the moment they are removed.

Visual language. Two passes shown as two layers: a full wiring map, then red cuts laid over it.

Target length. 90 to 110 seconds.

Check question. Why can a replica not shrink Bob's reach after Dan removes him?

Script:

Your reach is every room you have ever held a key to. Ever. Not currently. Here is why. (Screen: a keyring whose keys never leave it.)

Two revocations at the same moment. Dan removes Bob from Members. Bob, still an admin as far as he knows, removes Eve. (Screen: two red notes appear at once on two devices.)

Suppose Bob's reach depended on being an admin right now. A device that sees Dan's note first ignores Bob's. Eve stays. A device that sees Bob's note first removes Eve. Same bag. Different answers. (Screen: two devices, two outcomes.)

So Keyline works in two passes. Pass one ignores every revocation and draws the full map. Who ever stood where. That fixes everyone's reach. (Screen: layer one: the full wiring, everything lit.)

Pass two applies all the revocations to that map. Revocations never look at each other. Both land. Everywhere. In any order. (Screen: layer two: both cuts drawn, identical on both devices.)

Removing a moderator does not un-ban the people they banned. Quitting does not un-ban anyone either. And two devices never disagree. (Screen: three small icons.)

Reach only grows. And more reach only ever removes access. The surprise, if any, is always in the safe direction. (Screen: a keyring gains a key; a lamp goes dark.)

The price: a removed admin keeps the keys to every room they ever had. That is the sharp edge. (Screen: Bob, removed, still holding his keyring.)

Idea. No later message can undo an applied revocation, and re-issuing the identical certificate produces the identical, already-revoked hash. So a repair is a fresh grant that cites the revocation, which makes the heal a new, accountable certificate.

Why it matters. Every return of access is a fresh signature from live authority, never a message arriving in a lucky order, and never a silent duplicate.

Context assumed. Unit 8 (revocations are permanent). This is the optional tag promised in unit 2.

Metaphor. A cut cord stays cut; you run a new cord with a tag on it. Breaks at: nothing new.

Misconception. There is an undo, or re-issuing the same certificate restores access.

Visual language. A cut cord left in place; a new cord with a small tag (the citation) tied to it.

Target length. 80 to 100 seconds.

Check question. Dan re-signs Alice's membership byte for byte. Does Alice regain access?

Script:

Once a revocation is applied, nothing can undo it. A revocation can name a delegation. It cannot name another revocation. There is no undo to write. (Screen: a red note trying to point at a red note; it cannot.)

So how do you fix a mistake? You grant again. You run a new cord. The old revocation stays in the bag forever. (Screen: a new cord beside the cut one.)

One wrinkle. Certificates are named by their hash. Re-issue the identical delegation, and you get the identical certificate. Already revoked. (Screen: two identical notes merge into one, still crossed out.)

So the new grant carries a tag: the hash of the revocation it is healing past. Different bytes. Fresh hash. And it says, on the record: re-granted, knowing of the removal. (Screen: the new note with a tag pointing at the red note.)

The tag means nothing to the evaluator. It is not an undo. It only changes the hash. A wrong tag is harmless. (Screen: the evaluator ignores the tag.)

Why not random bytes? Then two accidental copies of a grant would be two live certificates. Revoke one, and the other stays. That fails open. With the tag, copies collapse into one, and one revocation covers them all. (Screen: random tags: two cords, one cut, one still lit; the tag: one cord, cut.)

Every return of access is a fresh signature from someone with live authority. Never a message arriving in a lucky order. (Screen: the new cord lit; the bag has one new note.)

Idea. Re-adding a key revives every certificate it ever issued, with the same hashes and provenance. That is a one-certificate repair and a hazard, so a removal after key compromise must come back with a fresh key.

Why it matters. It decides what removing someone actually does, and the fresh-key rule is the one operational habit everyone needs.

Context assumed. Unit 2 beat 7 (plug Bob back in), unit 6, unit 9 (cited grant).

Metaphor. Plug the strip back in and everything on it lights up, including the devices you forgot were there. Breaks at: nothing new.

Misconception. Removing someone clears what they set up.

Visual language. Alice's strip replugged; a whole subtree lighting, with one forgotten device among them; a new key icon for fresh-key re-add.

Target length. 80 to 100 seconds.

Check question. Alice's key was stolen and she was removed. Later "Alice" is re-added with the same key. What happens?

Script:

When Dan removed Alice, Carol went dark. Carol's certificate is dead. Not revoked. Now the difference matters. (Screen: Carol dark, cord intact.)

Dan re-adds Alice. Her strip is plugged back in. Carol lights up. And so does everything else Alice ever wired. Same certificates. Same hashes. (Screen: Alice plugged back in; the whole subtree lights.)

As a repair, that is wonderful. Remove by mistake, re-add, and the whole subtree returns for one certificate. Everyone except Eve? One re-add, one revocation. (Screen: subtree lit; one cord to Eve unplugged.)

As a hazard, it is the same thing. Re-add a key, and you revive certificates everyone forgot. Including ones a thief signed while they held that key. (Screen: a forgotten device lights; its note bears a thief's mark.)

So, after a compromise, re-add the person with a fresh key. The old key never returns. Its certificates stay dead forever. (Screen: a new key icon; the old strip stays dark.)

And when a removal must survive any future re-add, revoke what they issued, not just their membership. Explicit revocations are permanent. (Screen: red notes on each of Alice's issued certificates.)

Three kinds of removal. Implicit: reversible. It revives on re-add. Explicit: durable. What you keep must be re-issued. Fresh key: the old key simply never comes back. (Screen: three rows: implicit, explicit, fresh key.)

Dead and revoked are different states. The difference is one question. Will it come back? (Screen: two notes: one dark, one crossed out.)

Idea. A removed admin keeps their frozen reach forever and can still sign revocations that cover it, so durable removal of an admin requires rotating the role to a fresh key.

Why it matters. Revoking an admin's membership alone is not a removal. Every team will hit this.

Context assumed. Units 8 and 10; the creation-edge move from units 4 and 5.

Metaphor. Fired, but still holding keys to the rooms they had. Keyrings never shrink, so you run the cords through a new room. Breaks at: nothing new.

Misconception. Revoking an admin's membership removes their power.

Visual language. Bob outside the building with a keyring; a new room labelled Members prime; cords moved over one by one; the old room left standing, dark.

Target length. 120 to 140 seconds.

Check question. Dan revokes Bob's admin membership and does nothing else. Can Bob still cut new members?

Script:

Bob was an admin of Members. Dan removes him. Bob cannot read, write, or grant anything. But Members is on his keyring. And keyrings never shrink. (Screen: Bob outside the building, holding a keyring.)

So Bob can keep signing revocations that cut through Members. Against members added years later. There is no clock. His old notes and his new notes look the same. (Screen: Bob's hand reaches through the Members room and unplugs a new cord.)

He cannot take anything. Every note is signed. This is griefing, not theft. But it is forever. Unless you move. (Screen: red notes with Bob's signature piling up.)

Rotation. Mint a fresh role. Members prime. Its key signs the surviving admins in, and is destroyed. Dan wires the document into Members prime, and unplugs the old supply. (Screen: a new room, Members prime; its key signs two cords and shatters; supply cord moved.)

Then the members who stay get re-added. One certificate each. The roster is the whole job. (Screen: members replugged one by one.)

Everything below comes back by itself. A team Alice wired up from Members keeps working. Nothing re-signed. (Screen: a downstream subtree lights as soon as Alice is replugged.)

Bob's keys now open a room that routes nothing. His revocations stop biting. Even the good ones. The survivors re-sign those. (Screen: Bob's keyring greyed; survivors re-issue two red notes.)

The survivors' keyrings grow to include Members prime. Their old revocations keep working. (Screen: survivors' keyrings gain a key.)

One hazard. The old room is dormant, not demolished. Its roster is still wired inside. Wire a document into old Members again, and every former member lights up. And Bob's keys work again. (Screen: the old room, dark, roster intact, a warning sign on its door.)

After removing an admin, rotate the role. Otherwise the removal is not durable. (Screen: the rule, as a title.)

Idea. A document cannot rotate. Admin over it puts the document itself in someone's reach forever, and admin over a document buys nothing else. So root the document at Edit and supply roles at Edit, unless the owners are the document.

Why it matters. It is the one setup decision that decides whether any removal in your document can ever be durable.

Context assumed. Units 4 and 11.

Metaphor. The socket in the wall cannot move. Give someone a key to the socket's room and they keep it forever. Breaks at: nothing new.

Misconception. Administering a document needs Admin over the document.

Visual language. The socket fixed in the wall with a dashed room around it; the root edge's breaker; a supply breaker.

Target length. 100 to 120 seconds.

Check question. A document is rooted at Admin. Members is supplied at Edit, Bob is removed from Members and Members is rotated. Can Bob still revoke the root edge?

Script:

Rotation works because a fresh node comes after the ex-admin. No fact will ever put it on his keyring. (Screen: Members prime appears; Bob's keyring unchanged.)

But one node can never be fresh. The document itself. It is the socket in the wall. (Screen: the socket, fixed in the wall.)

Can the socket be on anyone's keyring? Only if someone holds admin over the document. That is set by the root edge's level, chosen once at creation, and by each supply's level. (Screen: the root edge with a breaker; a supply with a breaker.)

Root the document at admin, and every admin of Owners, ever, has the socket on their keyring. Rotate all you like. Each of them can unplug every cord in the socket's room. One revocation kills the document. (Screen: a dashed room around the socket; several keyrings hold its key; a hand unplugs the root edge.)

What does admin over a document buy? Reading, writing, inviting, managing a role. None of it needs admin over the document. Admin over a document is only the power to destroy it. (Screen: a list of actions; admin ticks none except unplugging the socket.)

So root at edit. Supply roles at edit. Then the socket is on nobody's keyring, and rotation always escapes. Root at admin only when the owners are the document, and ending it is the point. (Screen: the root breaker set to edit; the socket room has no key.)

The level is fixed at creation, and anyone holding the bag can see it. It is a fact about the document, not a policy. (Screen: a document labelled rooted at edit.)

Idea. Only Admin-level memberships add to anyone's reach. Giving an upstream role Admin over a child role puts the child on every upstream admin's keyring forever, so nest only when seniors should act inside the child; otherwise control a role through its supply, and hold people as members at a level.

Why it matters. It is the wiring convention that makes rotation exactly the roster and keeps the griefer set small.

Context assumed. Units 7 and 11.

Metaphor. A key to a room versus a key to the fuse that feeds it. Breaks at: nothing new.

Misconception. Nesting roles is just organisation, and more members means more people who can cut you off.

Visual language. Two floor plans: a role nested inside another's dashed room, and a flat layout where the parent holds only the supply cord.

Target length. 90 to 110 seconds.

Check question. Moderators is given Admin over Team X. Later Moderators is rotated. Do its former admins still have Team X on their keyrings?

Script:

Reach comes from one thing: holding admin over a node. Read and edit memberships add nothing to anyone's keyring. (Screen: a keyring; edit and read cords pass by without adding keys.)

So inviting a thousand editors adds nobody who can cut you off. An editor can still invite others, at or below their own level. Those invitations ride the editor's own strip, and die with it. (Screen: a thousand editors; keyrings unchanged.)

Now a choice. Wire Moderators in as an admin of Team X. Then everyone who was ever a Moderators admin holds a key to Team X. Forever. Rotating Moderators does not take it back. (Screen: Moderators nested inside Team X's dashed room; many keyrings gain the key.)

Or keep Team X flat. Its admins are named people. Moderators holds only the cord that feeds it. Control from above is total but coarse: unplug the supply, wire a successor. (Screen: flat layout; the parent holds one supply cord outside the room.)

Nest when seniors should be able to act inside the junior role. Keep it flat when the role should be governed only as a whole. Nesting is permanent. Supply control is not. (Screen: side by side, with the rule.)

One shape makes this hold. People are members of roles, at a level. The only certificates about a document itself are supplies. Then an ex-admin's reach is exactly the rosters they sat on. (Screen: the clean shape: socket, supplies, roles, people.)

Give admin only over things that can be rotated. And give it to people, not to roles. (Screen: the rule, as a title.)

Idea. Removal from the root role is never durable, because only the destroyed subject key could sign a new root edge. So the root role is kept minimal and used rarely, like a root certificate authority.

Why it matters. It is the one place in Keyline where a mistake cannot be rotated away, and it decides how to set a document up.

Context assumed. Units 4, 8 and 12 (rooting level).

Metaphor. The socket wired itself; there is no electrician to call. Spoken at beat 1. Breaks at: nothing new.

Misconception. Owners are just top-level admins under the same rules as everyone.

Visual language. The root edge drawn thicker and fixed; Owners as a very small room; two owners unplugging each other.

Target length. 100 to 120 seconds.

Check question. Why can the Owners role not be rotated?

Script:

Every role can rotate, except one. Rotating Owners needs a new root edge. Only the document's key could sign it, and that key was destroyed. (Screen: the root edge, fixed; the shattered key.)

So everyone who ever held admin in Owners keeps Owners on their keyring. And every route in the document passes through Owners. Removal from the root role is never durable. (Screen: an ex-owner's keyring with the Owners key; every route passes through the Owners room.)

Rooting at edit keeps the root edge itself off every keyring. But an ex-owner can still unplug the owners' memberships, inside Owners. Then the document goes dark. (Screen: memberships inside Owners unplugged; everything dark.)

Two owners can revoke each other at the same time. Both land. Below the root, whoever feeds the role rotates it and picks who stays. In the root role, there is no one above. If all the owners unplug each other, nobody can ever be added again. (Screen: two owners unplug each other; the room is empty; nothing above.)

So keep the root role tiny. One key per human owner, or just the creator. Do all the churn in roles below, where rotation works. (Screen: a tiny Owners room; a busy Members room below.)

One escape hatch. If the document's key was kept, in cold storage, it can cut the old root edge and wire a fresh Owners. That only helps when the document is rooted at edit. (Screen: a key in a safe; a new Owners room wired in.)

And whoever holds that key can re-root out from under you, too. Destroy it, or guard it. (Screen: the safe, with a warning.)

Idea. X can deny Y's access iff every live route from the subject to Y transits X's admin reach. So availability is a min-cut over roles, and the power is deny-only and attributable.

Why it matters. It turns a vague fear, that anyone upstream can grief you, into something you can compute and design around.

Context assumed. Units 7, 11 and 13.

Metaphor. Rooms again. Two cords through the same room are one cord. Breaks at: nothing new.

Misconception. More collaborators means more risk, or any second route is protection.

Visual language. A floor plan; Y's routes drawn through rooms; X's keyring; a cut line across the rooms. Upstream rooms drawn smaller with fewer keyrings.

Target length. 90 to 110 seconds.

Check question. Carol has two routes to the document, both through Members. Does the second route protect her from an ex-admin of Members?

Script:

Reach is where you hold keys, plus your own strip. A revocation unplugs cords in your rooms. So when can X cut off Y? (Screen: a floor plan; X's keyring; Y's routes.)

Exactly when every live route to Y passes through a room X holds a key to. Or through X's own strip. Not more. Not less. (Screen: all of Y's routes highlighted through X's rooms.)

A second route protects you only if it runs through different rooms. Two cords through the same role are one cord. (Screen: a second route through the same room, still cut; through a different room, it survives.)

Who holds keys? Admins. Only admins. The one exception is your inviter: if your only route runs through their strip, they can unplug you from it. (Screen: a thousand editors; keyrings unchanged; one inviter's strip highlighted.)

And it is bounded. They can never read, write, or escalate. Every revocation is signed, so a spree is a confession. Nothing is taken from you. You keep your copy, and everything you already decrypted. (Screen: three icons.)

Rooms near the socket sit on more routes. But fewer people ever held keys to them. The root can cut everything. That is just ownership. (Screen: upstream rooms drawn smaller, with fewer keyrings.)

Any system where removal is durable hands every remover this power. Keyline chose durable, then shrank the surface: reach, rotation, flat roles. (Screen: the rule, as a title.)

Idea. A replica can never prove it holds every revocation. But merging is union and revocations are permanent, so withholding one can only delay it, and a single honest peer repairs the omission.

Why it matters. It is the trust story: what a malicious or lazy peer can and cannot do to you without a server.

Context assumed. Units 1, 8 and 9.

Metaphor. The bag and the red note. Breaks at: nothing new.

Misconception. Without a server, a malicious peer can hide revocations and keep access indefinitely.

Visual language. Two bags of different sizes; a red note held back by one peer, delivered by another.

Target length. 80 to 100 seconds.

Check question. A peer hides a revocation from you. What bounds the damage?

Script:

No certificate can be judged alone. Only against a bag. And your bag might be missing something. (Screen: a bag with a gap in it.)

Miss a revocation, and you keep honouring access the full set has revoked. Until you sync. That is the window. (Screen: a lamp still lit that should be dark.)

Can a dishonest peer keep you in that window forever? No. The moment any peer shows you the red note, it applies. And nothing can ever undo it. (Screen: one peer withholds; another delivers; the lamp goes dark for good.)

One honest peer is enough. A withholder can delay. Never prevent. (Screen: the rule, as a title.)

The other direction exists too. If you never saw the note that made K an admin, you treat K's revocations as inert. Short on delegations means short on revocations. As notes arrive, coverage only grows. (Screen: a missing green note; a red note greyed; the green arrives; the red bites.)

Nobody can prove their bag is complete. Absence cannot be witnessed. What you get is weaker, and enough. You can be late. You can never be wrong in the open direction for good. (Screen: closing card.)