91 KiB
Scirium Business Proposal v2 (DRAFT FOR REVIEW)
Product: Scirium (pronounced "sigh-ree-um") - a white-label, self-hosted AI (artificial intelligence) knowledge assistant for document-driven SMBs Version: v2 (assembled from the marketing, technical, financial, and legal remediation sections; supersedes the v1 proposal dated 2026-08-16) Date: 2026-08-17 Status: DRAFT FOR REVIEW - recommended verdict: GO with conditions (churn gate, acquisition-maturation gate, professional trademark clearance, Phase 0 data-loss-prevention (DLP) spike). One-line version: build Scirium against a capacity-constrained ramp at a corrected $167K build, and gate all growth spending on measured pilot-cohort churn at or below roughly 3.5% per month.
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.
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.
What survived review unchanged: marginal cost of about $0.42 to $0.50 per 1,000 queries (immaterial even at a 5x LLM (large language model) price rise); the white-label wedge, re-verified against live vendor sources (no incumbent among Glean, Guru, Notion, Moveworks, and Microsoft Copilot offers white-label branding as a purchasable product; a negative finding from public sources and a go-to-market moat, not a technical one); and gross profit per tenant of about $443 per month, a strong per-unit engine.
The numbers that matter in v2:
- Build cost:
$68K to **$167K** (1,667 hours incl. contingency; connector re-estimated to a 275-hour midpoint; 360 hours of new v2 work (runtime DLP 90, the Rocket.Chat DLP app 50, three-lane routing 60, ops automation 160)). - CAC: $1,000 to $3,088 warm / $6,205 cold / $2,053 mature. LTV (lifetime value):CAC 4.8:1 warm @3% (7.2:1 mature, 2.9:1 @5%); the old 14.8:1 headline is the arithmetic artifact of the fictional $1,000 CAC, labeled as such.
- Ramp rebuilt net of churn; recommended planning case is the new capacity-constrained scenario: 26 gross adds, 22.05 tenants @3%, $72.2K net revenue, $123.9K year-one CAC spend, operating breakeven crossed in month 6 @3%. The Aggressive 90-tenant case is not executable under the 3.4-wins-per-month sales-capacity ceiling and is struck.
- 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 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.
2. Problem & Opportunity
Every organization past a handful of employees has the same failure: new hires take weeks to become useful because institutional knowledge is scattered across SharePoint libraries, PDFs, shared drives, and senior staff memory; repetitive questions interrupt the most expensive people in the building; policy changes never fully propagate, so some staff always operate on a superseded rule. The answer is almost always already written down; it is simply not findable by the person who needs it. Independent studies converge on knowledge workers losing roughly a fifth to a third of the workday to hunting for information that already exists (McKinsey, IDC (International Data Corporation), and Deloitte estimates are frequently recycled and should be treated as directional, not precise). The cost does not scale down with company size, but the tooling that fixes it does not scale down either.
Why every current answer fails: asking a manager interrupts the highest-paid person and does not scale; manual search costs 10 to 20 minutes per hunt with poor recall; printed binders go stale immediately; public consumer LLMs have no access to internal documents, fabricate confidently, and staff paste confidential text into a third-party service; and enterprise knowledge AI works only at enterprise price and enterprise procurement. The incumbents are not failing to serve small firms by accident; their cost structure makes small deals irrational for them. Glean is reported at roughly $50 to $75 per user per month with minimums commonly near 100 seats, a floor near $60,000 per year (third-party; Glean does not publish list pricing). Microsoft 365 Copilot is $30 per user per month on an annual commitment on top of a required base license, or $23.50 in an SMB bundle (vendor-confirmed): the buyer pays per seat, forever, to Microsoft. Guru no longer publishes a per-seat price at all (vendor-confirmed). And nobody sells the brand: even where an incumbent will take a smaller deal, the customer ends up using a product with someone else's name on it, which removes the reason an MSP would ever champion it.
The buyer is not buying "AI." The buyer is buying the removal of four line items: senior staff time lost to answering the same twelve questions; new-hire ramp time; errors and rework caused by staff following a superseded policy; and the compliance anxiety of staff pasting internal documents into a public chatbot. The pitch has to be measured against those four, because they are the only things the buyer will notice on a renewal call.
3. Product Overview
Scirium is a white-label, self-hosted internal staff knowledge assistant. Every knowledge domain inside a business (employee handbook, billing, IT (information technology) help, front office, policies) becomes its own scoped chat channel backed by that business's real documents. The product model references no industry; the same core serves a 12-person dental practice and a 200-person law firm.
The core primitive: the hard invariant. Every channel is exactly three things bound together: one knowledge domain, one attached AI agent (a domain-tuned persona), and one scoped knowledge source (one vector namespace over an allowlisted document set). A channel cannot span two domains, and an agent cannot serve two channels. This is enforced in the schema with unique constraints running in both directions, not in application code. It is the reason answers are provably grounded (only one scope feeds the answer) and provably isolated (a billing question cannot surface a neighboring domain or a neighboring tenant).
The never-fabricate rail. Two mandatory behaviors, both product-defining: every answer carries inline citation markers and a Sources footer linking each cited document; and empty or below-threshold retrieval returns "I could not find an answer" with no sources. Hallucination is the one risk that kills the product: if Scirium ever states a wrong policy or billing rule confidently, trust collapses. This is why the answer engine ships before any "do" capability.
What changed in the safety posture. v1 claimed PHI protection was "enforced at ingestion." That claim was not defensible: ingestion filters inspect documents pulled from SharePoint, but they do not see a staff member typing patient data directly into a chat message, and that path reached the third-party LLM unfiltered. v2 adds runtime PHI/PII (personally identifiable information) detection at two independent enforcement points that fail closed (the chat layer and the orchestrator boundary), described in Section 8.2. The v1 claim that data "never leaves the customer's estate" was also factually wrong for the LLM call; v2 replaces it with an explicit three-lane routing model with stated tradeoffs (Section 8.3).
Honest scope language. Scirium is not a HIPAA (Health Insurance Portability and Accountability Act)-compliant system and must never be sold as one. It is an internal staff knowledge tool with defense-in-depth controls that reduce the probability of PHI entering the pipeline; detection is probabilistic, and the product is not offered under a Business Associate Agreement. [to verify with counsel before publication: the exact customer-facing phrasing]
4. Market & Competitive Landscape
4.1 Market size
Bottom-up, per-seat, blended at $10 per user per month, deliberately below every enterprise incumbent's verified or reported price:
TAM (total addressable market) = ~1.0B global knowledge workers x $10/mo x 12 = ~$120B/year
SAM (serviceable addressable market) = 1.0B x ~46% (SMB share of private-sector employment) = ~460M workers
x $10/mo x 12 = ~$55B/year
SOM (serviceable obtainable market) = $55B x 1% (category winner, 3 to 5 year horizon) = ~$550M/year
$55B x 0.1% (year 1 to 2, realistic) = ~$55M/year
US (United States)-only cross-check: roughly 100M US knowledge workers, of whom SMBs employ about 46% (US Small Business Administration data), gives a US SMB SAM near $5.5B; a 1% capture is $55M per year. The honest framing: market size is not the risk. Distribution is the risk, which is why Sections 6 and 7 carry the load in this document.
4.2 The category is real, funded, and consolidating
| Company | Signal | Confidence |
|---|---|---|
| Glean | $150M Series F at a $7.2B valuation (June 2025); $100M ARR (annual recurring revenue) early 2025, $200M on 8 December 2025 | Vendor-confirmed |
| Moveworks | Acquired by ServiceNow for $2.85B; announced 10 March 2025, completed 15 December 2025 | Vendor-confirmed |
| Notion | Enterprise search across Teams, SharePoint, and OneDrive in Notion 2.51 (13 May 2025) with unlimited Notion AI in Business and Enterprise plans | Vendor-confirmed |
| Microsoft 365 Copilot | $30 per user per month add-on, annual commitment, on top of a required base license | Vendor-confirmed |
A $2.85B acquisition closed, a company doubling ARR in nine months (Fortune, December 2025), and Microsoft bundling the capability into its own suite: the category is validated and getting more competitive at the top, which is precisely why Scirium must not compete on generic "AI search over your documents."
4.3 Corrected competitive landscape
Replaces the v1 table; two v1 claims that were factually wrong are corrected in 4.4.
| Competitor | Price | Deployment | White-label? | Real gap Scirium exploits |
|---|---|---|---|---|
| Glean | ~$50-75/seat, minimums commonly near 100 seats, floor near $60K/yr (third-party) | Glean Hosted (software as a service (SaaS) on Google Cloud Platform (GCP)) or Customer Hosted, a Glean-operated managed tenant in the customer's AWS (Amazon Web Services)/GCP account (vendor-confirmed) | No white-label found; partner material reads "Powered by Glean" | Price and seat floor, plus true self-hosting: Glean's docs state Customer Hosted "is not a traditional self-hosted model," runs only in GCP/AWS |
| Moveworks | Not published; third-party estimates near six figures/yr | ServiceNow platform | No white-label found | IT/HR (human resources) ticket deflection tied to a ServiceNow estate, not general internal knowledge |
| Guru | No public per-seat price as of Aug 2026 (vendor-confirmed); third-party trackers cite ~$25/seat, 10-seat min | Vendor cloud only | No white-label found | No self-hosting, no rebrand, no channel-level scope isolation; moving upmarket |
| Notion AI | Bundled into Business and Enterprise plans with unlimited Notion AI (vendor-confirmed) | Vendor cloud only | No white-label found | Vendor-cloud-only hosting, no rebrand, no hard per-channel scope isolation. Notion does connect to Microsoft 365 (M365; 4.4) |
| Microsoft 365 Copilot | $30/seat/mo add-on, annual commitment; SMB bundle $23.50 (vendor-confirmed) | Microsoft cloud only | No white-label found; Copilot Studio permits name/icon changes but runs on Microsoft infra | Per-seat cost forever, Microsoft-cloud lock-in, no rebrandable resale, no self-hosting |
| Coveo / Dust | Enterprise quote-based; Dust per-seat plus credits | Vendor cloud | [to verify] | No SMB tier; agent-builder toolkit, not turnkey |
| Open WebUI, Onyx, AnythingLLM | Free and open source | Self-host | Open source, so branding is technically possible, but no commercial white-label program | Raw RAG (retrieval-augmented generation) toolkits: no per-tenant isolation guarantees, no managed M365 connector, no vertical templates, no support contract |
4.4 Two v1 claims that were wrong, corrected
Notion AI does have a Microsoft 365 connector. The v1 claim "Q&A only over Notion content; no M365 connector" is false and must never be said in front of a prospect. Notion ships a SharePoint and OneDrive AI Connector (documented in Notion's own help center), announced in Notion 2.51 (13 May 2025); it maps to existing Microsoft permissions and syncs hourly. The defensible version: the connector is beta, gated to Business/Enterprise plans, initial connection can take up to 36 hours, and Notion AI cannot read SharePoint site pages or personal OneDrives. Real coverage limits, not "no M365 connector."
Glean is not purely SaaS. Glean documents two deployment models; Customer Hosted (previously Cloud-Prem) places a Glean tenant inside the customer's own AWS or GCP account. Glean's own documentation says Customer Hosted "is not a traditional self-hosted model" and is "equivalent to a hosted-SaaS model, where Glean still has minimal access to operate it," and Glean maintains support access. The correct differentiator is not "we self-host and they cannot." It is: we self-host on infrastructure you or your MSP controls, at a price point Glean's seat minimum structurally cannot reach, and you can put your own name on it.
5. Positioning, Differentiation & the White-Label Wedge
For document-driven small and mid-sized organizations in compliance-sensitive work, Scirium is the knowledge assistant that runs on infrastructure you control, wears your brand, and can prove where every answer came from. Unlike enterprise platforms that require a hundred seats and put their own logo in front of your staff, and unlike consumer chatbots that guess, Scirium is scoped one domain at a time and will tell your team "I could not find an answer" rather than invent one.
The four differentiators, in order of durability. 1. White-label, as a purchasable product. Verified in Section 4 as unmatched by any of the five incumbents checked; the wedge and the entire reason the MSP channel can exist. 2. The one-channel-one-agent-one-scope invariant. Enforced in the schema, not with prompt instructions; competitors do broad permission-aware search across the whole corpus, which is genuinely useful for a 5,000-person enterprise and a liability for a 30-person firm. 3. The never-fabricate rail. Mandatory citations and the explicit fallback; hallucination risk is an acknowledged limitation of the incumbents too, and Scirium's difference is that the fallback is a hard product behavior rather than a recommended configuration. 4. Economics that permit SMB pricing. Marginal cost of roughly $0.42 to $0.50 per 1,000 queries against a $199 to $2,000 per month band; real and durable, but a supply-side advantage only. v1's error was treating a cost advantage as if it were a distribution advantage.
The white-label wedge, re-verified, with honest caveats. The greenlight condition was to confirm the wedge rather than assume it. Live check across Glean, Guru, Notion, Moveworks, and Microsoft Copilot: no vendor among the five publishes, documents, or markets a white-label or OEM (original equipment manufacturer) rebranding program for its knowledge assistant. Each ships as a named, vendor-branded product; Glean's partner material reads "Powered by Glean," which is co-branding and the opposite of white-label; Copilot Studio permits per-agent name/icon changes and a custom chat canvas, the closest any incumbent gets, but the agent still runs on Microsoft infrastructure with per-seat Microsoft licensing. Two caveats: this is a negative finding from public sources - the defensible claim is "no major incumbent offers white-label branding as a purchasable product"; and the wedge is a go-to-market moat, not a technical one - any vendor could add a branding layer, but none is likely to restructure per-seat enterprise pricing to make a 20-seat reseller deal worth closing.
Where a competitor genuinely beats us, stated plainly because a proposal that claims no weaknesses gets discounted entirely: breadth of connectors (Glean and Notion connect to dozens of systems; Scirium v1 connects to SharePoint and OneDrive, so a prospect with critical knowledge in Salesforce, Zendesk, or Jira is not our buyer yet); brand safety of the incumbent choice (nobody was ever fired for buying Microsoft); company-wide discovery (if the customer's actual need is "search everything at once," the scope invariant is a constraint they will resent); and roadmap velocity (we will not out-feature Glean; we compete on segment, price, brand ownership, and isolation).
Strategic implications. Do not lead with "AI chat over your documents": as of 2026 the two tools an SMB owner most likely already has, Microsoft 365 Copilot and Notion AI, both do grounded Q&A over SharePoint and OneDrive. Lead with what they verifiably do not have: your brand on it, your infrastructure under it, and hard per-channel scope isolation. Assume the price floor for generic knowledge Q&A moves toward zero over time; Scirium's premium has to be justified by isolation, branding, and control, which are architecture, not features.
6. Go-To-Market & Sales Engine
The v1 go-to-market described a beachhead, an MSP channel, and a three-step motion, but no sales engine: no funnel math, no lead sources, no capacity model, no quota, no honest CAC. The review's sharpest finding: the realistic 48-tenant ramp requires about 4 net-new signed and onboarded tenants every month, sustained for a year, and no engine to deliver that exists.
The v2 answer is not a bigger sales engine; it is an honest capacity model. Costing CAC in hours (Section 9.4) exposes that acquisition is rate-limited by principal and technician availability: the ceiling is 3.4 warm wins per month (and 1.7 cold wins) at a realistic 40 principal-hours plus 80 technician-hours per month. Sustaining 4 net-new tenants per month therefore requires either the partner channel maturing or a dedicated sales and onboarding hire at roughly $6,000 to $9,000 per month, which is not in the $5,310 opex. Without that hire, the sustainable add rate is 2 to 3 per month, exactly the capacity-constrained scenario this plan builds on. The Aggressive 90-tenant case is not executable under the ceiling (its month-12 schedule of 13 adds alone needs roughly 620 technician hours) and is struck from the plan unless explicitly re-costed with dedicated headcount.
Scirium is a sales-led motion at an SMB price point; bottom-up CAC lands at $3,088 warm / $6,205 cold / $2,053 mature (Section 9.4). The v1 phrase "CAC is near zero because we own distribution" should be struck: owned distribution shortens the first conversation but does not eliminate the sales motion, and it runs out after the first dozen relationships (warm pool modeled at 12 tenants).
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 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.
| Element | Terms |
|---|---|
| Partner margin | 30% of recurring revenue on partner-sourced tenants, rising to 40% above 10 active tenants |
| Onboarding fee | Partner keeps 100% of the setup and document-audit fee |
| Branding | Full white-label: partner's name, logo, colors, and domain; Scirium is invisible to the end client |
| Floor | No minimum commitment; a minimum kills partner signups in this segment |
| Our delivery obligation | We host and operate the infrastructure and provide tier-2 support; partner owns the client relationship and tier-1 |
Partner recruitment: roughly 50,000-plus MSPs operate in the United States (third-party, directional); a realistic year-one target is 8 to 12 signed partners, of which perhaps 4 to 6 become genuinely productive (channel programs follow a power law; planning for uniform partner productivity is how channel forecasts fail). Before a partner counts: enablement session plus certification call, branded demo tenant, collateral, deal registration (any account a partner registers is theirs for 90 days, and our direct motion does not touch it), and first-deal support.
Blended plan, reconciled to capacity. The v1-era schedule (2/mo ramping to 5 to 6/mo, 44 to 50 cumulative) does not hit 4 per month until month 4 or 5; the executable year-one plan is the capacity-constrained schedule (26 gross adds, roughly 2 to 3 per month, front-loaded on the warm pool then throttled to the cold-acquisition ceiling), detailed in Section 9.6. The Realistic 48-add schedule is the plan only if the dedicated hire is funded.
The delivery constraint, which v1 omitted entirely. Signed is not onboarded, and onboarded is what gets paid. Each new tenant requires provisioning, an M365 connector configuration, a document library audit, channel and agent and scope setup, ingestion and spot-check validation, an admin training session, and a two-week check-in. This labor is already costed inside CAC: a warm win carries 7.1 principal hours plus 23.8 technician hours including the failed-pilot loading (Section 9.4). The 40 to 56 hours per month of onboarding at 4 tenants per month is real and funded through CAC; what must still be planned is delivery capacity (runbook proven at Gate 1, executed by a non-builder at Gate 2, onboarding under 8 hours per tenant by month 9, or the model caps out around 5 tenants per month).
Metrics that decide whether this is working, reviewed monthly, each with a failure threshold: new tenants (4/mo by month 5 under the funded-hire plan; investigate below 3); blended CAC ($2,050 to $2,600; the floor is the mature-state CAC of $2,053; investigate above $3,500); pilot-to-paid (60%; below 40% is a problem); time to activated (under 14 days); onboarding hours (falling toward 8); weekly active staff (above 40% of seats; below 25% is the leading churn indicator); queries per active user (above 3); the "I could not find an answer" rate (5% to 15%); confirmed fabrications (zero; any instance is stop-and-fix); producing partners (5+ by month 12); gross churn (under 3%; above 5% trips the treadmill, Section 9.8).
The three most likely ways this go-to-market fails. 1. Top-of-funnel starvation after the warm list runs out (early warning: engaged leads below 60 per month in month 3). 2. Channel signed but not selling (track producing partners, never signed). 3. Onboarding backlog turning sales wins into churn (cap signings at proven onboarding capacity; activation rate is the real growth metric).
What is required to start: Gate 1 complete (beachhead pilot live, closed loop proven, onboarding runbook written); Gate 2 committed and funded (arms-length non-PHI pilot with all four pass conditions met before ramp spend); the five sales assets of Motion A complete; the partner program; a named onboarding owner; and a real acquisition budget consistent with $2,050 to $2,600 blended CAC, not a near-zero-CAC assumption.
7. Pricing
| Tier | Price | Includes |
|---|---|---|
| Starter | $199/tenant/mo (up to 10 users, +$15/user beyond) | 1 M365 connector (SharePoint + OneDrive), Rocket.Chat, 50K docs, 1 channel scope set |
| Business | $499/tenant/mo (up to 25 users, +$25/user beyond) | Teams connectors, unlimited channel scoping, single sign-on (SSO; OpenID Connect (OIDC)/Security Assertion Markup Language (SAML)), 250K docs, SLA (service-level agreement)-backed support, monthly DLP report |
| Enterprise | $2,000/tenant/mo (annual contract) | Dedicated instance, unlimited seats, custom connectors, SCIM (System for Cross-domain Identity Management), signed DPA (data processing agreement), custom retention, white-glove onboarding, 99.9% SLA |
Every tier includes the core grounded Q&A engine, the channel-scoped isolation invariant, citations, audit logs, and the no-PHI guardrail; higher tiers unlock more v2 capabilities and white-glove onboarding, not better core answer quality. The legal and compliance package is advisory-only and available at every tier (Section 10).
Enterprise tier benchmark. $2,000 per tenant per month is priced against what the incumbents charge for comparable scope: a 100-seat Microsoft 365 Copilot deployment costs about $3,000 per month ($30/seat) on top of required base licenses, and Glean's commonly cited ~100-seat minimum lands near $5,000 to $7,500 per month (Section 4.3). The gap is deliberate: the Enterprise tier funds its own dedicated infrastructure (Section 8.7, Option B), unlimited seats, white-glove onboarding, a signed DPA, and a 99.9% SLA, none of which the lower tiers carry.
Base case. The base financial case uses the conservative 60/30/10 tier mix, which blends to $469.10 per tenant per month (0.60 x 199 + 0.30 x 499 + 0.10 x 2,000). The v1 practice of modeling a $450 safety haircut is dropped because ARPU (average revenue per user) is not the fragile assumption; churn and CAC are. All revenue figures in Section 9 use $469.10.
Strategic pricing lever (explicitly not in the base model). The technical team's cost analysis (Section 8.6) shows that a $199 Starter tier cannot carry the fully-loaded per-tenant cost of a managed self-hosted fleet. Their recommendation is a strategic lever, labeled as such and kept out of the base model: retire the $199 Starter tier and enforce a $499 floor. That lifts blended ARPU toward $700 to $800 per tenant per month, raises fully-loaded contribution to roughly $202 per tenant per month at the current operations model, and pulls operating breakeven back to 22 to 23 tenants on the fully-loaded basis (fleet engineering included: ~$202 contribution per tenant per month against $4,500 per month fleet-wide engineering; 15 to 16 once support hours are automated down toward 1.0 per tenant per month). On the COGS (cost of goods sold)/opex basis the steady-state breakeven stays at 12 tenants (Section 9.8); the two bases are deliberately separate. The base case deliberately keeps the conservative $469.10 mix; the $499 floor is the lever a decision-maker can pull if the support-hours KPI does not converge.
8. Technical Architecture
8.1 The canonical layer split
| Layer | Responsibility | Owns |
|---|---|---|
| Rocket.Chat | Chat transport only | One workspace per tenant, MIT fossify build with EE (Enterprise Edition) stripped; rooms, users, messages; plus the chat-layer DLP app. Zero intelligence |
| Orchestrator | All intelligence | Multi-tenant FastAPI service: tenancy, agents, kb_scope, M365 connector, retrieval, DLP, LLM routing, posting |
| Presidio analyzer/anonymizer | DLP verdicts | Self-hosted, loopback only, no external calls |
| Postgres + pgvector | State and vectors | Tenants, channels, agents, scopes, documents, chunks, messages, dlp_events |
| admin-ai (LiteLLM) | LLM routing | Lane-aware routing with in-lane fallback chains only |
| Wasabi S3 (Simple Storage Service) | Object storage | M365 sync staging, backups, agent assets, audit exports |
The intelligence never lives in the chat layer. That split is what makes multi-tenancy clean and white-labeling a server-side concern instead of a per-tenant code fork.
8.2 Runtime PHI/PII DLP, failing closed
v1's ingestion-only filter caught PHI in documents but missed PHI typed into chat messages, DMs (direct messages), attachments, or REST (Representational State Transfer) API (application programming interface) injections, and retrieved chunks could carry PHI into the prompt. v2 adds two enforcement points that fail closed: chat-layer DLP (pre-persistence) and orchestrator-boundary DLP (pre-LLM). The orchestrator is the only component that talks to the LLM, so it cannot be bypassed.
Layer 1: chat-layer DLP (pre-persistence). A Rocket.Chat Apps-Engine app shipped with each tenant's provisioning bundle implements pre-send hooks (IPreMessageSentPrevent to block, IPreMessageSentModify to redact, IPreMessageUpdatedPrevent, IPreFileUpload). It calls the orchestrator DLP endpoint over HTTPS (Hypertext Transfer Protocol Secure), HMAC (hash-based message authentication code)-signed, and receives allow/redact/block; block prevents the send, redact rewrites the body before persistence so raw PHI is never written to MongoDB. Layer 1 stops PHI from ever landing in the tenant's chat database.
Layer 2: orchestrator-boundary DLP (pre-LLM). The orchestrator independently inspects the inbound question, the retrieved chunks, and conversation history immediately before the prompt is built. On BLOCK the LLM call is not made at all, a refusal is posted, a dlp_events row is written, and the audit record confirms zero tokens were sent. This layer is not optional and not tenant-disableable.
How it fails closed: DLP unreachable, timeout, 5xx, or malformed body all deny; an unhandled exception denies (the verdict defaults to block, reassigned only on an explicit allow); a tenant admin disabling the Rocket.Chat app leaves Layer 2 enforcing with a dlp_degraded flag and ITPP alert; DLP failing at startup means the application refuses to start; missing Presidio models fail startup. There is no fail-open toggle in code, and a CI (continuous integration) test kills the DLP dependency and asserts both layers deny, gating deployment.
The detection engine. Microsoft Presidio, Apache-2.0, self-hosted on loopback, three stages: regex and checksum recognizers for structured identifiers (SSN (Social Security number), MRN (medical record number) patterns, member and group numbers, NPI (National Provider Identifier), CPT (Current Procedural Terminology) and ICD (International Classification of Diseases)-10 codes, account numbers, phone, email, full dates of birth) plus per-tenant patterns; NER (named entity recognition) recognizers (PERSON, LOCATION, DATE_TIME, US_SSN, MEDICAL_LICENSE); and contextual co-occurrence rules (a name plus DOB (date of birth), member id, or clinical term is PHI; a name alone is not). BLOCK: SSN, MRN, member id, NPI, account, card, name-plus-clinical-context, full DOB in isolation [to verify with counsel]; REDACT: email, phone, address; ALLOW and log: name alone. An identical guardrail at the admin-ai (LiteLLM) proxy is defense-in-depth only [to verify against the deployed version].
Honest limitations, stated in the proposal and in the customer contract. Presidio's own documentation states there is no guarantee it will find all sensitive information. Recall is not 100%; false positives will annoy staff (per-tenant thresholds starting at 0.7 plus an allow-list); a determined insider can obfuscate data through (DLP is a guardrail against accident and habit, not against a motivated malicious insider); detection is English-only at launch [to verify: Spanish]. DLP adds ~300 to 650 ms per query (250 ms Layer 1, 400 ms Layer 2, both deny on expiry); the NER model adds 1.5 to 2.5 GB RAM (random access memory) per analyzer [to verify under load]. dlp_events stores entity types (never matched values), counts, confidence, a salted hash, and failure mode; raw values are never written, logged, or sent externally. A monthly DLP report is a Business-tier deliverable.
8.3 Three-lane LLM routing and the data-control promise
The v1 claim that data "never leaves the customer's estate" was factually wrong for the LLM call: the prompt carries the staff question plus retrieved chunks, the customer's internal knowledge, sent verbatim to a third party; a self-hosted proxy in front of a hosted model is not self-hosted inference; and DeepSeek's published privacy policy stores user-provided content on servers in the People's Republic of China, a procurement stopper for US regulated-adjacent customers [to verify: current DeepSeek enterprise/API terms].
The corrected statement that ships: chat, documents, vectors, audit logs, and DLP processing are fully self-hosted inside the ITPP-controlled estate; inference is the one component that may leave the estate, depending on the routing lane the tenant selects. Routing is a per-tenant (and optionally per-channel) configuration column enforced by the orchestrator's LLM client, and fallback chains are defined within a lane, never across lanes.
- Lane A: cost-optimized (default for non-sensitive tenants). DeepSeek V4 Flash or Pro via admin-ai/LiteLLM, ~$0.42 to $0.50 per 1,000 queries. Third-party processing, possible out-of-jurisdiction storage, no contractual retention or training posture. Sold to non-regulated SMB only; not sold to healthcare-adjacent, legal, or accounting tenants (hard sales gate).
- Lane B: compliance-routed (recommended for regulated-adjacent tenants). Enterprise-contracted hosted model with contractual data controls; reference target Azure OpenAI pinned to a US region (no-training committed, region pinning, modified-abuse-monitoring path removes the 30-day retention window [to verify: eligibility, pricing]). Cost ~$5 to $20 per 1,000 queries [to verify]; at $20, 3,000 queries per month costs $60 against a $499 subscription, so the tier still holds.
- Lane C: fully on-premise (open-weight, nothing leaves). Open-weight instruct model served locally with vLLM or llama.cpp on a dedicated GPU (graphics processing unit) host (reference: Hetzner GEX44, RTX 4000 SFF (small form factor) Ada, ~EUR 184 to 234 per month [to verify pricing and VAT (value-added tax)]). Fixed infrastructure, not per-token; one host can serve multiple Lane C tenants. The only lane where "data never leaves" is literally true. Tradeoff: below frontier quality on complex reasoning, but much smaller on grounded extractive Q&A; must be demonstrated on prospect documents during the pilot [to verify: Phase 0 evaluation set]. Gating requirements: a Data Processing Addendum with the model vendor (ITPP holds it as controller-side counterparty; no DPA, no Lane B); no-training and no-retention settings evidenced quarterly; regional routing pinned to a named US region or the tenant's jurisdiction (verified by endpoint inspection); and subprocessor disclosure with a right to object. Legal counterpart: the LLM vendor DPA (Section 10.6); contract exhibits update before any vendor or fallback change ships.
Payload minimization regardless of lane: sends the question, retrieved chunks, persona, and citation instructions (all post-DLP); never sends tenant identity beyond an opaque id, user identity, email, document paths, URLs, or credentials (citations re-attached locally); sends nothing at all on DLP block.
8.4 Tenant isolation
Isolation, in order of trust: schema-level tenant_id with unique constraints on the channel/agent/scope binding; Postgres row-level security keyed on a session variable; vector namespace filtering on every similarity query; physical chat separation (one Rocket.Chat workspace plus one MongoDB per tenant, isolated volumes, loopback-only Mongo ports); HMAC webhook auth with timestamp-skew checking and message-id dedupe; and an adversarial isolation test in CI that must fail on every cross-tenant route, gating deployment.
8.5 The M365 connector spike
The v1 estimate of 145 hours ("authenticate, crawl, chunk, index") treated the connector as trivial. The design doc specifies far more: multi-tenant Entra registration with per-tenant admin consent and re-consent; the Sites.Selected grant workflow; token management with per-tenant caching and rotation; batched crawling with paging; delta sync with deltaLink persistence, 410 recovery, and delete reconciliation; change-notification subscriptions with a 6-hour renewal cron against a 3-day expiry; 429 throttling discipline; ACL (access control list) mapping from SharePoint permissions onto kb_scope (the genuinely hard part); file format and OCR (optical character recognition) handling; Graph search fallback with a staleness gate; sync observability; and DLP on the ingestion path with block-and-quarantine. The revised estimate is 250 to 300 hours, with 275 as the planning midpoint, the riskiest engineering line in the project. A 40-hour timeboxed spike, drawn from the 275, must answer four questions before the full build is committed: does Sites.Selected consent work end to end against a real client tenant; does ACL mapping hold for the pilot's actual permission structure; what proportion of real documents parse cleanly and how many need OCR; and what is the real delta-sync throughput and throttling ceiling. The exit criterion is a written go or no-go on the 275-hour figure, with library-level scoping as the documented fallback.
8.6 Per-tenant operations model and honest cost
v1 priced 48 to 90 stateful per-tenant stacks at $3,500 to $4,000 per month total, which is not an operating cost, it is a rounding error. Architecture decision: shared Rocket.Chat for all tenants is rejected (it breaks the isolation invariant that is the entire moat); one host per tenant is rejected below the Enterprise tier; container-per-tenant for isolation, shared-host density for economics, automation to make the fleet manageable is the standard model; dedicated hosts are the Enterprise premium. Density: 10 to 12 stacks per 64 GB host (MongoDB memory is the binding constraint) [to verify with a load test at 3 tenants]; 4 to 5 hosts at 48 tenants, 8 to 9 at 90.
No per-tenant action may be manual (160 hours of automation v1 did not carry): Terraform/Ansible host provisioning; one-command tenant provisioning (target under 15 minutes); de-provisioning with export and retention hold; canary fleet upgrades with automatic rollback; nightly encrypted backups to Wasabi S3 plus an automated weekly restore test against a scratch host (an unverified backup is not a backup); per-tenant synthetic probes, DLP liveness, and certificate expiry alerting; PHI-safe log aggregation; Vaultwarden secrets; runbooks for the top ten failure modes. All of this must be automated before tenant number five.
Infrastructure is genuinely cheap (~$13 per tenant per month at 48 tenants). Human operations is the line v1 omitted entirely: 1.90 hours per tenant per month (fleet ops 0.35, support 0.60, DLP tuning 0.20, connector maintenance 0.30, incidents 0.25, account health 0.20) at $100/hr blended = $190. Steady-state engineering is $4,500 per month fleet-wide (v1: $3,500). Combined: roughly $653 per tenant per month at 10 tenants, $297 at 48, $253 at 90 (ops $190 plus engineering share $4,500/n plus infra $13: at 10 tenants 190 + 450 + 13 = $653; at 48, 190 + 94 + 13 = $297; at 90, 190 + 50 + 13 = $253).
At the v1 pricing mix, ~$297 per tenant per month at 48 tenants puts the all-in contribution margin near 34 to 37 percent, which is why pricing matters (Section 7.3) and why support hours are the real product variable: every 0.5 hours removed from the 1.9-hour baseline is $50 per tenant per month of margin, tracked as a first-class KPI. The financial model treats support as a COGS (cost of goods sold) line at 10 minutes per tenant per month (the automated target state); Section 9.3 reconciles both views into a gross-margin band.
8.7 Deployment Options
Exactly two standard deployment paths are offered, both fully managed by IT Pro Partner:
- Option A - ITPP-INFRA Shared. Scirium runs on the existing netcup RS 4000/2000 servers alongside IT Pro Partner's own operations, backed by the same Wasabi S3 backup pipeline that powers ITPP production. Lowest cost and fastest start; the standard choice for the multi-tenant fleet and for most SMB tenants.
- Option B - Dedicated. Dedicated netcup or Hetzner instances with a dedicated S3 bucket, fully managed by ITPP. For tenants that demand physical separation (compliance-sensitive buyers, Enterprise tier, or Lane C GPU hosting) or for the fleet at scale.
Shared responsibility is explicit and identical in both paths: ITPP manages everything below the application layer (servers, Docker, TLS (Transport Layer Security), Postgres, backups and restore verification, monitoring, DLP infrastructure); the customer owns their documents and how they use the assistant.
9. Financial Model
9.1 Assumption register
Every figure in this section traces to one of these assumptions; items marked GUESS are estimates with no empirical basis yet and are the first things a pilot should measure.
| ID (identifier) | Assumption | Value | Basis |
|---|---|---|---|
| A1 | Blended engineering rate, loaded | $100/hr | v1 figure, retained |
| A2 | Principal/founder rate, loaded | $150/hr | GUESS. Opportunity cost of principal time on billable MSP work |
| A3 | Technical staff rate, loaded | $85/hr | GUESS. Loaded cost of ITPP technician doing onboarding and pilot setup |
| A4 | Tier mix | 60% Starter / 30% Business / 10% Enterprise | v1 figure, retained (conservative) |
| A5 | Queries per tenant per month | 4,000 | GUESS. No usage data exists; drives LLM COGS only, which is immaterial |
| A6 | Marginal LLM cost | $0.50 per 1,000 queries | v1 figure, retained. DeepSeek V4 Flash via LiteLLM |
| A7 | Warm pool depth | 12 tenants | GUESS. Existing ITPP MSP relationships assumed to yield 12 warm wins before acquisition goes cold |
| A8 | Warm pilot conversion | 80% | GUESS |
| A9 | Cold pilot conversion | 50% | GUESS. Unvalidated category, no reference class |
| A10 | Monthly churn | 3% base / 5% stress | v1 figure, retained. Unvalidated; no cohort data |
9.2 Build cost: $167K (reconciled)
The financial remediation section originally computed $105,300 (780 rescoped hours at +35% contingency), but that corrected only the M365 connector and missed 360 hours of new v2 work itemized by the technical team. The technical build table is authoritative: 1,235 hours of component work plus 432 hours of contingency at +35% equals 1,667 hours at $100/hr = $166,700, approximately $167K. The range reflects the M365 connector band (250 to 300 hours) and the contingency band (30% to 40%): $157K to $176K (low 1,210 hours at 30% = 1,573 hours = $157,300; high 1,260 hours at 40% = 1,764 hours = $176,400).
Component hours (v1 to v2): M365 connector 145 to 275; ingestion pipeline 70 to 80; RAG retrieval 90 unchanged; multi-tenancy 50 to 60; Rocket.Chat integration 70 unchanged; runtime DLP 0 to 90; Rocket.Chat DLP app 0 to 50; LLM lane routing 0 to 60; ops automation 0 to 160; auth/SSO 70 unchanged; admin UI (user interface) 90 to 110; testing and deploy 90 to 120. Subtotal 675 to 1,235; contingency +432; total 1,667.
The contingency is justified: it carries ACL mapping against real SharePoint permission structures, DLP false-positive tuning, and the unverified Rocket.Chat Apps-Engine hook behavior under the MIT fossify build. The v1 range's $45K low end is struck. Every payback figure uses the $167K figure.
9.3 COGS and the gross-margin band
The v1 marginal-cost analysis survives review intact: LLM inference is near free at this query volume. v1 erred in calling $7 per tenant per month the whole of COGS; support labor is a cost of goods, not overhead, because it scales with tenant count.
COGS per tenant per month: LLM inference $2.00 (A5 x A6); Rocket.Chat workspace plus MongoDB share $6.00 (GUESS); Postgres/pgvector storage plus embedding refresh $2.00 (GUESS); backups and object storage $1.50 (GUESS); tier-1 support labor $14.45 (GUESS, 0.17 hrs/mo at A3); monitoring share $0.55 (GUESS). Total $26.50. Blended ARPU is $469.10; gross profit is $442.60 per tenant per month. Gross margin is a band, never an unconditional figure: 94.4% at the 10-minute support target state, 88.4% at 30-minute stress, and roughly 62-65% at the 1.9 support hours per tenant per month the v1-era ops model implies. The 98% claim from v1 is dropped.
Technical's fully-loaded per-tenant view (~$297 per tenant per month at 48 tenants, including fleet engineering share) is a stricter all-in definition than COGS and puts the all-in contribution margin near 34 to 37 percent at the v1 pricing mix (Section 8.6); the COGS basis above feeds LTV and breakeven. Financial's verdict stands: even at triple support load the product remains high-margin. Support load is not the thesis risk; churn and CAC are - but support hours are a first-class KPI, because every 0.5 hours removed is $50 per tenant per month of margin.
9.4 Honest CAC (bottom-up) and the sales-capacity constraint
v1's $1,000 CAC counted no labor and no non-converting pilots; it was an assertion, not a calculation. Honest CAC is (cost of every acquisition attempt) / (conversion rate) + (post-sale onboarding cost of the win) + (cash outlay), which loads failed pilots onto the winners.
| CAC basis | Value | Multiple of v1 claim | CAC payback (months of gross profit) |
|---|---|---|---|
| v1 claimed | $1,000 | 1.0x | 2.3 |
| Mature motion (target state) | $2,053 | 2.1x | 4.6 |
| Warm (ITPP relationship) | $3,088 | 3.1x | 7.0 |
| Cold (no relationship) | $6,205 | 6.2x | 14.0 |
The warm build: 15.5 hours per attempt at $150/$85 loaded rates equals $1,610 per attempt; divided by 80% conversion it loads the 1-in-5 failed pilot to $2,012.50, plus post-sale close, onboarding (7.0 technician hrs), and training (3.0 technician hrs) equals $3,087.50. The cold build: 23.0 hours per attempt divided by 50% conversion, longer onboarding, and a $400 cash outlay (GUESS) equals $6,205. The mature build: 10.0 hours per attempt at $150/hr plus a $40 cash outlay per attempt (GUESS), at 75% conversion, equals $2,053.33 ((1,500 + 40) / 0.75). The review predicted CAC 3 to 5x higher; bottom-up lands at 3.1x warm and 6.2x cold. The review's "payback 12 to 15 months" reconciles as the CAC payback on cold acquisition (14.0 months), not the build-cost payback.
The sales-capacity constraint (a consequence of honest CAC): acquisition is rate-limited by principal and technician availability. Warm wins cost 7.1 principal hours plus 23.8 technician hours each; cold wins cost 11.5 plus 48.0. At 40 principal-hours plus 80 technician-hours per month, the ceiling is 3.4 warm wins per month (technician hours bind first) and 1.7 cold wins per month. This falsifies the v1 Aggressive scenario, which requires 13 adds in month 12 (roughly 620 technician hours).
9.5 LTV and LTV:CAC
LTV is gross profit per tenant per month divided by monthly churn, the standard steady-state formula, undiscounted (generous: at 3% churn the average tenant life is 33 months, and money that far out is worth materially less than face value). LTV is $14,753 at 3% churn and $8,852 at 5% churn.
| CAC basis | LTV:CAC @ 3% churn | LTV:CAC @ 5% churn | Verdict |
|---|---|---|---|
| v1 claimed $1,000 | 14.8:1 (the old headline) | 8.9:1 | Not real. Assumes free labor and zero failed pilots; retained only as the arithmetic artifact it is |
| Mature motion $2,053 | 7.2:1 | 4.3:1 | Healthy. This is the target state |
| Warm $3,088 | 4.8:1 | 2.9:1 | Acceptable at 3%. Below the 3:1 floor at 5% |
| Cold $6,205 | 2.4:1 | 1.4:1 | Fails the 3:1 floor at both churn rates |
The honest band is 4.8:1 to 7.2:1 at 3% churn, which brackets the review's expected 4 to 7:1. At 5% churn the band is 2.9:1 to 4.3:1, and cold at 1.4:1 is value-destroying. Spending ceilings: at 3% churn the 3:1 minimum-viable CAC ceiling is $4,918 (4:1 = $3,688; 7:1 = $2,108); at 5% churn the 3:1 ceiling is $2,951. Cold outbound CAC of $6,205 exceeds the 3:1 ceiling even at 3% churn: cold outbound acquisition is not viable at any modeled churn rate. The business is only viable on warm, referral, and productized-inbound acquisition. That is a strategy finding, not just a number.
Churn sensitivity: warm LTV:CAC is 7.2:1 at 2.0% monthly churn, 5.7:1 at 2.5%, 4.8:1 at 3.0%, 4.1:1 at 3.5%, 3.6:1 at 4.0%, 2.9:1 at 5.0%. The critical threshold is roughly 3.5% monthly churn on warm acquisition; above roughly 4.5% the warm motion drops under the 3:1 floor. Measuring actual churn in the pilot cohort is the highest-value information the business can buy, and it is cheap to buy.
9.6 Twelve-month ramp, net of churn
v1 reported $52.7K / $107.6K / $198.9K as 12-month revenue with churn explicitly excluded; those are gross bookings under an assumption that no tenant ever cancels. The rebuild applies a monthly cohort decay (ending base = (opening base x (1 - churn)) + gross adds, revenue recognized on the ending base at $469.10 ARPU, churn applied to the opening base only). The v1 monthly add schedules were not published and are reconstructed to land on v1's stated month-12 tenant counts; that reconstruction is an inference, not a v1 quotation.
| Scenario | Month-12 tenants (gross) | Month-12 @3% | Month-12 @5% | v1 "12-mo revenue" | v2 net rev @3% | v2 net rev @5% |
|---|---|---|---|---|---|---|
| Conservative | 22 | 19.8 | 18.5 | $52.7K | $43.7K | $41.4K |
| Realistic | 48 | 42.9 | 40.0 | $107.6K | $99.3K | $94.1K |
| Aggressive | 90 | 80.2 | 74.5 | $198.9K | $190.3K | $180.1K |
| Capacity-constrained (new) | 26 | 22.0 | 19.8 | not modeled | $72.2K | $67.4K |
Net first-year revenue is 7.7% lower at 3% churn and 12.5% lower at 5% than gross bookings in the Realistic scenario (Conservative: 17.1% and 21.4% lower; Aggressive: 4.3% and 9.5%). Exit MRR (monthly recurring revenue): $9,289 (Conservative @3%), $20,143 (Realistic @3%), $37,638 (Aggressive @3%), $10,342 (Capacity-constrained @3%), an exit ARR of $124,104.
The capacity-constrained scenario is the recommended planning case. Given the 3.4 warm wins per month ceiling and a warm pool of only 12, neither the Realistic nor the Aggressive schedule is executable with current staffing. Its gross adds (1, 2, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2) front-load the warm pool then throttle to the cold-acquisition ceiling. At 3% churn the ending base reaches 22.05 tenants by month 12, with MRR of $10,342 and cumulative net revenue of $72,151; at 5% churn it ends at 19.81 tenants and $67,378. Year-one CAC spend is $123,920 (roughly 1.7x the net revenue it produces), and the scenario crosses operating breakeven (12 tenants) in month 6 at 3% churn. For contrast, the Realistic scenario's year-one CAC spend is $260,430, 2.6x the net revenue it produces and 1.6x the entire funded build cost; v1's model contained no such line, the largest single omission in the original financials. The Realistic case is achievable only with a dedicated sales and onboarding hire (roughly $6,000 to $9,000 per month) not in the $5,310 opex. The two cannot be mixed.
9.7 Opex reconciliation
v1's $4,000 per month could not be reconciled against its own $3,500 engineering line. Reconciled lines: engineering retainer $3,500 (35 hrs/mo at A1); shared infrastructure $95 (GUESS); backup and object storage baseline $45 (GUESS); tooling and licenses $120 (GUESS); product management (principal, 8 hrs/mo at A2) $1,200 (omitted in v1); admin/finance/insurance allocation (errors and omissions (E&O) insurance share, accounting, legal) $350 (omitted in v1). Reconciled fixed opex: $5,310 per month, versus v1's $4,000, a gap of +$1,310 (+32.8%). v1's figure is internally consistent only if product management and administration are valued at zero, the same free-founder-labor error that produced the $1,000 CAC. Annual fixed opex is $63,720, excluding any dedicated sales headcount (acquisition labor is costed inside CAC; a dedicated hire adds $6,000 to $9,000 per month).
9.8 Breakeven
Two distinct breakevens, kept separate because v1 blurred them. Steady-state operating breakeven (no growth spend): $5,310 / $442.60 = 12.0 tenants (v1 said ~9; its figure followed correctly from its own $4,000 opex, only the input was wrong); contribution per tenant past breakeven is $442.60. Cash-flow breakeven (growth spend included) is the operationally relevant figure and v1 omitted it: at 2 monthly adds the business needs 25.9 tenants at warm CAC (40.0 at cold); at 3 adds, 32.9 (54.1 cold); at 4 adds, 39.9 (68.1 cold). Adding 4 cold tenants per month requires 68 existing tenants just to stay cash-neutral, and at 5% churn that base is not reachable at that add rate.
The structural finding at 5% churn. Steady-state tenant count converges to monthly adds / churn: at 2 adds per month and 3% churn, 66.7 tenants, monthly gross profit $29,507, less opex $5,310 and CAC, nets +$11,787 per month (cold CAC) or +$20,090 (mature CAC). At 5% churn, 40.0 tenants, monthly gross profit $17,704, less opex and cold CAC, nets -$16 per month: at 5% monthly churn on permanently cold acquisition, the business converges to exactly zero net cash flow. It runs forever, funds its own replacement churn, and never returns the build cost. Not a bankruptcy scenario; a treadmill scenario, arguably worse because it consumes years before the failure becomes obvious. The escape is churn below 3.5% or CAC productized toward the mature figure. Both, ideally.
9.9 Payback
Two payback questions, reported separately, both on the corrected $167K build.
Build-cost payback (gross profit less opex versus the build; CAC excluded as discretionary growth investment). The model's sensitivity analysis shows payback is nearly insensitive to build cost (it moved only ~2 months across a $31K swing in the original computation), so the correction from $105,300 to $167K adds roughly two months to the base case. At the corrected build: approximately 20 months at Realistic and 3% churn (extrapolated estimate, labeled as such), against technical's range of ~18 to 22 months at the recommended $499 price floor and ~29 to 37 months at v1 pricing; the capacity-constrained planning case lands at the upper end of the v1-pricing range (about 30 months at 3% churn). This is a two to three year payback managed-software business, not a ten-month near-zero-marginal-cost software business.
| Payback basis | Figure | Basis |
|---|---|---|
| Build-cost, Realistic, 3% churn | ~20 months (extrapolated estimate; ~22 months on the assembled model) | $167K build against gross profit less opex |
| Build-cost, $499 price floor | ~18 to 22 months | Section 7.3 lever; contribution ~$202/tenant/mo |
| Build-cost, v1 pricing | ~29 to 37 months | Technical range (Section 8) |
| Build-cost, capacity-constrained, 3% churn | ~30 months | Upper end of the v1-pricing range |
| Fully loaded (build + opex + CAC) | 38 to 64 months | 38 at Realistic/3% with CAC maturing; 64 if CAC stays cold |
These are outputs of the month-by-month cash-flow model; the static tables in Sections 9.1 to 9.8 do not contain the full monthly simulation, so these figures are not independently derivable from them (the model workbook is available on request).
Fully-loaded payback (build plus opex plus honest CAC, the strictest test): 38 to 64 months, driven by whether CAC matures after year one (38 months at Realistic, 3% churn) or stays at cold acquisition cost (64 months). Unchanged by the build-cost correction because it is CAC-dominated: year-one CAC spend of $124K to $260K ranges from 0.7x to 1.6x the build cost itself. At 5% churn with CAC staying cold, fully-loaded payback never arrives (the Section 9.8 treadmill). Per-tenant CAC payback: 7.0 months warm, 14.0 months cold, 4.6 months mature; v1's "2.3 months per tenant" was correct on a $1,000 CAC and meaningless once CAC is honest.
9.10 Revised verdict
GO, with conditions, and for a different reason than v1 gave. What survived review unchanged: marginal cost is negligible; gross profit per tenant is about $443 per month; and the $469.10 blended ARPU is conservative and retained. What broke and is now corrected: CAC was understated 3.1x (warm) to 6.2x (cold), and cold outbound is not viable at any modeled churn rate; the ramp was gross, not net (net first-year revenue is 7.7% lower at 3% churn and 12.5% lower at 5% in the Realistic scenario); opex was understated 33%; build cost was understated 146% (was $68K, now $167K); payback was understated (about 20 months build-cost at Realistic and 38 to 64 months fully loaded, versus 10 to 13 claimed); and the Aggressive scenario is not executable under the sales-capacity ceiling.
The three conditions the numbers impose:
| Condition | Threshold | Why it is the threshold |
|---|---|---|
| Measure real churn in the pilot cohort before scaling spend | At or below 3.5%/mo | At 3.5% warm LTV:CAC is 4.1:1; above roughly 4.5% the warm motion drops under the 3:1 floor |
| Productize the acquisition motion inside year one | CAC trends from $3,088 toward $2,053 | Fully-loaded payback is 38 months with maturing CAC versus 64 months without, at 3% churn |
| Do not fund cold outbound acquisition | Cold CAC $6,205 exceeds the 3:1 ceiling of $4,918 at 3% churn | Warm, referral, and productized inbound only |
The recommendation: fund the $167K build against the capacity-constrained ramp, and treat measured churn in the first pilot cohort as the gate on all further growth spending.
10. Legal & Compliance
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
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.
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.
10.2 Advisory-only posture, available at every tier
The legal and compliance package is advisory-only and is offered as guidance and template documentation across all pricing tiers; it is not gated behind the Enterprise tier, and no tier is sold as "compliant" or "certified" on the strength of a marketing claim. Every tenant receives the same baseline no-PHI acceptable-use policy, the same limitation-of-liability framing, and access to the same DPA template. Enterprise-tier customers additionally receive a signed, negotiated DPA and dedicated-instance options, but the underlying legal posture (no PHI, no BAA (business associate agreement), self-hosted control, advisory-only terms) is identical across tiers.
10.3 ToS (terms of service)/MSA (master services agreement) and limitation of liability
Scirium is offered under a ToS/MSA package that is explicitly advisory-only: proposed templates to be reviewed, finalized, and issued by qualified counsel before any customer signs a live agreement. Key terms the finalized ToS/MSA should address: scope of service (self-hosted, white-label, multi-tenant knowledge-assistant chat over customer-provided documents with grounded, cited answers); customer ownership of its documents, chat content, and outputs; explicit exclusion of PHI and other prohibited data categories; SLA terms by tier; term, termination, and data-return/deletion obligations on offboarding; and no unilateral material change to the no-PHI restriction or the DPA without customer notice.
The MSA should include a standard limitation of liability structure, to be finalized by counsel: a liability cap limited to fees paid in the preceding 12 months (or a similarly-scaled fixed cap), except for carved-out categories (breach of confidentiality, gross negligence or willful misconduct, and express indemnification obligations); exclusion of consequential damages; no warranty of fitness for a specific regulated use (the service is not warranted as fit for use with PHI, regulated health data, or any use requiring a BAA); and an AI-output disclaimer: answers are grounded and cited but AI-generated, and the customer is responsible for independent verification before relying on any answer for a consequential business, medical, legal, or financial decision. Enforceability and exact cap amounts depend on jurisdiction and must be set by counsel.
10.4 Acceptable Use Policy: no PHI
The AUP (acceptable use policy) is a hard, contractual restriction, not just a technical guardrail, and it applies at every tier: customers may not ingest, upload, or otherwise introduce into Scirium any Protected Health Information as that term is understood under applicable health-privacy frameworks (patient records, diagnoses, treatment notes, medical record numbers, or similarly sensitive health identifiers), nor any other data category the customer is not permitted to disclose to a third-party processor. The AUP is the legal counterpart to the technical PHI controls: it puts the customer on contractual notice that the product is not designed, warranted, or licensed for PHI use, and that violation is a breach of the agreement independent of whether the technical filter catches every instance. The customer is responsible for configuring which document libraries are connected and for ensuring PHI is excluded before connection. Detected or reported PHI ingestion triggers immediate quarantine, customer notification, and remediation; repeated or willful violation is grounds for suspension or termination. This AUP is what allows Scirium to serve healthcare-adjacent verticals (a dental or orthodontic practice's non-clinical operational content, billing policy, HR and handbook material) without taking on the regulatory posture of a healthcare data processor.
10.5 Data Processing Addendum
A DPA template is available to any customer that requests one, at any tier, covering: roles (customer as data controller for its own documents and users' chat content; Scirium as data processor for the limited purpose of providing the service); scope of processing (ingestion, indexing, retrieval, and generation strictly within the customer's own tenant and channel scopes, consistent with the hard multi-tenancy invariant); a defined, disclosed sub-processor list (infrastructure hosting, the LLM vendor routed through the internal proxy, backup/object storage) with advance notice of material changes; data location and residency per the deployment option the customer selects (shared ITPP-managed estate or dedicated single-tenant instance), supporting regional routing commitments where required; security measures (encryption in transit and at rest, tenant isolation, signed internal service calls, audit logging of every question and answer); deletion and return on termination within a defined window with confirmation; and a defined breach/incident notification timeline with audit or attestation rights scaled to tier.
10.6 LLM vendor DPA
This is the legal counterpart to the three-lane routing architecture in Section 8.3 and directly addresses the review's shared flaw about external LLM data handling. The commitments below must be reflected in the actual contractual terms with whichever LLM vendors are in the routing chain, not just asserted in marketing copy: a no-training commitment (customer prompts and outputs are not used to train, fine-tune, or improve the vendor's models); a no-retention or minimal defined retention commitment (ideally zero retention beyond what is operationally required, or a short defined and disclosed period for abuse-monitoring purposes only, with deletion after that window); regional routing (where a customer's DPA or regulatory context requires it, the routing layer must direct that customer's LLM calls to a model or endpoint in a committed region, and the vendor DPA must reflect where processing actually occurs); fallback-chain disclosure (the same commitments must apply to every vendor in the fallback chain, and the DPA or an attached exhibit must list every vendor that can plausibly process a given customer's data); and the structural point that no PHI reaches the LLM layer because the AUP and technical controls block it before it enters the pipeline, so the LLM vendor DPA does not need to be, and should not be represented as, HIPAA-capable. If the architecture team changes a vendor or fallback chain, the LLM vendor DPA exhibit must be updated before the change ships.
10.7 HIPAA / BAA posture
Deliberately explicit and not softened in customer-facing material: Scirium is not a HIPAA covered entity (it does not provide healthcare treatment, payment, or health plan operations). Scirium does not sign Business Associate Agreements: because the product's contractual and technical design explicitly excludes PHI from the service, Scirium does not position itself as a HIPAA business associate, and a BAA is only appropriate where a vendor is knowingly handling PHI on behalf of a covered entity. A dental, orthodontic, medical-adjacent, or similar practice can use Scirium for non-clinical operational knowledge (employee handbook, billing policy and procedure, IT help, front-office training material) but must not connect any library or content source containing patient records or other PHI. This is a hard boundary of the product, not a tier-based upsell: "upgrade to get HIPAA support" is explicitly not an option. If a prospective customer requires a BAA or PHI handling as a condition of purchase, that customer is out of scope for Scirium as currently designed. This posture is the direct legal expression of the product's "permanently out of scope: patient records, PHI, HIPAA scope" hard rail; legal posture and product architecture agree by design.
10.8 Data protection, jurisdiction, and liability summary
Data location is known and disclosed at contracting time per deployment option; the only data flow that leaves the controlled estate is the LLM inference call itself, and the LLM vendor DPA is the mechanism that pins down where that hop occurs and under what retention terms. No claim of specific regulatory certification is made: this proposal does not claim SOC 2 (System and Organization Controls 2), ISO (International Organization for Standardization) 27001, HIPAA, or GDPR (General Data Protection Regulation) adequacy has been obtained. Indemnity, to be finalized by counsel: Scirium indemnifies the customer against third-party claims that the core, unmodified platform infringes third-party IP (intellectual property), subject to standard exclusions; the customer indemnifies Scirium against claims arising from its own content, its breach of the AUP (in particular PHI ingestion), and misuse of AI-generated outputs; and because the Scirium brand itself is cleared only at the basic-search level, any reseller or white-label agreement executed before a professional trademark opinion is obtained should include a clear allocation of risk and, ideally, a right to rename or rebrand on notice. The operating entity should carry technology E&O and cyber liability coverage sized to the customer base. Because PHI is contractually and technically excluded, the liability and indemnity structure is deliberately not sized for HIPAA breach exposure.
11. Team & Execution
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 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.
12. Roadmap & v1-to-v2 Scope
12.1 What product v1 is
Product v1 is the answer engine plus the safety rails, and nothing else. The message flow is eight steps: staff sends a message mentioning the agent (or DMs it); chat-layer DLP inspects pre-persistence (block, redact, or allow; on block the message is never written); Rocket.Chat fires a signed, HMAC-authenticated webhook to the orchestrator; the orchestrator resolves tenant, channel, agent, and scope in one request context and dedupes on message id; retrieval runs pgvector semantic search over the channel's namespace, always filtered by tenant and scope, falling back to Microsoft Graph search below threshold; orchestrator-boundary DLP inspects the question plus retrieved context plus history and fails closed; prompt build and lane-aware dispatch with no cross-lane fallback; the answer posts back as the agent bot with inline citations re-attached locally from Postgres. v1 hard behaviors: never fabricate (below-threshold retrieval returns "I could not find an answer" with no sources), every answer carries citations, runtime DLP at both layers failing closed and non-disableable at the orchestrator, allowlisted ingestion with the pre-index PHI filter retained, and a full audit log of every question, answer, and DLP event.
12.2 Built versus to build
| Component | Status | Disposition |
|---|---|---|
| Product model and data architecture | Settled, 3 design docs committed | Done |
| Data model (tenants, channels, agents, kb_scopes, documents, chunks, messages, users, dlp_events) | Spec'd, not built | Build |
| Orchestrator (FastAPI, tenancy, retrieval, LLM client, lane routing) | Not built | Build |
| Postgres + pgvector schema plus RLS (row-level security) | Spec'd, not built | Build |
| Rocket.Chat workspace and bot integration | Phase 0 checklist spec'd, not built | Build |
| Rocket.Chat DLP app (Apps-Engine) | New in v2, not spec'd | Build |
| Presidio deployment, recognizer tuning, contextual rules | New in v2, not spec'd | Build |
| M365 connector (Sites.Selected read) | Spec'd, not built | Build, re-estimated |
| White-label FOSS (free and open source software) rebrand (fossify build) | Phase 1 gate, not started | Build |
| Auth (Hexclave/Stack Auth, Entra OIDC) | Partially existing on app3 | Integrate |
| IaC provisioning and fleet automation | New in v2, not spec'd | Build |
| Lane C GPU inference host | New in v2 | Provision when the first Lane C tenant signs |
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.
12.4 Ops automation before tenant five
The rule from Section 8.6: no per-tenant action may be manual, and all fleet automation (provisioning, de-provisioning, upgrades, backup restore verification, monitoring, log aggregation, secrets, runbooks, 160 hours of build) must be in place before the fifth tenant, because manual steps multiplied by the fleet is the ops treadmill that silently destroys margin.
12.5 v2 risk-tiered capabilities
The v2 roadmap adds risk-tiered "do" capabilities, ordered by write risk, none of which ever unlock patient/PHI scope or autonomous destructive action: reporting (structured extraction, SQL (Structured Query Language) aggregation, chart render; zero new write risk, auto-approved, the recommended first v2 ship); content generation (drafts, summaries, boilerplate; drafts only, with DLP applied to generated output too); housekeeping (move, rename, delete-to-recycle; destructive, propose-then-approve-then-audit, with a mandatory undo path); integrations (Graph delegated sendMail, calendar, webhooks; external side effects, approval required, with DLP inspecting outbound payloads because an integration is a new egress path); and design and brand (template render, image gen; template-driven only, because raw image generation garbles text). Reliable aggregation comes from structured extraction at index time plus a SQL tool, not from better prompting. Permanently out of scope: patient records, PHI as a system of record, HIPAA scope, clinical or radiographic image analysis (a separate FDA (Food and Drug Administration)-regulated product class), and autonomous destructive actions.
12.6 Gating items before the first non-pilot customer
(1) Fail-closed DLP test passing in CI, both layers, and the Phase 0 Apps-Engine spike passed; (2) adversarial cross-tenant isolation test passing in CI; (3) automated backup restore verification proven on a scratch host; (4) DPA in force with any Lane B vendor, with no-training and region pinning evidenced; (5) the MIT fossify white-label build produced in CI, never the stock EE image; (6) the 40-hour M365 connector spike returning a written go on the 275-hour estimate; (7) legal review of the customer-facing PHI language; and (8) professional trademark clearance obtained before any reseller or white-label agreement or paid launch.
13. Risks & Mitigations
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Trademark: the "Cirium" phonetic neighbor | Low | High | Scirium is materially lower-risk than the retired v1 codename, but Cirium (LexisNexis/RELX aviation data and analytics, AI-adjacent) is a real residual risk, unprofessionally assessed. Professional clearance opinion required before trademark filing, any reseller or white-label agreement, or paid launch; reseller agreements carry a right to rename on notice until then |
| DLP Layer 1 hook behavior unverified (R8) | Medium | High | Rocket.Chat Apps-Engine pre-send hook behavior under the MIT fossify build and for REST-API messages is load-bearing for chat-layer DLP. Mandatory Phase 0 spike; DLP not declared production-ready until it passes; Layer 2 orchestrator DLP remains non-bypassable regardless |
| Churn above the critical threshold | Medium (unvalidated) | Critical | The model hinges on churn at or below ~3.5% monthly; above ~4.5% warm LTV:CAC drops under the 3:1 floor, and at 5% on permanently cold acquisition the business converges to zero net cash flow (the treadmill). Measure churn in the pilot cohort before scaling spend; activation rate, weekly active staff, and queries-per-active-user are the leading indicators |
| Cold outbound CAC not viable | Certain | High | $6,205 exceeds the $4,918 3:1 ceiling at 3% churn. Warm, referral, and productized-inbound acquisition only; no cold-outbound budget |
| Support hours (the gross-margin swing variable) | Medium | Medium | 1.9 hrs/tenant/mo implies ~62-65% COGS-basis margin; 10 min implies 94.4%. Every 0.5 hrs removed is $50/tenant/mo. Tracked as a first-class KPI; automation, self-serve admin tooling, better DLP tuning defaults, runbook-driven tier-1 |
| Pricing: $199 tier cannot carry fleet cost | Medium | Medium | At v1 pricing the fully-loaded all-in contribution is near 34-37%. Strategic lever to retire $199 and enforce a $499 floor (contribution ~$202/tenant/mo, breakeven 22-23 tenants); base model stays conservative at $469.10 |
| Sales-capacity ceiling | Certain | Medium | 3.4 warm wins/mo max; the Aggressive 90-tenant case is not executable. Capacity-constrained ramp as the base plan; dedicated hire at +$6-9K/mo only after Gate 2 and metric thresholds clear |
| Hallucination (the risk that kills the product) | Medium | High | Never-fabricate rail, mandatory citations, "I could not find an answer" fallback, DLP on generated output; zero confirmed fabricated answers is a stop-and-fix event |
| Cross-tenant or cross-channel leakage | Low | Critical | Schema constraints, RLS, vector namespace filtering, physical chat separation, HMAC auth, adversarial isolation test in CI gating deployment |
| Onboarding backlog turning wins into churn | Medium | High | Cap monthly signings at proven onboarding capacity; activation rate is the real growth metric; runbook proven at Gate 1, executed by a non-builder at Gate 2 |
| Channel signed but not selling | Medium | Medium | Track producing partners, never signed partners; certification call plus branded demo tenant required before a partner counts |
| M365 connector fragility | Medium | Medium | 275-hour planning midpoint, 40-hour de-risking spike with written go/no-go, delta sync, backoff, Graph search fallback |
| Rocket.Chat licensing in resale | Low | High | MIT fossify FOSS-only build in CI, never the stock EE image |
| Competition moving downmarket | Medium | Medium | Lead with brand, infrastructure control, and isolation; assume the price floor for generic knowledge Q&A moves toward zero |
14. Change Summary v1 -> v2
| # | Superseded v1 figure or position | v2 value or position |
|---|---|---|
| 1 | Build cost ~$68K (range $45K-$100K) | ~$167K (1,667 hrs at $100/hr incl. +35% contingency; range $157K-$176K). Build cost understated +146% (was $68K, now $167K) |
| 2 | M365 connector 145 hrs, no contingency | 275-hr planning midpoint (250-300 range), 40-hr de-risking spike, +35% contingency across all build hours |
| 3 | CAC ~$1,000 | $3,088 warm / $6,205 cold / $2,053 mature target (CAC payback 7.0 / 14.0 / 4.6 months) |
| 4 | LTV:CAC ~14:1 | 4.8:1 warm @3% churn; 2.9:1 warm @5%; 7.2:1 at mature CAC @3%. The 14.8:1 headline is an arithmetic artifact of the fictional $1,000 CAC, labeled as such |
| 5 | Opex $4,000/mo | $5,310/mo reconciled (+32.8%; the gap was PM (product management) and admin/insurance valued at zero); annual $63,720 |
| 6 | Breakeven ~9 tenants | 12 tenants steady-state; 26 to 40 tenants cash-neutral while growing |
| 7 | 12-month revenue $52.7K / $107.6K / $198.9K (gross bookings, churn excluded) | Net of churn @3%: $43.7K / $99.3K / $190.3K; @5%: $41.4K / $94.1K / $180.1K. Recommended planning case: capacity-constrained, $72.2K net @3% with $123.9K year-one CAC spend |
| 8 | Full payback ~10-13 months | ~20 months build-cost at Realistic @3% (extrapolated estimate); ~18-22 months at the $499 floor; ~29-37 months at v1 pricing; 38 to 64 months fully loaded (CAC-dominated) |
| 9 | Gross margin 95-98% | A band, never a single figure: 94.4% at the 10-min support target state, 88.4% at 30-min stress, ~62-65% at the 1.9-hr support reality. Support hours are the swing variable and a first-class KPI |
| 10 | Blended COGS ~$7/tenant/mo | $26.50/tenant/mo including support labor; per-tenant fully-loaded cost ~$297/mo at 48 tenants (technical view, Section 8.6) |
| 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) |
15. Sources & Open Questions
15.1 The [to verify] register (consolidated)
Engineering and architecture
- Rocket.Chat Apps-Engine
IPreMessageSentPreventbehavior on Rocket.Chat 7.4.0 under the MITfossifybuild, and whether app hooks fire for REST-API messages. Load-bearing for DLP Layer 1; mandatory Phase 0 spike before DLP is declared production-ready. - LiteLLM
pre_callPresidio guardrail behavior on the deployed admin-ai version (reported issues with redacted content propagating to the effective upstream payload). - Presidio NER memory profile under load (1.5 to 2.5 GB per analyzer container) and Spanish-language model availability and quality.
- Full date-of-birth blocking classification under HIPAA, and the customer-facing PHI language [with counsel].
- Current DeepSeek enterprise/API terms (may differ from the consumer privacy policy).
- Azure OpenAI modified-abuse-monitoring eligibility, approval timeline, and current per-token pricing.
- Lane C open-weight model selection and license terms for commercial resale; Lane A versus Lane C answer-quality comparison on the Phase 0 evaluation set.
- Hetzner GEX44 pricing and VAT treatment. Host density of 10 to 12 tenant stacks per 64 GB host [load test at 3 tenants].
Market and competitors
- Precise global and US knowledge-worker counts (aggregate estimates only, directional).
- Glean pricing (~$50 to $75 per seat, ~100-seat minimum) and the $300M ARR milestone reached in late May 2026 (third-party, TechCrunch; up from the $200M ARR announced 8 December 2025 and cited in Section 4.2). Glean does not publish list pricing.
- Guru per-seat pricing and 10-seat minimum (third-party; Guru no longer publishes pricing) and Guru white-label/custom-domain limitations (competitor-authored comparisons).
- Moveworks current list pricing (not published). Coveo and Dust white-label availability.
- Knowledge-worker search-time studies (McKinsey, IDC, Deloitte) - directional, frequently recycled.
Legal and brand
- Cirium's registered-mark status in the software/data-services classes; professional clearance opinion required before filing, reseller agreements, or paid launch. Domain and social-handle availability for the Scirium name.
Financial assumptions marked GUESS (A2, A3, A5, A7, A8, A9, A10)
- Principal rate $150/hr, technician rate $85/hr, queries 4,000/tenant/mo, warm pool 12, warm conversion 80%, cold conversion 50%, monthly churn 3%/5%, plus COGS line items, the cold-CAC cash outlay of $400, and mature-motion conversion of 75%. These are the first things a pilot should measure.
15.2 Sources
- This document assembles: the marketing remediation section (market, competitors, positioning, white-label wedge, GTM (go-to-market)), the technical remediation section (architecture, DLP, LLM routing, connector, ops, build cost), the financial remediation section (authoritative on revenue and unit economics), and the legal remediation section (trademark, ToS/MSA, AUP, DPA, BAA posture), all dated 2026-08-17; the v1 proposal (2026-08-16, team and product context; any v1 figure superseded by the remediation is replaced per Section 14); and the internal critical review (7 flaws, 7 conditions, CONDITIONAL GO).
- Vendor-confirmed sources cited in the market section: Notion SharePoint and OneDrive AI Connector documentation and 2.51 release notes; Glean deployment documentation and press releases (Series F, $200M ARR); ServiceNow and Moveworks acquisition announcements; Microsoft 365 Copilot pricing pages; Microsoft Copilot Studio customization documentation; Guru pricing page.
- Third-party, directional only: Glean and Guru pricing estimates (GoSearch, Onyx cost calculator, Workativ, Featurebase, Docsie); CAC benchmarks (Factors.ai, Digital Applied, SaaS Mag); US MSP population (Span Global Services).
End of proposal. Nothing in this document is legal advice; all legal, trademark, and regulatory conclusions require confirmation by qualified counsel before the underlying decisions are finalized.