One idea: Willow is a protocol family for independent spaces that keep deletion and privacy and work when scaled down. Yes.

Beats serve it: yes. Beat 5 is a roadmap, which is acceptable in a framing unit.

Metaphor: none declared. The guide says every unit needs one; a framing unit is the one defensible exception. Note only.

Assumptions: none. Fine.

Misconception ("Willow is one app or network") addressed at beat 1: yes, "Small private networks, next to big public ones."

Length: about 62 s. In range.

Claims: all supported by the home page and "Why Willow". "Two laptops and a cable should still work" is an illustration of "temporary loss of signal, natural disaster, or war" and is fair.

Verdict: pass. If unit 24's authorship beat is cut (see unit 24), its content belongs here or nowhere.

One idea: a name can get new contents or none; the hash is inside the record. Yes.

Beats: yes.

Metaphor (shelf label) carries and the break is spoken at beat 3. Good.

Assumptions: unit 1 only. Fine.

Misconception (content addressed like IPFS) at beat 1 and 2: yes.

Length: about 56 s. In range.

Claims:

A1 (W) Beat 4: "Take the book away, and the shelf is empty. That is what makes deletion possible." In Willow nothing is taken away; deletion is a newer write. Data model: "By writing a new entry at blog idea, our previous entries are deleted. Think of it as overwriting a directory in a file system with an empty file." The viewer leaves with a removal model that unit 6 then has to undo. Fix: "Put an empty book there, and the old one is gone. That is deletion." The check question still works.

Beat 1 and beat 5 supported by the comparison page ("Willow employs explicit naming of data ... bind data to a freely chosen name") and the Entry definition.

Verdict: back to 1b, beat 4 only.

One idea: a name has three parts. Yes.

Beats: yes.

Metaphor (building, room, shelf label): carries. It is also Meadowcap's own metaphor ("Metaphorically, everyone has their own private space in the same building"), which is a good sign.

Assumptions: unit 2. Beat 3's screen hangs "a person's key" by each room before any unit says what a key is (S1, see unit 9). Narration does not say "key", so this is a screen-only leak; drop the keys from the screen here.

Misconception ("a subspace is a folder") is said to be addressed at beat 3, but beat 3 never contrasts with a folder; it only says "room". Weak but tolerable since beat 4 immediately calls the path "like folders", which gives the contrast by position.

Length: about 48 s. In range.

Claims: beat 2 supported by the home page ("All spaces are completely independent"); beat 3 by the data model ("each user writes to their own, separate universe of data").

Verdict: pass (remove the keys from the beat 3 screen).

One idea: card versus parcel. Yes.

Beats: yes.

Metaphor (index card, parcel): carries.

Assumptions: unit 3. Fine.

Misconception ("an entry contains the data") at beat 4: yes.

Length: about 50 s. In range.

Claims:

A2 (O) Beat 4: "Up to sixteen million terabytes, if you like." Source: "Willow can store arbitrary bytestrings of at most 2^64−1 bytes." That is 16 million tebibytes but 18.4 million terabytes. The guide says a number needs its source line; this one has it and still misrenders it. The number does not serve the idea. Cut it, or say "any size up to two to the sixty-fourth bytes".

A17 (X) Beat 3 calls the payload digest "a fingerprint of the contents". Unit 16 then uses "fingerprint", the spec's own term, for the hash of a whole region. Two different things, one plain word, twelve units apart. Fix here, not in 16: "And a hash of the contents: the payload digest." Rename the unit "An entry is a name, a time, and a digest."

S6 Screen: by beat 3 the card shows namespace, subspace, path, timestamp, digest, length: six things. Draw the name as one block ("name") so the card never shows more than four.

Beat 5 supported by the RBSR page ("Once the two peers have reconciled their sets ... they can separately request any missing (suffixes of) Payloads").

Verdict: back to 1b (number, wording of beat 3, screen count).

One idea: the conflict rule. Yes.

Beats: yes.

Metaphor (newest card replaces the old on the shelf): carried in beat 1 and beat 4.

Assumptions: unit 4. Fine. Beat 1 says "same room, same shelf", which is exactly the scope the rule has.

Misconception ("conflicts need a merge step") at beat 5: yes.

Length: about 44 s. Inside the card's own 40 to 50 target, just under the brief's 45 floor. The idea is small; do not pad.

