Three Locks, One Document

What this means for you

There is a clean three-part story for how FNP works. It fits on a slide. It survives translation by a non-engineer. Use it whenever someone asks the obvious follow-up: if the server cannot read the document, how does it merge?

The pitch

A document gets three locks. A content lock so only the people on the document can read the words. An ordering lock so the server can put characters in the right place by comparing locked tags, never their values. A proof lock so every edit comes with a sealed receipt the server can check without opening it.

Who it’s for

The product marketer or solutions engineer who has 90 seconds in front of a buyer and needs the buyer to say, “I get it. Send me the deeper version.”

Proof points

• The same three-lock model is the opening explanation in the platform’s own architecture card, written before any marketing pass
• Each lock corresponds to a real, separately published primitive in the platform documentation, not a metaphor invented for the deck
• Edits arrive at the server with their own sealed receipt; the server checks the receipt and merges, then forwards. No plaintext touches the wire or the disk

mindmap
  root((Three Locks))
    Content lock
      only the readers
      hold the keys
    Ordering lock
      server compares
      never reads
    Proof lock
      every edit
      arrives with receipt