Server, read token, signing key
Current plan
What this screen sends
One request. The body is signed exactly as it is transmitted — the MAC covers the byte string, not a re-serialisation of a parsed object, because that difference is how signed webhooks get forged.
POST {server}/write
Content-Type: application/json
X-Unsay-Timestamp: 2026-10-08T09:14:22.418Z
X-Unsay-Signature: <hex HMAC-SHA256( timestamp + "." + body , write secret )>
{"patient":"ray","domain":"weight_bearing","audience":"user","value":"…",
"authorId":"okafor","authorLabel":"Sarah Okafor, physio","priority":0.9}
Any origin can point this page at a server. The Unsay server answers the preflight and allows the signature headers, and that grants nothing: every write carries its own HMAC and every read its own Bearer token, and there is no cookie for another origin to borrow.
writtenAt is not in the body on purpose: the server stamps
it from its own clock. A writer that could set it could backdate a correction, and “how old is
this instruction” is something the assistant says out loud.
See the mechanism on the landing page, or watch the correction land on the Echo Show screen.
Unsay relays what a clinician wrote. It does not generate clinical guidance and is not a
medical device. Ray Dunn, Sarah Okafor and this care plan are a scenario; the seed record
is committed at src/seed.ts.