Claims: the three-step rule matches the data model verbatim. "Dropped. Not kept in a history" matches the join ("remove all Entries ...") and the URI footnote ("Conformant stores will delete the overwritten Entry"). "Willow calls this destructive editing" matches the home page ("Synchronisable data storage with destructive editing"). Beat 5 (no coordination) follows from the join being a pure function of the two sets.

Verdict: pass.

One idea: prefix pruning. Yes.

Beats: yes.

Metaphor:

A5 (X) Card says "Removing a shelf label removes every card under it." Nothing is removed in the mechanism: a new card is written at the label. The script (correctly) says "Write a newer entry at just blog", so the card's metaphor is not what the script does. Change the card to "A new card at a shelf label sweeps every card beneath it."

Assumptions: unit 5. Fine.

Misconception ("deleting needs a tombstone per item") at beat 5: yes.

Length: about 48 s. In range.

Claims:

A3 (M) Neither the idea, the card nor any beat says the rule works within one subspace only. Data model: "old.subspaceid == new.subspaceid, and new.path is a prefix of old.path, and new is newer than old." A viewer who holds units 3 and 6 will believe my newer "blog" can delete your "blog/ideas" in the same namespace, which is the exact property the timestamps page says Willow protects against ("An Entry with a high timestamp only overwrites Entries in the same subspace"). Fix beat 1: "In one room, a path is a sequence of parts." Fix the idea sentence the same way.

A4 (O) Beat 5: "Nothing left behind." The new entry at "blog" remains, with whatever payload it carries. The comparison page's "traceless data removal" supports the spirit, the data model's "overwriting a directory in a file system with an empty file" says what remains. Fix: "One card at blog. Nothing else."

S6 Screen at beat 2: label, three old cards, one new card: five things. Make the new card replace the label's slot, or drop one old card.

Verdict: back to 1b (same-room scope, "nothing left behind", card metaphor, screen count).

One idea: a store is a set; joins are order-independent; no history. The card lists three clauses but they are one idea (state-based CRDT). Yes.

Beats: yes.

Metaphor (pouring two boxes together): spoken at beat 2. Good.

Assumptions: unit 6. Fine.

Misconception ("sync replays a log"): beat 5 says no history; it does not say "no log to replay". Close enough; the post could say it outright.

Length: about 51 s. In range.

Claims: beat 1 matches "A store is a set of AuthorisedEntries such that all its Entries have the same namespaceid"; beat 3 and 4 match the footnote "No matter in which order and groupings the stores are joined, the result is always the same. Stores form a join semi-lattice (also known as a state-based CRDT)". Beat 5 follows from the definition.

Verdict: pass.

One idea: timestamps are author claims and the damage model follows from that. Yes.

Beats: yes.

Metaphor ("a date stamp held by the author"): the stamp is on screen but never spoken (S4, minor). Say "stamp" once in beat 1.

Assumptions: unit 5. Beat 4 uses "permissions" and "a key may claim" one unit before Meadowcap or keys exist (S2). The guide allows saying what the later unit says; it does not allow a term the viewer cannot place. Replace "a key" with "a writer" and "permissions" with "a write ticket, which comes later".

Misconception ("anyone with a fast clock can override your data") at beat 2: addressed but see A7.

Length: about 60 s. In range.

Claims:

A6 (W) Beat 1: "Nobody checks it against a clock." Beat 4 of the same unit says "peers may refuse entries too far ahead of their own time," and the timestamps page says "peers can and should simply reject incoming Entries that were created too far in the future compared to their local time." Beat 1 contradicts both. Fix: "No one can verify it."

A7 (O) Beat 2: "Your room is untouched by anyone else's clock." Source is conditional: "If you do not allow anyone else to write to your subspace, it does not matter how devilishly clever they choose their timestamps." In a communal namespace with delegated write tickets (unit 11), someone else's clock can reach your room. Fix: "If only you write in your room, no one else's clock can touch it."

A8 (O, minor) Beat 3: "blocks your later writes." Source: "you cannot create any new Entries with accurate timestamps (under the buggy path) until the buggily assigned time has passed." Add "under that path".

Beat 4's second sentence is supported (see the checks table). Beat 5 is supported: "tracking the happened-before relation accurately requires space proportional to the greatest number of concurrent events, a number we cannot bound in a peer-to-peer system."

