Customer docs

What you get

• A tenant-scoped credential — a bearer token, issued at signup, shown once. It is not an admin key; it can only touch tenant.<your-id>.*.
• Bring-your-own governance — author your firm's policy + execution-context. It is stored in an isolated per-tenant store (no other tenant can read it) and sealed into your own tamper-evident chain.
• The governed loop — Engage → Draft → Review & Sign → Verify. PII stays client-side; only a content-addressed claim-ref leaves your browser. Verify re-verifies a real sealed chain.

Governed Email — the private beta, in plain words

1. Sign up on the signup page: your firm name, your email, and the name before @onrecord.email you want to send from. A quick check proves you are a person. Signup is on the page only.
2. Verify your mailbox and sign in: open /portal. You get a one-time PIN at the email you signed up with; entering it signs you in and verifies your mailbox. Sign in the same way any time later.
3. Sending is off until we turn it on. During the private beta, the operator turns sending on by invitation, for verified mailboxes only, and signs your sending permission. Your portal shows whether sending is on, your daily cap and your listed recipients.
4. Beta limits: 3 sends a day, to listed recipients only (a mail to anyone else is held for the operator), no attachments, and nothing stored — the message body is not kept.
5. What a recipient sees: an ordinary email from your address, with an AI line saying an AI assistant prepared it under your governance, a verify line naming the act, and a link to the browser verify page.
6. Check a receipt with no key: every send carries an act hash. Anyone can open https://verify.braas.dev/act/<act hash>/verify and see whether it verifies — no key, no account.

1 · Sign up

Sign up on the signup page (it carries the person check; there is no script path). You get a token, shown once:

# → { tenant_id, token, governance_root, engagement_url }   (token shown ONCE)

Store the token securely. We persist only sha256(token) and cannot recover it. Lost it? Re-sign-up.

2 · Author your governance (propose → apply)

curl -XPOST $GATEWAY/tenant/policy/propose -H "Authorization: Bearer $TOKEN" \
  -d '{"key_suffix":"governance.review_threshold","value":{"min_reviewers":2}}'
# returns { proposal: { namespace, key, proposal_hash, gate, change_kind, prev_value } } — writes NOTHING

curl -XPOST $GATEWAY/tenant/policy/apply -H "Authorization: Bearer $TOKEN" \
  -d '{"proposal": , "agree": {"proposal_hash":"","decision":"agree"}}'
# → { applied:true, method, seal:{ seq, hash } }   (written to YOUR store + sealed in YOUR chain)

The agree must be bound to the exact proposal_hash — an unbound or mismatched agree is refused (deny-by-default).

3 · Read & verify (isolation is server-side)

curl $GATEWAY/tenant/policy/list -H "Authorization: Bearer $TOKEN"     # only YOUR rules
curl "$GATEWAY/tenant/policy/list?namespace=tenant.OTHER.governance" -H "Authorization: Bearer $TOKEN"
# → 403 cross_tenant_denied   (you can never read another tenant's governance)
curl $GATEWAY/tenant/chain/verify -H "Authorization: Bearer $TOKEN"   # { verified:true, total_entries }

4 · Run the engagement

Open your engagement_url and run Engage → Draft → Review & Sign → Verify. The drafting engine is under-the-hood (claude-for-legal / claude-for-financial); the figure-of-record is the deterministic floor.

Honest limits (production residuals)

• Identity: the portal signs you in with Cloudflare Access (a one-time PIN to your email); the API keeps your tenant token. A PKI signer (Ed25519, S217 mechanism) is the named hardening.
• Simulation: engagements are INTERNAL-DEMO until a real licensed signer + e-sign + live-adapter draft are wired (operator-gated).
• Isolation: enforced server-side by tenant_id on the only door (this gateway); the store has no public read route.