Scirium v2: anonymize beachhead customer (strike Wall Orthodontics, Anita Brown); remove Wall-O references entirely

projects/scirium/04-business-proposal-v2.md

@@ -9,7 +9,7 @@
 
 ## 1. Executive Summary
 
-Scirium is a white-label, self-hosted knowledge assistant for document-driven SMBs (small and midsize businesses; 10 to 200 employees; MSP (managed service provider) clients, healthcare-adjacent practices, legal, accounting). Every knowledge domain inside a business becomes its own scoped chat channel backed by that business's real documents, served through Rocket.Chat, with grounded, cited answers. The hard invariant is one channel equals one knowledge domain, one attached agent, and one scoped knowledge source, enforced in the schema rather than in prompt text, which is why answers are provably grounded and provably isolated. The never-fabricate rail sits on top: mandatory citations and an explicit "I could not find an answer" fallback when retrieval comes back weak. The beachhead is Wall Orthodontics.
+Scirium is a white-label, self-hosted knowledge assistant for document-driven SMBs (small and midsize businesses; 10 to 200 employees; MSP (managed service provider) clients, healthcare-adjacent practices, legal, accounting). Every knowledge domain inside a business becomes its own scoped chat channel backed by that business's real documents, served through Rocket.Chat, with grounded, cited answers. The hard invariant is one channel equals one knowledge domain, one attached agent, and one scoped knowledge source, enforced in the schema rather than in prompt text, which is why answers are provably grounded and provably isolated. The never-fabricate rail sits on top: mandatory citations and an explicit "I could not find an answer" fallback when retrieval comes back weak. The beachhead customer will be identified as one of IT Pro Partner's (ITPP) existing MSP customers.
 
 The v1 proposal received a CONDITIONAL GO from internal critical review, with seven flaws and seven conditions. This v2 is the remediation, and it changes the recommendation's reason, not its direction. **v1 said build it because the returns are spectacular. v2 says build it because the returns are good if and only if monthly churn holds at or below roughly 3.5% and the acquisition motion matures off cold-outbound cost within the first year.** v1 rested on two load-bearing fictions: a $1,000 CAC (customer acquisition cost) that counted no labor and no failed pilots, and a 12-month revenue ramp that assumed no tenant ever cancels. Both are rebuilt here; the honest numbers still clear the bar, but as a good managed-software business, not the ten-month near-zero-marginal-cost business v1 described.
 