S7 Beat 5 screen names "a vector clock" that the narration never says ("track causality"). Either say "vector clock" or draw "causality" some other way.

Verdict: back to 1b (beat 1, beat 2, terms in beat 4, screen at beat 5).

One idea: communal versus owned, decided by the id. Yes.

Beats: yes.

Metaphor:

S4 Card: "A club notice board versus a company file room." The screen draws them at beat 5; the narration says "a club where everyone keeps their own notes" and "a group where one party decides who writes". Neither "notice board" nor "file room" is spoken, and it is a second metaphor on top of the building. Drop it and use the building the series already has, which beat 2 and 3 do: rooms with their own keys versus one key over the door. The Meadowcap page uses exactly that split.

Assumptions:

S1 (dependency gap, series-wide) Beat 2 is the first time the series says "public key" and "signature", and nothing defines them. Unit 10 beat 4 half-defines them one unit later ("sign with the matching secret key"). Units 10, 11, 12, 18 and 22 all lean on this. The Anytwo lesson in the guide is exactly this case. Add two lines to beat 2 before "The subspace id is a public key": "A key pair is a public key anyone can see and a secret key only you hold. Only the secret key can make a signature that the public key checks." That costs about 8 s; the unit has room.

Misconception ("namespaces have an admin list") at beat 3: the beat says what owned namespaces do but never denies the list. Add "There is no list" to beat 3 or 4.

Length: about 59 s. In range even with the key-pair lines (about 67 s; trim beat 5).

Claims: beat 2 and 3 match Meadowcap ("Subspace IDs are public keys"; "peers reject all requests unless they involve a signature from the namespace keypair"). Beat 4: "the last bit of the key decides" is a fair gloss of "least significant bit is 0" (note in the checks table). Beat 5 matches "Owen has control over who gets to participate".

Verdict: back to 1b (key-pair definition, metaphor, misconception line).

One idea: an unforgeable ticket with four fields, checkable alone. Yes.

Beats: yes.

Metaphor (ticket) and its break ("the holder is a key, not a person") spoken at beat 4. Good.

Assumptions: unit 9 (with the key-pair fix). Beat 3 defines "area" inline, which unit 14 later deepens; that ordering is fine.

Misconception ("permissions live on a server") at beat 5: yes.

Length: about 55 s. In range.

Claims: "unforgeable token that bestows read or write access" is verbatim. The four fields match the spec's access mode, granted namespace, granted area, receiver. Beat 5 matches the home page ("No central authority needed") and the recursive verification rule.

Verdict: pass.

One idea. Yes.

Beats: yes.

Metaphor: card says "tearing a ticket smaller"; script says "shrink". Say "tear" once or change the card (S4, minor).

Assumptions: unit 10. Fine. Beat 1 ("a ticket for a whole room") matches a communal root capability whose granted area is "the subspace area of the userkey".

Misconception ("delegating needs the original issuer") at beat 5: yes.

Length: about 50 s. In range.

Claims: beat 2 to 4 match validity: "cap is valid if prevcap is valid, the granted area of prevcap includes newarea, and newsignature is a UserSignature issued by the prevreceiver". The chain travelling with the ticket matches the delegations field. One unsaid detail that does not harm the model: the access mode cannot change either.

Verdict: pass (one-word metaphor fix).

One idea. Yes.

Beats: yes.

Metaphor: card says "a ticket stapled to the card"; script says "travels with a token". "Stapled" is only on screen (S4, minor). Say it.

Assumptions: unit 10. Fine.

Misconception ("peers trust each other's writes") at beat 1: yes.

Length: about 46 s. In range.

Claims:

A12 (M) Beat 4 and the check question: "A peer checks two things. Does the ticket cover this entry? Did its holder sign it?" The spec's meadowcapisauthorisedwrite has four conditions: "mat.capability is valid, the access mode of mat.capability is write, the granted area of mat.capability includes entry, and userverify(receiver, mat.signature, encodeentry(entry)) is true." A viewer who answers the check question with two checks has a model in which a forged chain passes. Fix: "A peer checks the ticket is genuine, and two more things." Update the check question to three.

S6 Beat 4 screen (peer, card, ticket, signature, two check marks) is five or six things. Show the two checks as marks on the ticket.

Beat 5 matches "An AuthorisedEntry is a PossiblyAuthorisedEntry for which isauthorisedwrite returns true."

