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}
Serve this page from the server’s own origin. The Unsay server
sends no CORS headers and answers a preflight with 405, so a browser blocks every
request above before it leaves when this page is opened from file:// or a different
port. From the same origin it needs nothing.
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.