@@ -25,7 +25,7 @@ The numbers that matter in v2:
 - Opex reconciled to **$5,310/mo** (v1's $4,000 valued product management and admin/insurance at zero). Operating breakeven **12 tenants** steady-state; **26 to 40** cash-neutral while growing. Gross margin is a **band, never a single figure**: 94.4% at the 10-minute support target state, 88.4% at 30-minute stress, ~62-65% at the 1.9 support hours per tenant per month the v1-era ops model implies; support hours are the swing variable and a first-class KPI (key performance indicator).
 - Payback: **~20 months** build-cost at Realistic @3% (extrapolated estimate), ~18-22 months at the recommended $499 floor, **38-64 months fully loaded** (CAC-dominated, unchanged).
 
-The plan adds two validation gates. Gate 1: the beachhead pilot at Wall Orthodontics, strictly internal staff knowledge, no PHI (protected health information). Gate 2 (a commitment): before any ramp figure is treated as a forecast, Scirium must land and fully onboard a second pilot arms-length from the founding relationship with no PHI exposure, in a law firm, accounting firm, or retail group. One friendly pilot proves the software works; it does not prove the product can be sold to a stranger, and the difference between those two claims is the whole business case.
+The plan adds two validation gates. Gate 1: the beachhead pilot with an existing ITPP MSP customer, strictly internal staff knowledge, no PHI (protected health information). Gate 2 (a commitment): before any ramp figure is treated as a forecast, Scirium must land and fully onboard a second pilot arms-length from the founding relationship with no PHI exposure, in a law firm, accounting firm, or retail group. One friendly pilot proves the software works; it does not prove the product can be sold to a stranger, and the difference between those two claims is the whole business case.
 
 The three conditions the numbers impose: (1) measure real churn in the pilot cohort before scaling spend, at or below 3.5% per month; (2) productize acquisition inside year one so CAC trends from $3,088 toward $2,053; (3) do not fund cold outbound acquisition, which is not viable at any modeled churn rate. With those conditions held, fund the $167K build against the capacity-constrained ramp.
 
@@ -128,7 +128,7 @@ Scirium is a **sales-led motion at an SMB price point**; bottom-up CAC lands at
 
 Working backwards from 4 closes per month: 7 pilots (60% pilot-to-paid), 20 qualified discovery calls (35%), 29 booked calls (70%), 115 engaged leads (25%), roughly **950 to 1,000 top-of-funnel touches** (12% engagement). That is the honest headline. The demand is real, but the **supply side binds first** (3.4 wins per month); both constraints have to hold, and v1 satisfied neither.
 
-**Motion A: founder-led direct sales.** Target: 2 of the monthly closes in months 1 through 6, dropping to 1 to 2 as the channel scales; the founder closes the first fifteen to twenty deals personally. Lead sources in priority order: the ITPP (IT Pro Partner) managed-services base (highest trust, strictly finite, realistically 5 to 10 closes in total); vertical association and peer networks (bar associations, CPA (certified public accountant) societies, dental and orthodontic study clubs); targeted outbound to a built list (sequenced email plus phone, with the compliance hook that tests best: "your staff are pasting client documents into ChatGPT"); narrow vertical content; and trigger-based outreach (firms that just posted five or more job openings). Five sales assets are required before outbound opens, including a demo tenant that can show a cited answer and a deliberate "I could not find an answer" response, and an objection-handling sheet opening with the now-correct objection: "we already have Copilot." Cadence: 40 touches per day, 8 discovery calls per week, 5 pilots.
+**Motion A: founder-led direct sales.** Target: 2 of the monthly closes in months 1 through 6, dropping to 1 to 2 as the channel scales; the founder closes the first fifteen to twenty deals personally. Lead sources in priority order: the ITPP managed-services base (highest trust, strictly finite, realistically 5 to 10 closes in total); vertical association and peer networks (bar associations, CPA (certified public accountant) societies, dental and orthodontic study clubs); targeted outbound to a built list (sequenced email plus phone, with the compliance hook that tests best: "your staff are pasting client documents into ChatGPT"); narrow vertical content; and trigger-based outreach (firms that just posted five or more job openings). Five sales assets are required before outbound opens, including a demo tenant that can show a cited answer and a deliberate "I could not find an answer" response, and an objection-handling sheet opening with the now-correct objection: "we already have Copilot." Cadence: 40 touches per day, 8 discovery calls per week, 5 pilots.
 
 **Motion B: the MSP and reseller white-label channel.** Target contribution: 2 of 4 monthly closes by month 6, and 3 to 4 by month 12 as partners mature. The pitch takes one sentence: the MSP is asked for an AI offering by its clients and has nothing to sell; reselling Glean or Copilot means putting a vendor's brand in front of a client the MSP has spent years owning; Scirium is the only option checked here that lets the MSP put its own name on a working knowledge assistant.
 
@@ -371,13 +371,13 @@ The recommendation: fund the $167K build against the capacity-constrained ramp,
 
 *Disclaimer: this section is part of a business proposal prepared for internal planning purposes. It is not legal advice. Any legal, trademark, or regulatory conclusions herein must be confirmed by qualified counsel before the underlying decisions (naming, contracting, market launch) are finalized. Nothing in this document is a binding contract or legal advice to any prospective customer.*
 
-### 10.1 Trademark clearance and the rename
+### 10.1 Trademark clearance
 
-The v1 proposal used the internal codename "Wall-O" as the product's working name. Critical review flagged it as a trademark collision risk: it is a near-homophone of Disney/Pixar's "WALL-E," a globally famous, actively enforced mark, and a name that sounds like a well-known mark carries meaningful risk of a demand letter, opposition, or costly rebrand after go-to-market investment. Acting on that review, the product is renamed **Scirium** (pronounced "sigh-ree-um") for all market-facing use, and the codename "Wall-O" is retired; it may persist only as an internal historical reference in prior-dated documents.
+**Scirium** (pronounced "sigh-ree-um") is the market-facing product name for all current and future use.
 
 A basic, non-professional clearance search was run: no exact match for "Scirium" was found as an existing registered trademark, company brand, or software product; the **closest phonetic and spelling neighbor is "Cirium,"** an existing, actively operating aviation data and analytics company (part of LexisNexis Risk Solutions / RELX, rebranded from FlightGlobal in 2019) with AI-adjacent offerings; "Scirium" differs from "Cirium" by a single leading "S," close enough that a professional would want to assess likelihood-of-confusion risk, particularly in the software/data-services classes. One incidental mention of "SCirium" appeared in an academic paper on blockchain-based air traffic management, unclear whether entity, codename, or typo. No conflicting software company, SaaS product, or enterprise-AI brand named "Scirium" was identified.
 
-**Honest statement of residual risk.** This search is not a clearance opinion: it does not check USPTO (U.S. Patent and Trademark Office) TESS (Trademark Electronic Search System) or equivalent registries, state registries, common-law use in commerce, domain and social-handle conflicts, or the goods/services classes that determine likelihood of confusion. Scirium is materially lower-risk than the retired codename was, but the proximity to Cirium, an existing, active, well-funded brand in an adjacent data/analytics space, is a real finding that should not be waved away; the risk is plausibly low but not zero, and it has not been professionally assessed. **Recommendation: obtain a professional trademark clearance search and opinion from qualified counsel before (1) filing any trademark application for Scirium, (2) executing any reseller, franchise, or white-label agreement that extends brand rights to third parties, or (3) any large-scale paid marketing launch under the Scirium name.** This is a go/no-go gate for irreversible brand commitments, not a blocker for continued internal development, pilot use with the first client, or this proposal's approval.
+**Honest statement of residual risk.** This search is not a clearance opinion: it does not check USPTO (U.S. Patent and Trademark Office) TESS (Trademark Electronic Search System) or equivalent registries, state registries, common-law use in commerce, domain and social-handle conflicts, or the goods/services classes that determine likelihood of confusion. The proximity to Cirium, an existing, active, well-funded brand in an adjacent data/analytics space, is a real finding that should not be waved away; the risk is plausibly low but not zero, and it has not been professionally assessed. **Recommendation: obtain a professional trademark clearance search and opinion from qualified counsel before (1) filing any trademark application for Scirium, (2) executing any reseller, franchise, or white-label agreement that extends brand rights to third parties, or (3) any large-scale paid marketing launch under the Scirium name.** This is a go/no-go gate for irreversible brand commitments, not a blocker for continued internal development, pilot use with the first client, or this proposal's approval.
 
 ### 10.2 Advisory-only posture, available at every tier
 
@@ -415,11 +415,11 @@ Data location is known and disclosed at contracting time per deployment option;
 
 Scirium is built and operated by IT Pro Partner (ITPP), a managed services provider founded and led by **Germaine Brown**. ITPP brings the three assets the plan depends on: an existing managed-services client base (the warm pool of roughly a dozen relationships the financial model assumes, A7); an existing production infrastructure estate (netcup hosts, the Wasabi S3 backup pipeline, Vaultwarden secret management, the admin-ai LiteLLM proxy, and existing auth on app3) that Scirium shares rather than buys; and an existing operational discipline (backup verification, monitoring, runbooks, per-tenant managed-services delivery) that the operations model in Section 8.6 extends rather than invents. The team is small by design: the principal (founder), engineers, and technicians execute the build, sales, and onboarding; the go-to-market plan is explicitly founder-led for the first fifteen to twenty deals.
 
-The beachhead customer is **Wall Orthodontics**, the orthodontics and dental practice owned by Anita Brown, which serves as the Gate 1 pilot and the reference case for the dental vertical. The second-pilot commitment (Gate 2) requires an arms-length tenant with no PHI exposure - a law firm, accounting firm, or retail group - signed through one of the Section 6 channels, before any ramp figure is treated as a forecast.
+The beachhead customer will be identified as one of ITPP's existing MSP customers, selected as the Gate 1 pilot and the reference case for its vertical. The second-pilot commitment (Gate 2) requires an arms-length tenant with no PHI exposure - a law firm, accounting firm, or retail group - signed through one of the Section 6 channels, before any ramp figure is treated as a forecast.
 
 **The execution constraint and the dedicated-hire trigger.** Execution is rate-limited by the same hours that drive CAC: at 40 principal-hours plus 80 technician-hours per month, the ceiling is 3.4 warm wins per month. The plan therefore commits to the capacity-constrained ramp (26 gross adds in year one) as the base case, which requires no additional headcount. The Realistic ramp (48 adds) is explicitly conditional on a **dedicated sales and onboarding hire at roughly $6,000 to $9,000 per month, added to opex**; the trigger is Gate 2 passing (repeatable arms-length onboarding) plus two consecutive months of the Section 6 metrics clearing their thresholds with a pipeline that supports the higher add rate. Until then, signing faster than onboarding capacity is the most likely failure mode of the entire plan, and it is managed by capping monthly signings at proven capacity.
 
-**Success definition.** Product v1 (the answer engine): a Wall Orthodontics staff member asks a policy question in a channel and gets a cited, correct answer, with zero fabricated answers across a week of real use, and the DLP fail-closed test passing before the proof slice is called complete. Business: 3 paying tenants with demonstrated ROI (return on investment) within 6 months of v1 launch, and Gate 2's four pass conditions met before any material sales or marketing spend. Technical: the MIT `fossify` white-label build produced in CI before the first non-pilot customer, no PHI ever ingested, isolation verified by an adversarial test, and automated backup restore verification proven on a scratch host.
+**Success definition.** Product v1 (the answer engine): a beachhead-customer staff member asks a policy question in a channel and gets a cited, correct answer, with zero fabricated answers across a week of real use, and the DLP fail-closed test passing before the proof slice is called complete. Business: 3 paying tenants with demonstrated ROI (return on investment) within 6 months of v1 launch, and Gate 2's four pass conditions met before any material sales or marketing spend. Technical: the MIT `fossify` white-label build produced in CI before the first non-pilot customer, no PHI ever ingested, isolation verified by an adversarial test, and automated backup restore verification proven on a scratch host.
 
 ---
 
@@ -448,7 +448,7 @@ Product v1 is the answer engine plus the safety rails, and nothing else. The mes
 
 ### 12.3 Phase 0 proof slice, with the DLP gate and the R8 spike
 
-Phase 0 is one Rocket.Chat workspace for Wall Orthodontics, a registered bot, one channel, one attached agent, one indexed document, and one grounded cited answer. Two additions to Phase 0 are mandatory. First, **the DLP fail-closed test must pass before the proof slice is called complete**, because retrofitting DLP after the pipeline exists is how it ends up bypassable. Second, the **load-bearing uncertainty spike**: the exact behavior of the Rocket.Chat Apps-Engine pre-send hooks (`IPreMessageSentPrevent` and related interfaces) under Rocket.Chat 7.4.0 with the MIT `fossify` build is unverified, and whether app hooks fire for messages created through the REST API is unknown; Layer 1 DLP depends on it. A timeboxed spike in Phase 0 must verify hook behavior end to end, and **DLP cannot be declared production-ready until it passes**. Alongside it, the 40-hour M365 connector spike of Section 8.5 runs, with a written go or no-go on the 275-hour estimate.
+Phase 0 is one Rocket.Chat workspace for the beachhead customer (an existing ITPP MSP customer), a registered bot, one channel, one attached agent, one indexed document, and one grounded cited answer. Two additions to Phase 0 are mandatory. First, **the DLP fail-closed test must pass before the proof slice is called complete**, because retrofitting DLP after the pipeline exists is how it ends up bypassable. Second, the **load-bearing uncertainty spike**: the exact behavior of the Rocket.Chat Apps-Engine pre-send hooks (`IPreMessageSentPrevent` and related interfaces) under Rocket.Chat 7.4.0 with the MIT `fossify` build is unverified, and whether app hooks fire for messages created through the REST API is unknown; Layer 1 DLP depends on it. A timeboxed spike in Phase 0 must verify hook behavior end to end, and **DLP cannot be declared production-ready until it passes**. Alongside it, the 40-hour M365 connector spike of Section 8.5 runs, with a written go or no-go on the 275-hour estimate.
 
 ### 12.4 Ops automation before tenant five
 
@@ -502,7 +502,7 @@ The v2 roadmap adds risk-tiered "do" capabilities, ordered by write risk, none o
 | 11 | "Data never leaves the customer's estate" | **Corrected**: inference may leave. Three explicit lanes (cost-optimized, compliance-routed with DPA + region pinning + no-retention, fully on-premise open-weight) with stated tradeoffs and payload minimization |
 | 12 | "No PHI, enforced at ingestion" | **Runtime DLP at the chat layer and the orchestrator boundary, both failing closed**, with an audited dlp_events trail and honest limitations stated |
 | 13 | Ramp scenarios 22 / 48 / 90 tenants, no capacity model | Four scenarios net of churn; **Aggressive (90) struck** as not executable under the 3.4-wins/mo sales-capacity ceiling; capacity-constrained (26) is the recommended planning case |
-| 14 | Product name: the v1 codename Wall-O | **Scirium**, following trademark review; Wall-O retired to internal historical references only (see Section 10.1) |
+| 14 | Product name and trademark risk | **Scirium** is the sole market-facing name; clearance search found no exact match; closest phonetic neighbor Cirium flagged for professional review before filing or launch (see Section 10.1) |
 
 ---