Verdict: back to 1b (beat 4 and the check question).

One idea. Yes.

Beats: yes.

Metaphor ("a ticket with dates on it"): the script says "time range"; acceptable.

Assumptions: units 8 and 12, plus unit 10's time range. Fine.

Misconception ("no revocation means no control") at beat 4: yes.

Length: about 51 s. In range.

Claims: beat 1 is supported by implication (timestamps page: "Repeatedly handing out capabilities that grant access for a small time span imitates the concept of revoking rights"; Meadowcap: "Owen probably will not give Alfie a new capability at the end of the week either, effectively removing Alfie from the space"). Beat 2 follows from areas including a time range. Beat 4 matches "by creating newer Entries, you make sure that someone with an expired capability cannot make their writes propagate anymore." Beat 5 matches the checks table. Small note for the post, not the script: "your newer entries win" needs your entry's path to be at or above theirs.

Verdict: pass. Optional deepening beat from Meadowcap: a moderator deletes irrevocably "by writing Entries ... whose timestamp lies two weeks in the future."

One idea. Yes.

Beats: yes.

Metaphor (block in a grid with a time dial): carried; "dial" is screen-only, fine.

Assumptions: unit 10. Fine.

Misconception ("permissions and sync work on namespaces") at beat 5: yes.

Length: about 45 s. At the floor; the idea could carry one more beat (an example area in words).

Claims:

A14 (M) Beat 3: "A shelf prefix. Blog alone, or blog, ideas, and everything below it." A prefix area always includes everything beneath the prefix: "To be included in this Area, an Entry's path must be prefixed by the path." "Blog alone" reads as "just the blog shelf", which no area can express. Fix: "A shelf prefix. Everything under blog. Or only everything under blog, ideas."

A15 (U) Beat 5: "Queries return areas." No page says this. The grouping page says a query "corresponds to a box", that is, you ask with an area. Fix: "Queries ask for areas."

Beat 1 matches "three orthogonal dimensions: subspaceid, path, and timestamp". Beat 2 matches "subspaceid: SubspaceId | any".

Verdict: back to 1b (beat 3, beat 5; consider a sixth beat).

One idea. Yes.

Beats: yes.

Metaphor (a small lit block in a huge building): "enormous", "one shelf of one room" carry it; "block" is screen-only. Acceptable.

Assumptions: unit 14. Fine.

Misconception at beat 1: yes.

Length: about 48 s. In range.

Claims: beat 2 and 3 match AreaOfInterest ("the Entries with the greatest timestamps"; maxcount, maxsize). Beat 4 matches Confidential Sync: "The non-empty intersections of AreasOfInterest from both peers contain the Entries to synchronise." Beat 5 matches "Partial sync: peers synchronise only those regions of data they both care about."

A19 (X, series-wide; recorded here, fixed in 17, 18 and 24) "They sync the overlap" is Confidential Sync's model; WTP is request and response ("peers can send and request Entries and Payloads to and from each other"). Both end at the same place, so this unit passes, but see unit 17.

Verdict: pass.

One idea. Yes.

Beats: yes.

Metaphor:

S4 Card: "Comparing seals on boxes." The script never says "seal" or "box"; it says "fingerprint". The visual language fixes "a fingerprint is a seal on a region", so the screen will show seals the narration never names. Say it once in beat 2: "One seal over the whole box. Same seal, same contents."

Assumptions: unit 15, and the word "fingerprint" from unit 4 (A17, fixed there).

Misconception ("sync lists every entry") at beat 5: yes.

Length: about 44 s. Short of both the card's 45 and the brief's floor. One more beat lands it: "The fingerprint also counts how much of each payload a peer holds, so a half-downloaded parcel shows up as a difference too" (RBSR: LengthyAuthorisedEntries, "modifying ... its number of available bytes, should result in a completely different PreFingerprint").

Claims:

A16 (O) Beat 5: "The work grows with the differences, not with the size of the area." RBSR page: "drill down to the differences between their two sets in a logarithmic number of communication rounds, spending only little bandwidth on those regions of the original sets where they hold the same items." Bytes follow the differences; rounds grow with the log of the size. Fix: "The bytes sent grow with the differences. The rounds grow only with the logarithm of the size."

Beat 2 to 4 match "one peer first computes a hash over all items in its set ... If the fingerprints match, they are done ... split its set in half ... if the set is sufficiently small, the peer can instead simply transmit its items."

