Level 9 OS™: Operating Reality Report

Everything on this page is measured directly against the production database as of October 13, 2026. Nothing here is projected, rounded up, or aspirational. Where a number is a proxy rather than a direct measure, that is stated in the line itself.

• Usage source: route_view_events, a first party page view log written on every authenticated OS route, with role and impersonation flags. Impersonated sessions are attributed to the viewer, so internal staff numbers are slightly inflated and client numbers are not.
• Activity source: Row counts and created_at timestamps on the primary entity tables, filtered to trailing 30 days unless stated.
• Client denominator: Client accounts that own at least one active workspace, excluding seeded demo accounts. Dormant and historical logins are excluded from rates.
• Known distortion: Historical Asana imports inflate lifetime comment and task counts. Trailing 30 day figures are clean, lifetime figures are not.

Modules are ranked by trailing 30 day page views and distinct users. The right column is the honest verdict, not the roadmap position.

The honest summary

• The real product: Task lifecycle. Task detail, boards, dashboards, AI intake, and comments account for roughly 94 percent of all page views. Everything a client does, they do around a task.
• Genuine secondary use: Business Brain, Role Builder, Process Builder, and Sub-Accounts have real but small user bases, in the 18 to 29 client range each. These are onboarding artifacts more than daily tools today.
• Shelfware to either fix or retire: Saved Views (built, zero saved), Workspace Automations (2 rules total), Timeline, Cost Estimator, Communications Registry, Dial Tracker, and VA Brain chat. Each works, none has pull.
• Internal only workhorses: System Health, Audit Center, and Self Heal run continuously through 43 scheduled jobs. Low page views because they are automated, not because they are unused.

The production schema carries roughly 150 tables. These are the entities that matter for a commercial or investor conversation, with live row counts.

• Throughput: Tasks created, completed, active, overdue, parked, and waiting on client, per workspace, per VA, per PM, and platform wide.
• Time and utilization: Actual hours per task from Time Doctor, hours purchased, hours used, rollover, overage, and burn rate against the current billing cycle. Automatic alerts at 80 percent and 100 percent consumption.
• SLA and responsiveness: Time to first assignment, time to first action, time to completion, ageing, and breach flags against per priority thresholds. Stored on the task row as first_assigned_at and first_action_at.
• Margin: Base estimated hours vs client facing hours vs actual hours, category multipliers, margin delta in hours and dollars per task, rolled up per client and per PM.
• Quality and rework: Revision counts, QC checklist completion, estimation accuracy per VA, and delivery rate.
• Client health and sentiment: Composite health score per account plus nightly AI sentiment scoring of client comment tone, with retention risk analysis and weekly usage decline checks.
• Adoption: Route level page view logging with role and impersonation attribution, which is what this report is built on.
• Platform reliability: Invariant audits every 15 minutes, edge probes every 2 minutes, notification health checks, sync queue depth, error spike detection, and automated self healing runs every 10 minutes.

What is not tracked

• Revenue per account: Not stored. Hours are stored, pricing and invoices live outside the OS.
• Client outcome metrics: No leads generated, appointments set, or revenue influenced attribution back to delegated work.
• Session depth and dwell: Page views are logged, session duration and funnel completion inside the OS are not.

The closest things that exist

• Agency Operations Assessment: 11 submissions between June and July 2026. Captures self reported capacity, hours, and bottlenecks at the prospect stage. It is a marketing funnel artifact, it is not linked to the client account after they sign.
• First cycle hour allocation: The first client_hour_allocations row for an account is an implicit starting point, but it measures what was sold, not what the client was doing before.
• Health and sentiment history: Client health and sentiment are scored from the moment they are onboarded forward, so they show trend but no origin point.

The gap worth closing

A single onboarding baseline snapshot per account, storing self reported weekly hours on delegatable work, current cost of that work, current turnaround, and the top three bottlenecks, would let every dashboard in the OS render a credible before and after. It is a small table and one onboarding form, and it is the highest leverage missing data asset in the platform today.

Login rate

Roughly half of active client accounts touch the OS in a given week and about two thirds in a month. The remaining third are effectively running on email, SMS, and their PM, which is exactly the population that makes retention fragile because the relationship lives with a person rather than a system.

Top in-product client actions, trailing 30 days

The behavioral shape is clear. Clients use the OS as a request desk and a status window. They submit work, they watch it move, and they talk about it in the thread. They do not use it to plan, configure, or analyze.

What clients say on calls

