Three Buyers, One Promise

What this means for you

FNP sells the same product to three distinct buyers. The promise is one sentence: a shared document the host cannot read. The reason each buyer signs is different, and the call needs to land on the right one.

Who it’s for

The regulated industry lead. Legal, healthcare, finance. The contract their counsel will not sign says the vendor cannot read client work. They want a collaborative editor that already complies, not a feature flag that promises to.

The privacy-first product team. Builders shipping client-side encryption who hit the wall the moment two users need to edit the same object at the same time. They have keys. They need merge.

The internal platform owner. Runs an audit-grade environment where every change must be provable later. They want the proof to live with the operation, not in a log file that can be tampered with.

Proof points

• Three distinct buyers, one shared backend: same fnp-server binary, same persistence schema, same proof contract
• Built on the post-quantum primitives the regulated buyer already has on their procurement checklist
• Audit log lives in the database with the operation, not in a sidecar that can drift

journey
  title From cold interest to signed contract
  section Regulated lead
    Hears "host cannot read" : 5: Lead
    Sends to counsel : 4: Lead
    Counsel approves : 5: Counsel
  section Privacy product team
    Reads the spec : 5: Engineer
    Runs the local stack : 5: Engineer
    Replaces homegrown merge : 4: Engineer
  section Platform owner
    Asks for audit story : 4: Owner
    Sees proofs at rest : 5: Owner
    Signs : 5: Owner