Verdict: back to 1b (length, beat 5, speak the metaphor).

One idea. Yes.

Beats: yes.

Metaphor ("comparing scrambled versions of a secret"): spoken ("scrambles"). Good.

Assumptions: unit 15. S3: "salt" is used in beat 3 and 4 and never defined. Add half a line: "a random string mixed in before hashing".

Misconception ("peers send their read capabilities first") at beat 5: yes.

Length: about 55 s. In range.

Claims: the mechanism is supported verbatim (checks table). Beat 2's example matches the page's gemmastinks example. Beat 4 "No match reveals nothing" matches "cannot learn about the existence of any NamespaceId, SubspaceId, or Path which they did not know about already" (the page also notes attackers "can confirm their guesses", which "nothing new" correctly allows for). Beat 5 matches "the other peer then sends its read capabilities" and the sensitive-field-omitting encoding.

A19 (X) This is Confidential Sync's private interest overlap detection. Unit 24 says Confidential Sync is paused and its page says "A lot of the designs in this document are outdated". WTP, the live proposal, says the opposite of this unit: "Metadata, such as capabilities themselves, or requests for specific groupings of Entries are transmitted naively, however; peers must be mindful of possibly leaking information this way." The series intro also promises "sync protocols that reveal nothing to peers who do not share your interests" without qualification. The guide's Anytwo lesson applies: name the protocol. Fix beat 1: "In Confidential Sync, before syncing, two peers must find what they both care about." And in unit 24 beat 4 say that the private part lives in the paused spec. The intro paragraph should say "one of its sync protocols".

Verdict: back to 1b (name the protocol, define salt).

One idea? The idea sentence has three clauses: handshake binds a key, tickets must be for it, no middle box can listen. Clauses 1 and 2 are one idea; clause 3 is its consequence and is fine if stated as such. Beat 4 (who holds read tickets) is a separate idea and does not serve this one (S5). Strike beat 4 or replace it with a beat that deepens the binding (for example the ephemeral-key trick: "Peers can even create ephemeral keypairs per sync session and create valid capabilities by delegation which they discard after the session").

Beats: beat 4 does not serve.

Metaphor:

S4 Card: "A doorman who checks the ticket and the face." Never spoken. Say it in beat 2: "Like a doorman who checks the ticket and the face it was issued to."

Assumptions: unit 17 (and key pairs from the unit 9 fix). Fine.

Misconception ("encryption of the link is enough") at beat 2: yes.

Length: about 55 s. In range.

Claims:

A22 (W) Beat 5: "And a box in the middle learns nothing. The handshake rules it out, and the session is sealed." Both halves are contradicted by the PIO page. "If Alfie and Betty know longterm public keys, they can exclude an active attacker during the handshake"; for strangers it is the tickets that shut the attacker out: "if they do manipulate the handshake by replacing the exchanged public keys ... they will later have to produce read capabilities for those public keys ... they will not be able to do so." And it does not learn nothing: "An active eavesdropper can access everything at L2 without holding a corresponding read capability" (L2 is the timestamps, public keys and signatures inside transmitted capabilities). Fix: "A box in the middle can swap keys in the handshake. But then it needs a ticket for its own key, and it has none. It gets no entries and no names."

A21 (O) Beat 4: "A room's owner holds one for the room. A follower gets one delegated." True in a communal namespace only ("Every CommunalCapability with zero delegations is valid"; granted area "the subspace area of the userkey"). In an owned namespace the room's writer holds nothing until the namespace key signs an initialauthorisation. If the beat survives, say "in a communal building".

A23 (O, minor) Beat 1: "the link is encrypted." WTP: "peers should encrypt if and only if the underlying communication channel is unencrypted." Fine for the video; note it in the post.

Beat 2 is supported by WTP ("A valid ReadCapability whose receiver is the Receiver authenticated in the opening handshake") and PIO ("Peers must reject any read capabilities presented to them whose receiver is not the inipk or respk"). Beat 3 is supported (checks table).

Verdict: back to 1b (beat 5 rewrite, beat 4 strike or scope, speak the metaphor).

One idea. Yes.

Beats: yes.

Metaphor (parcel checked piece by piece): spoken. Good.

Assumptions: unit 4. Beat 5 says "pass it on", which assumes relaying (unit 20) but is understandable alone. Fine.

