NDA

Why NDAs are structural here

Most SaaS products treat an NDA as a checkbox: you click "I agree" once at sign-up, and it's done. For board material — which frequently includes financials, fundraising plans, personnel changes, legal strategy — that's not enough. You want:

• A specific document, not boilerplate hidden behind a Terms of Service link.
• A signed record — member name, date, IP, device — for every person with access.
• A way to rotate the NDA when it changes (a new board member with different terms, a lawyer revising the template, a jurisdictional update) and force re-acceptance.
• Enforcement that's structural, not suggestive — a member who hasn't signed the current version sees the NDA acceptance screen and nothing else.

Versions

An NDA lives as a versioned document. Version 1 is created during org setup. When you need a new NDA, you publish a new version — v2, v3, etc. Only one version is active at a time; prior versions stay in the archive (you can't delete them — they're legal record).

Each version has:

• A body — rich text, the actual agreement. Paste from your law firm's template or draft in the editor.
• An effective date — when it becomes the active version.
• A changelog note — visible to members when they re-sign. "What's different since v3?" — writing this helps members feel respected rather than surprised.
• A signature list — every member who accepted this specific version, with the metadata below.

Acceptance flow

When a member needs to sign (first time, or re-acceptance after rotation):

1. They land on /nda — a full-page doc reader. Nothing else in the app is reachable until they finish.
2. The document renders through <BoardProse> — so their accessibility preferences (font, size, line-height, background) apply; they can Listen to it via TTS.
3. A scroll-progress bar tracks how much they've actually read. The Sign button unlocks only after they hit the end. This is a gentle speed-bump, not a formal proof of reading.
4. At the bottom, a text input asks for their full legal name (not their display name — if they invite as "Sid", we still want "Sidney Hornych" on the signature). They type it and click Sign.
5. BoardHerald records:
   • Full legal name
   • Timestamp (UTC)
   • IP address
   • User agent (browser / device)
   • The exact NDA version they signed under (immutable)
   All of this is written to the audit log as an nda.accepted event.

Rotation

To replace the active NDA with a new version, an ADMIN opens Settings → NDA → New version, drafts the new body, sets the effective date, and writes a changelog note. On the effective date (usually "now") the new version becomes active.

Every existing member is bounced to the NDA re-acceptance screen on their next sign-in. Until they re-sign, they can't read anything. Members who already have an active session stay signed in, but any page they try to navigate to routes them through NDA first.

This is the point of a rotatable NDA — if your terms change (e.g. a new jurisdiction, a clearer confidentiality clause), the board gets the refreshed language without you having to chase each member for a new signature via email.

Who's signed what

Settings → NDA shows a table: every member × every version × signed / unsigned. Unsigned fields for the current active version are highlighted — these are members who can't read anything right now. Click any signed cell to see the full signature metadata.

Agent interaction

API keys are issued against a human user — and that human must have signed the current NDA. An agent holding a key whose human hasn't accepted the active version gets a 403 nda_required response on every tool call. The agent can't "accept" an NDA on anyone's behalf — that's a human action, always.

If you rotate the NDA, every agent loses access until its human re-signs. This is by design: a new NDA that's materially different terms shouldn't carry stale agent consent.