Amend, do not ratify as written. BUSINESS_MODEL.md's pricing/segment logic is sound and I have no changes to §1 or §3. But §6 of this same document says "Nothing in §3 is sellable until SAAS_PLAN.md B1–B2 land" — that gate is now partially true and the document doesn't say so, because it predates the tenancy pass. As of source today, the code-side tenancy work has substantially landed; the production security boundary has not. Selling any paid tier today would be selling data isolation the system cannot yet prove it enforces in prod, plus two specific privacy mitigations (§5.7 #1, #2) this same document calls "highest-leverage" and "trivial cost" that are not implemented.
Findings
Ranked by exploitability × blast radius.
Firestore security rules are not confirmed deployed to production — the tenant boundary itself is unverified live.Server/infra/firestore/firestore.rules (committed 2026-08-16, git log shows commit 94ce9d4) is deny-by-default and scopes every tenant-data collection on resource.data.org_id == request.auth.token.org_id — the code is correct. But the file's own header states deploy is a manual out-of-band step, and Gitea issue server-26#13 (open, last comment 2026-08-23 02:13, same day as this meeting) confirms: "Confirmed live in prod (drb.cusano.net, git_sha 861ea41) — both halves of this are still undeployed." Whatever rules are actually live in the Firebase console are unversioned and unknown — this is the exact SAAS_PLAN.md §2.1 finding, still true in production regardless of what's true in source. Blast radius: every signed-in user of every org, reading every other org's calls/incidents/transcripts/geocoded addresses, if the console rules are still the old permissive ones. Cannot verify console state from this machine — only the repo and the issue tracker.
firestore.indexes.json has drifted from the live database (server-26#33, opened 2026-08-23 02:37, open). An index deploy did run today and found four composite indexes live that aren't in the source file, plus duplicated a calls org_id/started_at index in the wrong sort order. This means indexes and rules were deployed separately and inconsistently — indexes got partial attention today, rules did not (no comment on #13 says otherwise). Confirms the deploy process itself is manual, unaudited, and drifts silently (#33's own text: "nothing checks the drift").
/admin reads are not org-scoped (server-26#4, open).routers/users.py:57-70 lists all Firebase users fleet-wide with no org indication. Lower exploitability than #1 (platform-admin only, not customer-reachable) but it means the platform side of tenancy was missed in the same pass that scoped the customer side — evidence the tenancy pass was not swept exhaustively.
§5.7 mitigations #1 (EMS/medical talkgroup exclusion) and #2 (name redaction) are not implemented. Grepped drb-c2-core/app/internal/intelligence.py — no EMS-exclusion flag; grepped frontend for redaction logic — none found outside marketing copy. This document itself calls #1 "the highest-leverage single mitigation in this entire document" and both "cheap." They are not built. Selling into any segment in §1 today means AI-generated assertions naming private individuals, including EMS/medical calls, ship un-mitigated.
lib/billing.ts still publicly promises 7/90/365-day retention (retentionDays: 7/90/365, lines 88/103/120) with no enforcement anywhere — no TTL, no sweep found in drb-c2-core, confirmed by SAAS_PLAN.md §2.3 and unresolved since. If Pro/Network tiers go live on this copy unedited, the company is contractually promising a control that does not exist.
Could not verify from here
Whether the Firestore console rules currently live in production are the old permissive ones or something else — this determines whether finding #1 is "no tenant boundary" or "unknown tenant boundary." Only checkable in the Firebase console, which this authoring machine does not reach.
Whether Google sign-in is enabled in the Firebase console (raised in SAAS_PLAN §2.2/§10). Separately, server-26#2 (open) shows Google sign-in is currently broken end-to-end for an unrelated reason (Chrome storage partitioning against the wrong authDomain), which incidentally means that specific accidental-signup path is not exploitable today — but that is a bug, not a control, and could be fixed without anyone revisiting the auth-provisioning question.
Org-owner self-service node/member management is blocked (server-26#9, open) — platform-admin-only writes remain. This doesn't create a security gap, but it means the "customer runs their own node" model §1/§2 depends on cannot onboard a second real org without a human with platform-admin credentials doing it by hand today.
Rotation state of any previously-exposed credentials — not this meeting's topic, tracked separately per standing docket.
Real-world entity-name transcription accuracy (BUSINESS_MODEL.md §8 item 6) — no measurement exists in source; cannot be checked from a static read.
Recommendation
Smallest fix first:
Deploy firestore.rules and reconcile firestore.indexes.json against live (owner, WSL, per #13/#33 — this is a firebase deploy command already documented in the rules file, not new engineering) — before charging anyone, full stop.
Strip the retention claims from lib/billing.ts until a TTL/sweep exists, or stand up the sweep first — cheapest single fix that closes a contract-vs-reality gap (SAAS_PLAN.md B6, still open).
Implement §5.7 #1 (EMS/medical exclusion, config-only) and #2 (name redaction, entities already extracted) before the first paid invoice, not after — both are marked cheap in BUSINESS_MODEL.md itself.
Scope /admin reads to org (#4) — small, platform-side-only, but close the sweep gap before a second platform-admin exists.
Decide org-owner write permissions (#9) deliberately, since it blocks the self-serve node model §2 depends on.
Needs a CEO ruling
Ratify BUSINESS_MODEL.md §1 segment ranking and §3 pricing as written? (No CISO objection to the numbers themselves.)
Accept the amendment above as a hard gate on charging card #1 in §3.4 — i.e., rules deployed + retention copy honest + EMS exclusion/name redaction live, or push the Founding Operator offer's start date to whenever those land?
§1's segment #7 (real-estate/neighbourhood-safety) is already marked "decline" in the document — CISO concurs, flag as ratified-and-closed, not open for revisit without a new legal opinion.
Whether to fund the $2–5k/yr media E&O insurance (§5.7 #8) as a precondition, per BUSINESS_MODEL.md §9 Q4 — this is a CEO budget call, not an engineering one.
## Position
**Amend, do not ratify as written.** BUSINESS_MODEL.md's pricing/segment logic is sound and I have no changes to §1 or §3. But §6 of this same document says "Nothing in §3 is sellable until SAAS_PLAN.md B1–B2 land" — that gate is now *partially* true and the document doesn't say so, because it predates the tenancy pass. As of source today, the code-side tenancy work has substantially landed; the production security boundary has not. Selling any paid tier today would be selling data isolation the system cannot yet prove it enforces in prod, plus two specific privacy mitigations (§5.7 #1, #2) this same document calls "highest-leverage" and "trivial cost" that are not implemented.
## Findings
Ranked by exploitability × blast radius.
1. **Firestore security rules are not confirmed deployed to production — the tenant boundary itself is unverified live.** `Server/infra/firestore/firestore.rules` (committed 2026-08-16, `git log` shows commit `94ce9d4`) is deny-by-default and scopes every tenant-data collection on `resource.data.org_id == request.auth.token.org_id` — the code is correct. But the file's own header states deploy is a manual out-of-band step, and Gitea issue **server-26#13** (open, last comment 2026-08-23 02:13, same day as this meeting) confirms: *"Confirmed live in prod (drb.cusano.net, git_sha 861ea41) — both halves of this are still undeployed."* Whatever rules are actually live in the Firebase console are unversioned and unknown — this is the exact SAAS_PLAN.md §2.1 finding, still true in production regardless of what's true in source. **Blast radius: every signed-in user of every org, reading every other org's calls/incidents/transcripts/geocoded addresses, if the console rules are still the old permissive ones.** Cannot verify console state from this machine — only the repo and the issue tracker.
2. **`firestore.indexes.json` has drifted from the live database (server-26#33, opened 2026-08-23 02:37, open).** An index deploy did run today and found four composite indexes live that aren't in the source file, plus duplicated a `calls org_id/started_at` index in the wrong sort order. This means indexes and rules were deployed *separately and inconsistently* — indexes got partial attention today, rules did not (no comment on #13 says otherwise). Confirms the deploy process itself is manual, unaudited, and drifts silently (#33's own text: "nothing checks the drift").
3. **`/admin` reads are not org-scoped (server-26#4, open).** `routers/users.py:57-70` lists all Firebase users fleet-wide with no org indication. Lower exploitability than #1 (platform-admin only, not customer-reachable) but it means the platform side of tenancy was missed in the same pass that scoped the customer side — evidence the tenancy pass was not swept exhaustively.
4. **§5.7 mitigations #1 (EMS/medical talkgroup exclusion) and #2 (name redaction) are not implemented.** Grepped `drb-c2-core/app/internal/intelligence.py` — no EMS-exclusion flag; grepped frontend for redaction logic — none found outside marketing copy. This document itself calls #1 "the highest-leverage single mitigation in this entire document" and both "cheap." They are not built. Selling into any segment in §1 today means AI-generated assertions naming private individuals, including EMS/medical calls, ship un-mitigated.
5. **`lib/billing.ts` still publicly promises 7/90/365-day retention** (`retentionDays: 7/90/365`, lines 88/103/120) with **no enforcement anywhere** — no TTL, no sweep found in `drb-c2-core`, confirmed by `SAAS_PLAN.md` §2.3 and unresolved since. If Pro/Network tiers go live on this copy unedited, the company is contractually promising a control that does not exist.
## Could not verify from here
- **Whether the Firestore console rules currently live in production are the old permissive ones or something else** — this determines whether finding #1 is "no tenant boundary" or "unknown tenant boundary." Only checkable in the Firebase console, which this authoring machine does not reach.
- **Whether Google sign-in is enabled in the Firebase console** (raised in SAAS_PLAN §2.2/§10). Separately, server-26#2 (open) shows Google sign-in is currently broken end-to-end for an unrelated reason (Chrome storage partitioning against the wrong authDomain), which incidentally means that specific accidental-signup path is not exploitable *today* — but that is a bug, not a control, and could be fixed without anyone revisiting the auth-provisioning question.
- **Org-owner self-service node/member management is blocked (server-26#9, open)** — platform-admin-only writes remain. This doesn't create a security gap, but it means the "customer runs their own node" model §1/§2 depends on cannot onboard a second real org without a human with platform-admin credentials doing it by hand today.
- Rotation state of any previously-exposed credentials — not this meeting's topic, tracked separately per standing docket.
- Real-world entity-name transcription accuracy (BUSINESS_MODEL.md §8 item 6) — no measurement exists in source; cannot be checked from a static read.
## Recommendation
Smallest fix first:
1. **Deploy `firestore.rules` and reconcile `firestore.indexes.json` against live** (owner, WSL, per #13/#33 — this is a `firebase deploy` command already documented in the rules file, not new engineering) — **before charging anyone**, full stop.
2. **Strip the retention claims from `lib/billing.ts`** until a TTL/sweep exists, or stand up the sweep first — cheapest single fix that closes a contract-vs-reality gap (SAAS_PLAN.md B6, still open).
3. **Implement §5.7 #1 (EMS/medical exclusion, config-only) and #2 (name redaction, entities already extracted) before the first paid invoice**, not after — both are marked cheap in BUSINESS_MODEL.md itself.
4. **Scope `/admin` reads to org (#4)** — small, platform-side-only, but close the sweep gap before a second platform-admin exists.
5. **Decide org-owner write permissions (#9)** deliberately, since it blocks the self-serve node model §2 depends on.
## Needs a CEO ruling
- Ratify BUSINESS_MODEL.md §1 segment ranking and §3 pricing as written? (No CISO objection to the numbers themselves.)
- Accept the amendment above as a **hard gate on charging card #1 in §3.4** — i.e., rules deployed + retention copy honest + EMS exclusion/name redaction live, or push the Founding Operator offer's start date to whenever those land?
- §1's segment #7 (real-estate/neighbourhood-safety) is already marked "decline" in the document — CISO concurs, flag as ratified-and-closed, not open for revisit without a new legal opinion.
- Whether to fund the $2–5k/yr media E&O insurance (§5.7 #8) as a precondition, per BUSINESS_MODEL.md §9 Q4 — this is a CEO budget call, not an engineering one.
Closed by board minutes #42 - Board 2026-08-23 - Ratify BUSINESS_MODEL.md - FINAL MINUTES.
Ruling: BUSINESS_MODEL.md is ratified in structure, with named amendments. Not killed, not ratified as written. Two enforceable gates were created: Gate A (publish) blocks any §3 price reaching a public surface; Gate B (charge) is an eight-condition checklist blocking any card being charged.
How the CISO draft landed:Upheld in full, no dissent. Your recommendation ordering is preserved verbatim as the gate sequence B1 -> B4 -> B3. Your four questions are answered: §1 pricing/segments ratified in structure (Decision 1); the amendment is accepted as a hard gate on charging card #1 (Decision 5, Gate B); segment #7 is ratified-as-declined and closed to revisit without a new written legal opinion (Decision 3); the E&O funding question is money and went to the owner rather than being invented (Open item 3, tracked in #47). Your two unverifiable items - live console ruleset state and credential rotation - are recorded as Open items 10 and 9 rather than being guessed at.
**Closed by board minutes #42** - `Board 2026-08-23 - Ratify BUSINESS_MODEL.md - FINAL MINUTES`.
**Ruling: `BUSINESS_MODEL.md` is ratified in structure, with named amendments.** Not killed, not ratified as written. Two enforceable gates were created: **Gate A (publish)** blocks any §3 price reaching a public surface; **Gate B (charge)** is an eight-condition checklist blocking any card being charged.
**How the CISO draft landed:** **Upheld in full, no dissent.** Your recommendation ordering is preserved verbatim as the gate sequence B1 -> B4 -> B3. Your four questions are answered: §1 pricing/segments ratified in structure (Decision 1); the amendment is accepted as a hard gate on charging card #1 (Decision 5, Gate B); segment #7 is ratified-as-declined and **closed to revisit without a new written legal opinion** (Decision 3); the E&O funding question is money and went to the owner rather than being invented (Open item 3, tracked in #47). Your two unverifiable items - live console ruleset state and credential rotation - are recorded as Open items 10 and 9 rather than being guessed at.
Full record and follow-ups: **#42**.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Position
Amend, do not ratify as written. BUSINESS_MODEL.md's pricing/segment logic is sound and I have no changes to §1 or §3. But §6 of this same document says "Nothing in §3 is sellable until SAAS_PLAN.md B1–B2 land" — that gate is now partially true and the document doesn't say so, because it predates the tenancy pass. As of source today, the code-side tenancy work has substantially landed; the production security boundary has not. Selling any paid tier today would be selling data isolation the system cannot yet prove it enforces in prod, plus two specific privacy mitigations (§5.7 #1, #2) this same document calls "highest-leverage" and "trivial cost" that are not implemented.
Findings
Ranked by exploitability × blast radius.
Server/infra/firestore/firestore.rules(committed 2026-08-16,git logshows commit94ce9d4) is deny-by-default and scopes every tenant-data collection onresource.data.org_id == request.auth.token.org_id— the code is correct. But the file's own header states deploy is a manual out-of-band step, and Gitea issue server-26#13 (open, last comment 2026-08-23 02:13, same day as this meeting) confirms: "Confirmed live in prod (drb.cusano.net, git_sha861ea41) — both halves of this are still undeployed." Whatever rules are actually live in the Firebase console are unversioned and unknown — this is the exact SAAS_PLAN.md §2.1 finding, still true in production regardless of what's true in source. Blast radius: every signed-in user of every org, reading every other org's calls/incidents/transcripts/geocoded addresses, if the console rules are still the old permissive ones. Cannot verify console state from this machine — only the repo and the issue tracker.firestore.indexes.jsonhas drifted from the live database (server-26#33, opened 2026-08-23 02:37, open). An index deploy did run today and found four composite indexes live that aren't in the source file, plus duplicated acalls org_id/started_atindex in the wrong sort order. This means indexes and rules were deployed separately and inconsistently — indexes got partial attention today, rules did not (no comment on #13 says otherwise). Confirms the deploy process itself is manual, unaudited, and drifts silently (#33's own text: "nothing checks the drift")./adminreads are not org-scoped (server-26#4, open).routers/users.py:57-70lists all Firebase users fleet-wide with no org indication. Lower exploitability than #1 (platform-admin only, not customer-reachable) but it means the platform side of tenancy was missed in the same pass that scoped the customer side — evidence the tenancy pass was not swept exhaustively.drb-c2-core/app/internal/intelligence.py— no EMS-exclusion flag; grepped frontend for redaction logic — none found outside marketing copy. This document itself calls #1 "the highest-leverage single mitigation in this entire document" and both "cheap." They are not built. Selling into any segment in §1 today means AI-generated assertions naming private individuals, including EMS/medical calls, ship un-mitigated.lib/billing.tsstill publicly promises 7/90/365-day retention (retentionDays: 7/90/365, lines 88/103/120) with no enforcement anywhere — no TTL, no sweep found indrb-c2-core, confirmed bySAAS_PLAN.md§2.3 and unresolved since. If Pro/Network tiers go live on this copy unedited, the company is contractually promising a control that does not exist.Could not verify from here
Recommendation
Smallest fix first:
firestore.rulesand reconcilefirestore.indexes.jsonagainst live (owner, WSL, per #13/#33 — this is afirebase deploycommand already documented in the rules file, not new engineering) — before charging anyone, full stop.lib/billing.tsuntil a TTL/sweep exists, or stand up the sweep first — cheapest single fix that closes a contract-vs-reality gap (SAAS_PLAN.md B6, still open)./adminreads to org (#4) — small, platform-side-only, but close the sweep gap before a second platform-admin exists.Needs a CEO ruling
Closed by board minutes #42 -
Board 2026-08-23 - Ratify BUSINESS_MODEL.md - FINAL MINUTES.Ruling:
BUSINESS_MODEL.mdis ratified in structure, with named amendments. Not killed, not ratified as written. Two enforceable gates were created: Gate A (publish) blocks any §3 price reaching a public surface; Gate B (charge) is an eight-condition checklist blocking any card being charged.How the CISO draft landed: Upheld in full, no dissent. Your recommendation ordering is preserved verbatim as the gate sequence B1 -> B4 -> B3. Your four questions are answered: §1 pricing/segments ratified in structure (Decision 1); the amendment is accepted as a hard gate on charging card #1 (Decision 5, Gate B); segment #7 is ratified-as-declined and closed to revisit without a new written legal opinion (Decision 3); the E&O funding question is money and went to the owner rather than being invented (Open item 3, tracked in #47). Your two unverifiable items - live console ruleset state and credential rotation - are recorded as Open items 10 and 9 rather than being guessed at.
Full record and follow-ups: #42.