Misconception at beat 2: yes.

Length: about 54 s. In range.

Claims:

A24 (O, minor) Beat 3: "Willow uses a tree hash." The data model needs only "a secure hash function". It is Confidential Sync ("expects PayloadDigest to be the digest of a Merkle-tree-based hash function"), WTP and the drop format ("The hashpayload parameter of the data model must be a member of the Bab family") that require it, and Willow'25 that picks WILLIAM3. Fix: "Willow's sync protocols require a tree hash." Name Bab here once, since unit 22 says "from the Bab tree hash" as if the viewer had heard of it.

A25 (U) Beat 4: "Garbage is caught at the first chunk." No listed page says this sentence; it is what a Bab verifiable stream does, and the Confidential Sync page supports the principle ("verify that the data is indeed a prefix of the expected Payload"). The Bab spec is outside the recorded sources. Either record a Bab sentence in the sources or soften to "Each chunk is checked as it arrives."

Beat 5 is supported: "If transmission of a Payload is cut short ... peers should be able to work with the data they had received so far", and drops carry "verifiable subslices of their payloads".

Verdict: back to 1b (two wording fixes; small).

One idea: what must stay visible for joins to work. Yes, though it carries three facts (payload, paths, timestamps); they are one rule applied three times.

Beats: yes.

Metaphor (envelope with a scrambled label whose slots are kept): the slots idea is spoken ("three scrambled parts ... still share it after scrambling"); "envelope" and "label" are not. Minor (S4).

Assumptions: units 6 and 14. Fine.

Misconception ("encrypting data breaks sync") at beat 4: yes.

Length: about 51 s. In range.

Claims:

A52 (M, minor) Beat 2: "The payload is encrypted." By whom? "Willow has no built-in mechanisms for encrypting data." Say "You encrypt the payload."

Beat 3 and 4 match the e2e page ("encrypting individual Components with encryption keys that we successively derive"; "prefix-preserving cyphertexts"; "Protocols like Meadowcap or Confidential Sync just work with the encrypted Paths"). Beat 5 matches "Computing joins of stores necessitates comparing Timestamps numerically ... we begrudingly accept that Willow deals in plaintext Timestamps only." The recorded source's "must remain unencrypted" is a paraphrase, not a quote.

S7 Beat 5 screen: "timestamp and ids left plain on the card." The narration never says "ids". Either say "and the ids" (the page supports it: "there is little reason to encrypt them at all") or take them off the screen.

Note for the post: the relay also sees the capability tokens in the clear ("Meadowcap McCapabilities cannot be encrypted"), so "never learn what any of it says" is about contents and names, not about who may write.

Verdict: back to 1b (one-line fixes in beat 2 and the beat 5 screen).

One idea. Yes.

Beats: yes.

Metaphor (USB stick): spoken in beat 5. Good.

Assumptions: unit 12. Fine.

Misconception ("Willow needs a live network") at beat 1: yes.

Length: about 48 s. In range.

Claims: beat 2 matches "a sequence of pairs of a PossiblyAuthorisedEntries and a sequence of non-overlapping slices of payload chunks". Beat 3 matches the changelog ("allowing for entries with no available payload"). Beat 4 matches "A drop can then be treated as a kind of static set of stores which can be joined with any other stores"; the receiver checking tokens follows from drops carrying PossiblyAuthorisedEntries. Beat 5 matches "We highly recommend encrypting drops for transport."

A27 (O, minor) Beat 5: "Encrypt a drop before you hand it over. Then any channel will do." Any channel does regardless; encryption is for confidentiality. Swap the order: "Any channel will do. Encrypt the drop first."

Verdict: pass (optional reorder).

One idea (a parts list that makes implementations interoperate). Yes.

Beats: yes.

Metaphor (parts list): "slots" is spoken, "parts list" is not. Minor (S4).

Assumptions: units 9 and 18. Beat 2 says "from the Bab tree hash" and nothing has named Bab (fix in unit 19).

Misconception ("Willow'25 is a new version of the protocol") said to be addressed at beat 2: beat 2 implies it ("fills the slots") but never denies it. Add "Not a new protocol. The same protocol with its blanks filled in."

Length: about 57 s. In range.

Claims:

A28 (O, minor) Beat 1: "The data model does not say which hash or which signature to use." The data model has no signature parameter; signatures are Meadowcap's. Fix: "The data model does not say which hash to use. Meadowcap does not say which signatures. Those are parameters."