This is qualitative and not stored in the database, so it is reported as observed themes rather than measured facts. It should be validated with a structured post call field before being used in any external material.

• Liked: Visibility without asking. One place to see every request, its status, and who has it. Task Intelligence turning a rough idea into a properly scoped brief. Seeing hours consumed against what they bought.
• Disliked: It is another login and another inbox on top of email and Slack. Notification volume before the digest first rework. Empty modules that ask for setup work with no immediate payoff, particularly SOPs and Roles. Confusion when subtask names appeared in notifications instead of the parent task.

How OS access is packaged

• Bundled, not sold separately: There is no entitlement, plan, or subscription table in the schema. OS access is provisioned by invite when an account is created, and every client engagement includes it. There is no code path that charges for it or gates it behind a tier.
• Invite only: No open registration. Access requires a valid invite token, and Team Members can only be invited from the parent client account.
• Shut off on cancellation: A revoke client access function exists and workspaces are archived rather than deleted. In practice the account goes dark and the history is retained internally. There is no read only alumni mode, no data export handoff by default, and no reason for a departing client to keep a relationship with the software.

Power users vs churned accounts

Stack

• Front end: Custom single page application. React 18, Vite 5, TypeScript, Tailwind. Not a white label, not a ClickUp or Notion wrapper. Installable progressive web app, no native mobile build.
• Back end: Managed Postgres with row level security on every table, roughly 150 tables, plus about 100 Deno edge functions and 43 scheduled jobs. Authentication, storage, and realtime are part of the same managed platform.
• Edge and domain: Cloudflare in front of the custom domain, with an edge monitor probing availability every 5 minutes.
• AI: A single gateway abstraction rather than a direct vendor dependency, used for intake refinement, briefings, scoring, search, and chat.
• Reliability engineering: Invariant audits, an automated self heal routine, error spike detection, a system health cockpit with historical run diffing, and a deploy gate checklist for task management and dashboard changes.

Engineering bandwidth, stated plainly

There is no in-house engineering team and no outside dev agency. The platform is specified and shipped by the founder working with an AI development agent, which is why feature velocity is unusually high for the headcount and why the operational discipline lives in automated audits rather than in code review by peers. This is a genuine strength on speed and a genuine concentration risk on continuity. Any serious diligence conversation should treat bus factor and documentation as the first question, not the feature list.

Off limits, technically or by policy

• No time tracking rebuild: Time Doctor stays. It supplies screenshots, activity rates, and the device id that the OS cannot produce. The OS never pushes worklog into Time Doctor, the direction is Time Doctor to OS only.
• No Asana writes, ever: Asana is permanently decommissioned as a source of truth, protected by an edge killswitch, a terminal status guard, and a source_of_truth column. Historical data is preserved as read only.
• No open signup: Invite only, by policy. Team Members never receive their own workspace, they collaborate on the parent client's.
• Roles live in one place: Roles are stored in a dedicated role table keyed on the auth user id, never on the profile record, to prevent privilege escalation. Every access policy depends on this invariant.
• Client isolation is a hard line: Database level guards prevent a client from ever being linked as a follower, collaborator, or notification recipient outside their own workspaces. This is enforced on write, not just filtered on read.
• No minutes, decimal hours only: Every time input and display uses decimal hours in quarter hour steps.
• Framework is fixed: React and Vite. The platform cannot be migrated to Next.js, Vue, or a server rendered framework without a full rebuild.
• No billing engine inside the OS: Deliberate. Invoicing stays outside, the OS tracks hours and overage only.

• What is unambiguously true: Level 9 Virtual runs its entire delivery operation on custom software it owns, with 65,941 tasks, 1,613 workspaces, and about half of those clients log in every week. The task lifecycle, time capture, hours reconciliation, and reliability automation are real and load bearing.
• What is true but smaller than it sounds: SOPs, Roles, Business Brain, and Sub-Accounts are live modules with real users in the twenties, not company wide behavior. Automations, Saved Views, Timeline, and the Cost Estimator are built and effectively unused.
• What cannot be claimed yet: That the OS causally reduces churn, or that it delivers a measurable before and after for a client. The correlation is strong and the baseline data does not exist. Both are fixable, one with a small onboarding snapshot table and one with two more quarters of cohort data.
• The sharpest strategic gap: The OS is a request desk that clients visit, not an asset they would refuse to give up. Baseline capture, an outcome metric tied to delegated work, and a reason to keep access after a pause are the three changes that would turn adoption into retention leverage.