Beat 2 to 5 are supported verbatim (Ed25519, "We use WILLIAM3 as the go-to hash function, which is defined as part of the Bab specification", the three 4096s, AEADCHACHA20POLY1305, "essentially the XX handshake of the noise protocol framework", "We intend to not release another set of recommended parameters until one of the cryptographic primitives of Willow'25 is broken").

S6 Screens accumulate: by beat 4 the slots show Ed25519, WILLIAM3, 4096, 4096, 4096, ChaCha20-Poly1305, Nose XX: seven things. Show one slot group per beat and dim the rest.

S7 Beat 4 screen says "Nose XX" while the narration says "Noise style XX". Either say "the authors call it Nose" or write "Noise XX" on screen.

Verdict: back to 1b (beat 1 wording, misconception line, screen counts).

One idea. Yes.

Beats: yes.

Metaphor:

S4 Card: "A street address versus directions." Never spoken. Beat 5 is the place: "The name is the address. The hint is directions."

Assumptions: unit 14. "URI" is undefined but the audience is developers.

Misconception ("the URI says where the data is") at beat 5: yes.

Length: about 48 s. In range.

Claims:

A32 (O) Beat 5: "The name is not the location. The hint is." Source: hints "serve as hints for how and/or where to obtain the identified data. Hints appearing early in the sequence should be tried before hints appearing later." A hint is a place to try, and may be stale or wrong. Fix: "The hint is only where to look first."

Beat 1 to 4 match the page ("willow://namespace.subspace/path/components"; "?digest=" identifies "an Entry with a specific Payload"; "?area" with count, size, from, to; "willow://family.alfie/blog?area&count=12").

A33 (M, minor) The screen shows "family.alfie". Under Willow'25 a namespace id is a hex-encoded key with a leading "+" for communal or "-" for owned ("the byte 43 (ASCII +) if iscommunal maps the NamespaceId to true, or the byte 45 (ASCII -) otherwise"). After unit 9 taught that ids are keys, a viewer may think names are words. One line: "Family and alfie stand in for keys."

Verdict: back to 1b (beat 5 wording, speak the metaphor, one line on placeholders).

One idea? No. Beat 1 (who made Willow, Earthstar) is a second idea (S5). Cut it, or move it to unit 1. If it stays anywhere, the About page credits a third person for the core model ("The path / author / timestamp model at the heart of Willow was designed by our dear departed friend Cinnamon"); naming two designers and not the third is an omission (A34, M).

Beats: beat 1 does not serve.

Metaphor (status board): not spoken; fine for a framing unit.

Assumptions: unit 1. Fine.

Misconception ("the whole protocol is finished") at beat 4: yes.

Length: about 52 s. In range.

Claims:

A36 (U) Beat 3: "The drop format is a candidate." The drop format page says "Status: Proposal". Only the changelog says "Drop format has been promoted to Candidate". The curriculum's own recorded sources record both. A video that states a status should state the one on the spec page, or say "the changelog promoted it to candidate, though its page still says proposal" in the post and leave it out of the script.

A38 (U) Beat 4: "was proposed in October twenty twenty six." The WTP page says "Status: Proposal (as of 16.10.2026)"; nothing says when it was proposed, and the changelog never mentions WTP. Fix: "Its spec, dated October twenty twenty six, is a proposal."

A35 (U, minor) Beat 2: "Meadowcap was promoted in October twenty twenty five." Changelog: 26/10/2025. Meadowcap page: "Final (as of 21.11.2025)". Drop the month: "Meadowcap became final in twenty twenty five."

Beat 2's "final" and beat 3's "Willow twenty five ... is a proposal" and beat 4's "paused" are supported (checks table). "A simpler Willow transfer protocol, request and response" matches the specs index: "A network protocol for simple, request-response-based data synchronisation."

A19 (X) Beat 4 should say that the private overlap detection of unit 17 belongs to the paused spec, and that WTP sends requests and capabilities in the clear, so the viewer's model of "which parts are settled" includes privacy.

S6 Screens accumulate six names with stamps by beat 4. Stamp one row per beat and fade the earlier rows, or show the four blocks from unit 1 throughout.

Verdict: back to 1b (cut beat 1, drop-format status, WTP date, Meadowcap month, protocol note, screen).