Stakeholder Report

ZOS Project Tracker

Zaelab Operating System — Assessment & Build Progress

Last Updated: March 30, 2026

Assessment

In Progress

Data Model Gate

Not Started

Build

Not Started

Module Status Board

11 modules

Grow

CRM

Phase 1Assessment Complete

Replaces HubSpot

Deals/Opportunities, Pipeline Stages, Contacts, Companies. 1,447 deals, $598M pipeline, 145 workflows, 536 reports

Client Portal

Future — Unplanned

New capability

Client-facing project visibility and collaboration

Deliver

PSA / ERP

Phase 2Assessment Complete

Replaces Mavenlink (Kantata)

324 users, 296 projects, 260K time entries, $15.5M AR

Estimator

PlannedNot Assessed

Replaces Blueprint (Google Sheets)

Custom estimation tool with SOW generation

Strategic Planning / EOS

Phase 1In Progress

Replaces 90.io

18 teams, 216 users, 454 measurables, 165+ meetings

Operate

HRIS

Future — Unplanned

Replaces BambooHR

People records duplicated across 3+ systems

ATS

Future — Unplanned

Replaces Workable

Applicant tracking and hiring workflows

Finance

Future — Unplanned

Integration with NetSuite

Critical integration: invoicing and revenue recognition

Collaboration / Wiki

Future — Unplanned

Replaces Confluence

Knowledge base, policies, and procedures

Workflows / ITSM

Future — Unplanned

Replaces Jira

10+ business process workflows (SOW approvals, etc.)

LMS

Future — Unplanned

Replaces Lattice

Training, courses, and personalized learning paths

Assessment Tracker

System	PRD	Usage Audit	Transcript Insights	Eval	Status
Current Scope
90.io	✓	✓	✓	✓	Complete
HubSpot	✓	✓	✓	—	In Progress
Blueprint	✓	N/A (spreadsheet)	✓	—	In Progress
Mavenlink	✓	✓	✓	—	In Progress
Future — Not in current scope
BambooHR	—	—	—	—
Jira	—	—	—	—
NetSuite	—	—	—	—
Lattice	—	—	—	—
Workable	—	—	—	—
Confluence	—	—	—	—
DEEL	—	—	—	—

Build Sequence

12-week plan

EOS + CRM + Estimator as the primary 12-week effort. PSA foundation as stretch goal. Tracks overlap — shared data model enables parallel work.

Assess & Plan

Source module assessments, architecture planning, data model design

In progress — 3 of 11 systems assessed. CEO feedback applied March 27.

Data Model Approval

Canonical data model review and sign-off with Zaelab leadership

Gate — must be approved before build begins

Weeks 1–4: Foundation + EOS

Person, Organization, Auth, MCP framework. Scorecard, Rocks (L1→L2→L3), To-Dos, Issues, V/TO, Meetings, Accountability Chart

Replaces 90.io. Foundation entities shared across all modules.

Weeks 3–8: CRM

Deal/Opportunity + Pipeline Stages + Contacts + Companies, deal scoring, basic reporting

June 2026 HubSpot deadline. Overlaps with EOS tail. Built on shared Person + Organization entities.

Weeks 6–10: Estimator

Scope templates, Rate cards, Resource planning, SOW generation, margin approvals

Replaces Blueprint. Bridges CRM to PSA. Sold-as margin born here. Overlaps with CRM tail.

Weeks 8–12: PSA Foundation (Stretch)

Time tracking, Project setup from won deals, basic invoicing, staff margin

Stretch goal — scope calibrated based on EOS/CRM/Estimator progress. Full Mavenlink replacement continues in Phase 2.

Future Phases

Full PSA (Mavenlink), HRIS (BambooHR), ATS (Workable), Wiki (Confluence), ITSM (Jira), LMS (Lattice), Client Portal, Finance (NetSuite)

Sequenced after 12-week core effort ships

Open Questions

4 items

HubSpot marketing migration — 246 email campaigns, 636 forms used for client campaigns (ServiceNow, Shopify, etc.). This is separate from the CRM replacement. Does it stay in HubSpot, move to a different tool, or eventually come into ZOS?

Forecasting model requirements — Currently done in "a million spreadsheets." What exactly is being forecasted (revenue, capacity, demand, cash flow)? What inputs? Needs definition before building into CRM or PSA.

145 HubSpot workflows — How many are still active? Which encode critical business logic vs. legacy automations? Must be mapped before CRM migration.

Actual SaaS cost per system — The ~$1.5M total is Evan's verbal estimate. Need verified invoices/contracts for a real cost baseline and ROI model.

Cost Baseline

~$1.5M

Annual SaaS Spend

Known Breakdown

HubSpotMarketing Pro + Sales Pro + Content Enterprise + Data Starter

Mavenlink (Kantata)Enterprise PSA, 50+ seats (est. $35K–$66K+/yr)

90.ioUnknown

BambooHRUnknown

JiraUnknown

NetSuiteUnknown

Lattice, Workable, Confluence, DEELUnknown

Source: Evan Klein verbal estimate (Mar 18, 2026) — "we're spending like a million and a half dollars a year on systems." Not verified against invoices or contracts. System-by-system cost breakdown needed for ROI analysis.

1. The Problem

Zaelab is a ~$40M technology services company. 300 people. 25+ countries. Two acquisitions in the last year. 9+ SaaS platforms. ~$1.5M/year in software spend. And their CEO still can't answer a basic question about where the business is at.

"We have what the world tells us is a best in class PSA. We have HubSpot, we have Bamboo, we have Jira. And I still can't get a goddamn piece of information to know where the business is at." — Evan Klein

System-hopping: 300 people bouncing between tabs all day.
Duplicate records: Same person in BambooHR, Mavenlink, HubSpot, 90.io, DEEL, and spreadsheets.
Disconnected lifecycle: Deal closes in HubSpot, manually recreated in Mavenlink, invoiced to NetSuite, forecasted in spreadsheets. None of these steps talk to each other.
No margin visibility: Can't track sold-as, staff, or delivered margin because the data spans four systems.
Forecasting in spreadsheets: "You're using a million spreadsheets for forecasting, and it's the bane of our existence."
AI strategy blocked: Zaelab rates AI disruption as WARNING at 6-12 months, CRITICAL at 12-24. Can't build AI on fragmented data.

2. The Thesis

ZOS is a purpose-built, AI-native operating system that replaces Zaelab's siloed SaaS stack with a single platform that owns the data.

"This needs to have persistence and be the actual data storage. I need to sunset these other systems from the world." — Evan Klein

Own the data. ZOS is the persistence layer. When a system gets replaced, it gets turned off.
Modular architecture. Grow / Deliver / Operate. Discrete modules, shared data model.
AI embedded, not bolted on. "Let me build the platform that embeds AI so that we're all using AI, but it's done in a way where we're bringing it to the people."
MCP from day one. "Everything should have an MCP around this. That should be a day one thesis."
Build for actual usage. "When you get down to brass tacks — I don't believe it's as complicated as replacing every single widget in HubSpot."

3. What We're Building

ZOS replaces 11 systems with 4 core modules (first effort) plus cross-cutting platform capabilities. Current status and assessment progress are tracked in the Tracker tab.

The build sequence follows the business flow: Deal (where opportunities enter the pipeline) → Estimate (where scope is priced) → Project (created when a Deal is won, where work is delivered and invoiced). EOS runs in parallel as the operational cadence layer.

The Four Modules

Strategic Planning (EOS) — Scorecards, Rocks, V/TO, L10 Meetings, Accountability Chart. Replaces 90.io.
CRM — Deal/Opportunity, Contacts, Companies, Pipeline Stages (S1-S7), Deal Scoring, Contract Generation. Replaces HubSpot (deals pipeline only — marketing deferred).
Estimator — Project estimation, roles/rates/geographies, scope templates, SOW generation, AI-first reviews. Replaces Blueprint. Bridges CRM to PSA. This is where "sold-as margin" is born.
PSA/ERP — Project financials, staffing, time entry, demand planning, utilization, margin management, invoice milestones. Replaces Mavenlink. Feeds NetSuite.

Cross-Cutting Platform Capabilities

These are the foundation that makes every module work together. They are as important as the modules themselves.

Workflow / Approvals Engine — Configurable approval chains across all modules
Reports / Dashboards — Unified reporting across all data
Analytics & AI Layer — Embedded intelligence, not a bolt-on
Role-Based Access & Permissions — Per-module, per-entity access control
MCP Server — Programmatic access to all platform data and operations
API-First Architecture — Every operation available via API
Audit Trail & Versioning — Full history of changes across all entities
Security / PII / DR — Enterprise-grade security for a 300-person, multi-country org

Remaining systems (BambooHR, Jira, NetSuite, Lattice, Workable, Confluence, DEEL) are future phases, not currently scoped. They will be addressed after the core four modules ship.

4. The Three-Stage Margin Model

The single most valuable capability ZOS can produce — and the one that's impossible with the current stack. It requires connected data across CRM, Estimator, PSA, and Finance.

Sold-as margin — At deal close. Based on the Estimate linked to the Deal (Blueprint today). Revenue = net fees after discount. Cost = sum of estimated role costs. The Deal doesn't become a Project until it reaches S7-Won, so sold-as margin is born on the Deal, not the Project.
Staff margin — When real people are assigned to the project. Their actual cost rates may differ from the generic role rates used in estimation. This reveals whether the staffing plan protects or erodes the sold-as margin.
Delivered margin — Actual hours worked, actual rates, actual costs from time entries. This is ground truth. The delta between sold-as, staff, and delivered margin tells the full story of project profitability.

Today, sold-as lives in Blueprint, staff lives in Mavenlink resource plans, and delivered lives in Mavenlink time entries — three systems, no connection. In ZOS, sold-as margin is born on the Deal (via Estimate), then carried forward to the Project when the Deal is won. Staff and delivered margin live on the Project. See the Data Model tab for the field-level mapping.

6. Key Design Principles

Each principle grounded in what Evan and the team said. Runpoint recommendations labeled separately.

From Evan (direct)

Own the data. Sunset the systems. "This needs to have persistence and be the actual data storage. I need to sunset these other systems from the world."
Build for actual usage. "I don't believe it's as complicated as replacing every single widget in HubSpot. We don't need to do that."
Follow the business flow. "Everything is kind of downstream from [CRM]. There's a natural progression — let's track how the business flows."
Compound value, not incremental. "I don't get a lot of value if I replace one or two of these. I only get real value if I eventually get to the place where I could move most of this off."
Platform over discrete agents. "Rather than let 100 people go off and build their own AI thing — let me build the platform that embeds AI."
MCP from day one. "Everything should have an MCP around this. That should be a day one thesis."
100% operations tool. "It's 100% a day-to-day operations tool." Not a demo, not for equity value.
Prove it, then scale it. "Can we chunk this up and prove it out with 90, prove it out with CRM, and use that as the testing ground."
Collaborative build. "We want to work hand in hand with you and be active contributors."

From Runpoint (our recommendations)

Design the data model with the end state in mind. Even Phase 1 entities should anticipate Phase 2+ needs.
Transparent about unknowns. We say what we know and flag what we don't.
Data quality as a visible feature. Surface missing fields, stale records, and incomplete data. Foundation for trustworthy AI.

This is a living document. Updated as assessments complete, modules ship, and scope refines.

Data Model

How ZOS connects the data that runs the business. Six scenarios show how information flows through the platform — from deals to delivery to the Monday morning L10. Below the scenarios: the entity model, the three-stage margin calculation, and open questions for validation.

Updated March 30, 2026. CEO feedback applied. Deal/Opportunity split from Project. Resource Request/Allocation split. Role/Level reference data added. 12-week parallel timeline: EOS + CRM + Estimator.

Convention: All entities include id, created_on, and modified_on as standard fields. These are omitted from individual field tables below.

How Your Data Flows Through ZOS

6 scenarios

Each scenario starts with a situation you'd recognize, shows what ZOS does at each step, and ends with what changes. If you can say "yes, that's how it happens" at each step, the model is right.

Deal to Delivery

A new ServiceNow implementation deal comes in.

Today: Sales creates a deal in HubSpot. It moves through S1-S6 manually. At S7-Won, someone Slacks delivery. An SA opens Blueprint (Google Sheets), retypes the deal ID, builds scope, picks resources from a dropdown. Someone else goes into Mavenlink and retypes the client name to create a project. At no point can anyone compare delivered margin to what was sold.

In ZOS:

A new Deal enters the pipeline. One Deal record: client (Organization), channel partner (Organization), platform, service type, deal amount, owner (Person). Shows on the pipeline board and revenue forecast immediately.
Estimate created on the Deal. SA builds scope line items with hours by discipline. Rate card auto-prices each role by region. Sold-as margin calculated: $450K revenue, $210K cost, 53% margin. Multiple estimate versions supported.
Deal reaches S7-Won → Project created. The winning Estimate links to the new Project. Delivery entity is born with the deal’s context carried forward.
Staffing. Resource Requests define what’s needed (role, level, skills, region). Delivery lead fulfills them via Resource Allocations — assigning real people with actual cost rates. Staff margin recalculates: 48% (dropped 5 points because a NA resource costs more than the generic role rate).
Delivery & time tracking. Team logs time daily. Delivered margin updates continuously. Midway: $220K billed, $125K cost, 43% delivered margin.
Project closes. All three margins visible in one view: 53% sold-as, 48% staff, 43% delivered.

What you get: Deal and Project are separate entities with clear lifecycle boundaries. Three-stage margin calculated automatically. "How does our estimating accuracy compare to delivery?" becomes answerable across the entire portfolio.

Entities: Deal, Project, Organization, Person, Contact, Estimate, Scope Line Item, Resource Request, Resource Allocation, Rate Card, Time Entry, Task, Financial Transaction, Pipeline Stage

Monday Morning — The Weekly L10

It's 9:00 AM Monday. The Leadership Team runs their L10 meeting.

Today: Someone spends Sunday night pulling numbers from HubSpot, Mavenlink, and spreadsheets, then manually types them into 90.io measurables. If they're late or wrong, the scorecard has stale data. 90.io has no connection to anything — when a number is off-track, there's no way to drill into why.

In ZOS:

Scorecard auto-populates. Pipeline value (S3+) pulled live from Project. Utilization calculated from Time Entry data. Delivered margin from Project records. AR outstanding from Financial Transactions. No manual entry.
Rock review grounded in data. A rock like "Launch ServiceNow practice" links to actual ServiceNow Projects — 3 in pipeline ($1.2M), 2 active ($400K). Progress is a count, not a feeling.
Issues link to root causes. "Project margins trending below 40%" — the team drills into which projects, and whether the problem is estimation, staffing, or delivery.
Meeting record persists. Duration, rating, attendees, decisions, issues resolved, to-dos created — all captured.

What you get: No more Sunday night data entry. When a measurable is off-track, drill from the scorecard into the actual deals, projects, or people driving the number.

Entities: Measurable, Rock, Issue, Meeting, VTO, Person, Project, Time Entry, Financial Transaction, Organization

New Hire Onboarding

A backend engineer joins the Eastern Europe team.

Today: HR creates a record in BambooHR. Somebody creates a login in Mavenlink. Somebody adds them to 90.io. Their cost rate gets typed into Blueprint and maybe Mavenlink — and the two might not match. No single view of this person exists. "Bamboo has the people record. PSA has a people record. There's records all over the place."

In ZOS:

Person record created. Maria Ivanova, type=Internal, role=Backend Engineer. Lightweight identity shared across all modules.
Employee Record created (restricted). Linked 1:1 to Person. Contains salary, tax ID, address, employment type, DEEL status. Only HR sees this — it never leaks into CRM or client-facing views.
Rate card applied. Role (Backend) + Region (EE) maps to bill rate ($145/hr) and cost rate ($18/hr) automatically.
Skills assigned, org placement set. Skills become searchable for staffing. Manager linked. She appears on the staffing board immediately.
First project assignment. Resource Allocation links Maria to the project with her actual rates. Staff margin recalculates — her $18/hr vs. generic $15/hr is a $2,400 impact across 800 hours. Visible before the assignment is confirmed.

What you get: One person, one record, everywhere. HR data isolated from client-facing data by design. Staffing decisions show cost impact before you commit.

Entities: Person, Employee Record, Organization, Geography, Skill, Rate Card, Resource Allocation, Project, Measurable, Rock

Margin Alert

A project's margin is slipping and nobody knows it.

Today: The Acme Corp project was sold at 50% margin. During delivery, an EE backend developer was replaced by a senior NA resource at 4x the cost rate. Delivered margin is now 31%. Nobody catches it until the quarterly P&L reconciliation. By then, $120K in margin has evaporated.

In ZOS:

Staffing change happens. EE developer's allocation ends. NA senior assigned at $95/hr vs. original $18/hr.
Staff margin recalculates instantly. Drops from 50% to 38%. Delta is 12 points.
Threshold alert fires. Configurable rule creates an EOS Issue: "Acme Corp — staff margin dropped 12 points below sold-as (38% vs 50%)."
Issue surfaces in Monday L10. Team IDS's it: find another EE resource, renegotiate the rate, or accept the hit. Decision and action items captured on the record.

What you get: Real-time margin monitoring instead of quarterly surprises. Instant diagnosis — sold-as: 50% (estimation fine), staff: 38% (staffing killed it), delivered: 31% (delivery ran over too).

Entities: Project, Resource Request, Resource Allocation, Person, Rate Card, Measurable, Issue, Time Entry

Quarterly Rock Review

Start of Q2. The leadership team reviews Q1 rocks and sets Q2 rocks.

Today: The team opens 90.io. Each rock owner says "on track" or "not on track." When a rock says "Launch ServiceNow practice," someone has to manually check HubSpot for pipeline, Mavenlink for projects, and a spreadsheet for revenue. The "on track" assessment is vibes.

In ZOS:

"Launch ServiceNow practice" rock links to all Projects where platform=ServiceNow. ZOS shows: 3 deals in pipeline ($1.2M), 2 active ($400K), 1 delivered (47% margin).
"Reduce margin variance to <5%" rock links to a Measurable tracking AVG(ABS(sold_as - delivered)) across completed projects. Current: 7.2%. Not on track — and you can see which projects are driving it.
"Hire 5 EE backend engineers" rock links to Person records filtered by discipline + region + start date. Count: 3 of 5. Progress is a number.
V/TO alignment. Every rock references which 1-Year Plan goal it supports. At the annual, see which goals had rocks that delivered and which didn't.

What you get: Rocks connected to real data. "On track" backed by pipeline, projects, people, and margins — not gut feel. The 90.io-to-everything-else gap is closed.

Entities: Rock, Measurable, VTO, Project, Person, Organization, Pipeline Stage

Channel Partner Reporting

Evan wants to see all activity for ServiceNow.

Today: Someone goes to HubSpot for deals, Mavenlink for projects, then stitches together pipeline, delivery, and revenue data in a spreadsheet. It takes a day. It's stale by the time it arrives. If Evan wants a different slice — "just Q4" or "ServiceNow vs. Shopify margins" — it's another day.

In ZOS:

One click: ServiceNow portfolio view. Filter Projects by channel_partner=ServiceNow. Pipeline: 6 deals, $3.1M. Active: 4 projects, 44% margin. Completed: 8 projects, 41% margin. Total lifetime: $7.8M.
Compare partners. ServiceNow 41% delivered margin. Shopify 47%. BigCommerce 38%. One query.
Resource capacity by partner. Who has ServiceNow skills? Who's assigned? How much bench capacity exists? All answerable because Person + Resource Allocation + Project are connected.
Partner rep relationships. ServiceNow Contacts with deal history per rep. "We did $1.2M through Sarah Chen last year. She's sent 4 new deals this quarter."

What you get: Partner reporting in minutes instead of days. Walk into a QBR with: 18 delivered projects, margin by engagement type, 6 in pipeline, 12 certified people ready to deploy. That's a different conversation.

Entities: Organization, Project, Contact, Person, Skill, Resource Allocation, Financial Transaction, Measurable, Rock

Entity Model

26 entities

Every entity below appeared in the scenarios above. Four layers: People & Org, Business Lifecycle, Operational, and Reference Data.

People & Organization

Entity

What It Is

Scenarios

Status

Person

Lightweight core identity. Every module references this. Intentionally thin — detailed data lives in Employee Record or Contact.

Fields

name	text
email	text
type	enum	internal / external / candidate
auth_role	text
status	enum	active / inactive / alumni

1-6

Draft

Employee Record

Restricted sensitive data for employees/contractors. Linked 1:1 to Person. Only HR sees this — never leaks into CRM views. Primary source: BambooHR. Employee documents (NDAs, contracts) are Files attached to this entity. Note: cost_rate is employee-specific (derived from salary). Bill rate comes from the Rate Card, not the employee record.

Fields

person_id	FK → Person
employee_id	text	BambooHR employee ID
manager_id	FK → Person	employment context — not all Persons have managers
role_id	FK → Role/Level	references shared lookup
level_id	FK → Role/Level	references shared lookup
employment_type	enum	FTE / contractor / vendor
cost_rate	currency	hourly, derived from salary
salary	currency	annual
salary_history	JSON[]	historical salary changes from BambooHR
title	text
department_id	FK → Organization
region_id	FK → Geography
hire_date	date	drives tenure calculation
start_date	date
address	text	restricted
emergency_contact	JSON	name, phone, relationship
tax_id	text	restricted (SSN etc.)
pto_balance	number	hours
deel_id	text	offshore payroll ref
bamboohr_id	text	BambooHR external ref

3, 4

Draft

Contact

External relationship data. Client contacts, partner reps, prospects. Enrichment target — auto-populates from LinkedIn, public data.

Fields

person_id	FK → Person
organization_id	FK → Organization
title_at_company	text
phone	text
role_in_deal	enum	decision maker / influencer / champion / end user
lifecycle_stage	enum	prospect / MQL / SQL / customer
linkedin_url	url
enrichment_data	JSON	auto-populated external data

1, 6

Draft

Organization

Hierarchical. Clients, channel partners, departments, teams, practices. Tree structure with parent/child.

Fields

name	text
type	enum	client / channel_partner / department / team / practice
parent_id	FK → Organization	tree hierarchy
leader_id	FK → Person
accountabilities	text[]	EOS accountability bullets
industry	text	for clients
website	url
enrichment_data	JSON	auto-populated for clients

1-6

Draft

Geography

25+ countries across 3 rate regions (NA, EE, WE). Drives rate cards, payroll compliance, calendars.

Fields

region	enum	NA / EE / WE
country	text
timezone	text
currency	text
holiday_calendar	JSON
payroll_provider	enum	internal / DEEL

3, 4

Draft

Skill

Standalone lookup table for skills and certifications. Skills exist as both person attributes (via PersonSkill) AND project/estimate requirements. "This project requires ServiceNow skills" is a valid use case independent of who's assigned.

Fields

name	text	e.g. "ServiceNow", "React", "Project Management"
category	enum	certification / language / technical / methodology / other
description	text
is_active	boolean

PersonSkill (junction)

person_id	FK → Person
skill_id	FK → Skill
proficiency_level	number	1-5
certified_date	date	for certifications

SkillRequirement (junction)

entity_type	text	project / estimate
entity_id	FK	polymorphic ref
skill_id	FK → Skill
required_count	number	how many people with this skill needed
min_proficiency	number	1-5

1, 3, 6

Draft

Business Lifecycle

Entity

What It Is

Scenarios

Status

Deal / Opportunity

The pre-sale pipeline entity. Deals exist independently before a Project is created. When a deal reaches S7-Won, it converts to a Project. All estimates are linked to Deals, not Projects.

Fields

name	text
client_id	FK → Organization
channel_partner_id	FK → Organization	optional
deal_owner_id	FK → Person
stage_id	FK → Pipeline Stage	configurable S1-S7
deal_amount	currency
forecast_category	enum	pipeline / upside / commit / closed
close_probability	pct
contacts	FK[] → Contact
hubspot_deal_id	text	external ref

1, 6

Draft

Source: HubSpot (deal, 1,447 records, $598M pipeline)

Project

The post-sale delivery entity. Created when a Deal reaches S7-Won. Carries delivery, staffing, time tracking, invoicing, and the three margins.

Fields

name	text
deal_id	FK → Deal	the originating deal
estimate_id	FK → Estimate	the winning estimate
client_id	FK → Organization	the end customer
channel_partner_id	FK → Organization	optional — inherited from deal but may change
service_type	enum	Implementation / Advisory / etc. (7 values)
platform	enum	ServiceNow / Shopify / etc. (21 values)
billing_type	enum	T&M / Fixed Fee
rate_card_version	FK → Rate Card
sold_as_margin	pct	from Estimate
staff_margin	pct	from Resource Allocation
delivered_margin	pct	from Time Entries
start_date / end_date	date

1-6

Draft

Estimate

Approach variant for a deal. Estimates are created before a project exists — they link to Deals. When a deal converts to a project, the winning estimate links to the new project. Supports multiple versions over the deal lifecycle.

Fields

deal_id	FK → Deal	estimates are created before a project exists
variant_name	text	Original, Short Timeline, etc.
version	number	supports multiple versions over lifecycle
locked	boolean	locks after approval
discount_pct	pct	0-100
contract_type	enum	T&M / Fixed Fee
total_hours	number	calculated
gross_fees	currency	before discount
net_fees	currency	after discount
total_cost	currency	calculated
gross_margin_pct	pct	calculated
is_selected	boolean	the winning variant

Draft

Scope Line Item

A deliverable within an estimate. Hours by discipline. SOW-ready descriptions.

Fields

estimate_id	FK → Estimate
sequence_id	number	display order
is_included	boolean	in/out of scope
category	text	Feature Set (epic)
name	text	Feature name
description	rich text	SOW-ready
assumptions	rich text	SOW-ready
hours_frontend	number
hours_backend	number
hours_integration	number
hours_ux	number
hours_additional	number

Draft

Resource Request

The operational need — “we need a Senior Backend Engineer for 12 weeks.” Created during estimation or staffing. Carries skill requirements.

Fields

deal_id	FK → Deal	nullable
project_id	FK → Project	nullable
role_id	FK → Role/Level
level_id	FK → Role/Level
discipline	enum	14 values
region	enum	NA / EE / WE
skills	FK[] → Skill	required skills
hours_needed	number
start_date	date
end_date	date
status	enum	request / soft / hard

1, 3, 4, 6

Draft

Resource Allocation

The fulfillment — “Jane Smith is assigned.” Links a real person to a resource request with specific rates.

Fields

request_id	FK → Resource Request
person_id	FK → Person
bill_rate	currency/hr	from Rate Card
cost_rate	currency/hr	from Employee Record
weekly_hours	JSON	array by week
status	enum	tentative / confirmed / completed

1, 3, 4, 6

Draft

Financial Transaction

Money in and out. Quotes, invoices, payments, revenue recognition. Fixed Fee projects: milestone invoicing is separate from rev rec (rev rec is by percent complete, not milestones).

Fields

project_id	FK → Project
type	enum	quote / invoice / payment / credit_memo / recognition
amount	currency
currency	text	multi-currency support
date	date
due_date	date
status	enum	draft / sent / paid / overdue
netsuite_id	text	external ref
line_items	JSON
percent_complete	pct	for rev rec on Fixed Fee (not milestone-based)
recognition_method	enum	by_deliverables / by_hours / pm_judgment
recognized_amount	currency	revenue recognized to date

1, 2, 6

Not Started

Operational

Entity

What It Is

Scenarios

Status

Time Entry

Universal work record. 260K entries, 324 users. Highest-traffic entity.

Fields

person_id	FK → Person
project_id	FK → Project
task_id	FK → Task
date	date
hours	number
billable	boolean
notes	text
approval_status	enum	pending / approved / rejected
approved_by	FK → Person
locked	boolean	prevents edits after lock date

1, 2, 3, 4

Draft

Task

Work items across modules. Polymorphic: project tasks, EOS to-dos, rocks, workflow steps.

Fields

title	text
description	rich text
type	enum	project_task / eos_todo / eos_rock / workflow_step
assignee_id	FK → Person
status	text	configurable per type
due_date	date
parent_id	FK → Task	hierarchy (phases, sub-tasks)
project_id	FK → Project
meeting_id	FK → Meeting	for meeting-generated tasks
is_recurring	boolean

1, 2, 5

Draft

Measurable

Weekly/monthly/quarterly KPI tracked on the scorecard. 454 measurables across 18 teams. Phase 1 all manual entry; designed for future auto-calculation from CRM/PSA/Finance.

Fields

name	text
owner_id	FK → Person
team_id	FK → Organization
goal	number
unit_type	enum	currency / pct / number
period	enum	weekly / monthly / quarterly
operator	enum	gte / lte / eq
data_source	enum	manual / crm / psa / finance
values	JSON	time-series by period

2, 5

Draft

Rock

Quarterly goal with milestones and status tracking. Supports L1→L2→L3 hierarchy: L1 = company rocks, L2 = department, L3 = team. Allows tracing rock hierarchy across levels.

Fields

title	text
owner_id	FK → Person
team_id	FK → Organization
quarter	text	e.g. Q2 2026
status	enum	on_track / off_track / complete
milestones	JSON[]	simple milestones, human judgment for completion
linked_project_id	FK → Project	bridge to PSA
parent_rock_id	FK → Rock	self-ref for L1→L2→L3 hierarchy

2, 5

Draft

Issue

Short-term and long-term issues tracked through the Identify-Discuss-Solve process. 13 strategic issues actively tracked by Leadership Team.

Fields

title	text
priority	number	IDS ranking
status	enum	open / resolved
ids_phase	enum	identify / discuss / solve
team_id	FK → Organization
meeting_history	JSON[]	carry-forward context

2, 4

Draft

Meeting

L10, quarterly, and annual meetings with structured agendas. 165+ meetings for Leadership Team. AI-generated summaries.

Fields

type	enum	L10 / quarterly / annual
team_id	FK → Organization
date	datetime
duration	number	minutes
rating	number	1-10
attendees	FK[] → Person
agenda_sections	JSON	L10 format
ai_summary	text	auto-generated

2, 5

Draft

VTO

Vision/Traction Organizer. Strategic planning document with core values, core focus, 10-year target, and annual plan. One per team/company level.

Fields

team_id	FK → Organization
core_values	text[]
core_focus	text
ten_year_target	text
one_year_plan	JSON	revenue, profit, goals

2, 5

Draft

Document

Generated artifacts: SOWs, proposals, contracts, change orders. Versioned.

Fields

project_id	FK → Project
type	enum	sow / proposal / contract / change_order
template_id	text
version	number
status	enum	draft / sent / signed
file_id	FK → File
generated_from	JSON	source entity refs

Not Started

Forecast

Revenue, capacity, demand, cash flow projections. Currently in spreadsheets.

Fields

type	enum	revenue / capacity / demand / cash_flow
period_start	date
period_end	date
value	number
confidence	pct
assumptions	text
created_by	FK → Person

Not Started

Approval Request

Workflow and approval tracking. Replaces 10+ Jira business workflows.

Fields

entity_type	text	project / estimate / sow / pto
entity_id	FK (polymorphic)
chain_id	FK → ApprovalChain
current_step	number
status	enum	pending / approved / rejected / cancelled
requested_by	FK → Person

ApprovalChain

name	text	e.g. "SOW Approval"
steps	JSON[]	approver_id or role, order
conditions	JSON	routing rules, e.g. "if margin < 65% route to CEO"

MarginThreshold (reference)

min_margin	pct	lower bound
max_margin	pct	upper bound
action	enum	auto_approve / require_approval
approver_role	text	COO / CEO
service_type	enum	optional — can vary by service type

Default thresholds: >72.5% auto-approve, 65–72.5% COO approves, <65% CEO approves

ApprovalStep

approver_id	FK → Person
decision	enum	approved / rejected
decided_at	datetime
notes	text

Draft

Platform Content (Horizontal)

These attach to any entity across the platform. Not owned by any single module.

Entity

What It Is

Scenarios

Status

Note

Comments, observations, context. Attaches to any entity.

Fields

entity_type	text	polymorphic ref
entity_id	FK	polymorphic ref
author_id	FK → Person
content	rich text
is_internal	boolean	hidden from client portal
created_at	datetime

All

Not Started

File

Documents, images, PDFs attached to any entity. Supports both direct uploads and external references (Google Docs, Google Sheets, etc.). Versioned. Employee documents (NDAs, contracts) are Files attached to Employee Record.

Fields

entity_type	text	polymorphic ref
entity_id	FK	polymorphic ref
filename	text
reference_type	enum	upload / external_link
external_url	url	for Google Docs, Sheets, external references
mime_type	text
size_bytes	number
storage_url	url	for uploads
version	number
uploaded_by	FK → Person

1, 3

Not Started

Recording

Audio/video with derived transcripts. Meetings, deals, contacts.

Fields

entity_type	text	polymorphic ref
entity_id	FK	polymorphic ref
file_id	FK → File
duration_seconds	number
transcript	text	derived from audio
transcript_status	enum	pending / complete
participants	FK[] → Person

Not Started

Activity

System-generated audit log on every entity. Automatic.

Fields

entity_type	text	polymorphic ref
entity_id	FK	polymorphic ref
action	enum	created / updated / deleted / assigned / approved
actor_id	FK → Person
timestamp	datetime
changes	JSON	field-level diff

All

Not Started

Reference Data

Entity

What It Is

Scenarios

Status

Role/Level

Shared lookup for roles and seniority levels. Referenced by Employee Record (what someone IS) and Resource Request (what’s NEEDED). Ensures consistency across staffing and HR.

Fields

role_name	text	e.g. "Backend Engineer"
level	enum	Junior / Mid / Senior / Lead / Principal / Executive
discipline_id	FK → Discipline vocabulary

1, 3, 4

Draft

Rate Card

Versioned billing and cost rates. 52 entries per version. Old projects keep their original card.

Fields

version	text	e.g. "2025"
effective_date	date
entries	JSON[]	region, discipline, role, cost_rate, bill_rate

1, 3, 4

Draft

Pipeline Stage

Admin-configurable deal stages. Editable without code changes.

Fields

name	text	e.g. "S3 Solution"
display_order	number
is_closed	boolean
is_won	boolean
default_probability	pct
color	text	hex

1, 5, 6

Draft

Key Entity Relationships

From	To	Cardinality	Notes
Deal	Estimate	1:N	Multiple estimate variants per deal
Deal	Project	1:1	On conversion at S7-Won
Deal	Contact	N:N	Multiple contacts per deal
Deal	Organization	N:1	Client and channel partner
Deal	Pipeline Stage	N:1	Current deal stage
Estimate	Scope Line Item	1:N	Deliverables within estimate
Project	Time Entry	1:N
Project	Financial Transaction	1:N
Resource Request	Resource Allocation	1:N	One request, multiple fulfillments
Resource Request	Skill	N:N	Required skills for the request
Resource Allocation	Person	N:1	Assigned person
Employee Record	Role/Level	N:1	What role/level someone IS
Resource Request	Role/Level	N:1	What role/level is NEEDED
Person	Employee Record	1:1	Restricted HR data
Person	Contact	1:1	External relationship data
Person	Organization	N:1	Team/department membership
Rock	Project	N:1	Optional bridge to PSA
Meeting	Organization	N:1	Team meetings
Measurable	Person	N:1	Owner

Three-Stage Margin Model

The core value proposition. Today this data spans 4 systems with no linkage. In ZOS, it's one calculation on the Project entity.

Stage	When	Revenue	Cost	Source Today
Sold-as Margin	Deal closes, estimate selected	Estimate.net_fees	Estimate.total_cost (generic role rates)	Blueprint
Staff Margin	Real people assigned	SUM(allocation.bill) - discount	SUM(allocation.cost) at actual person rates	Blueprint → Mavenlink
Delivered Margin	Work complete	SUM(time.hours * time.bill_rate) - discount	SUM(time.hours * time.cost_rate)	Mavenlink

Answered Questions

14 resolved

Questions resolved across two feedback sessions with Evan Klein (March 26-27). Responses captured and applied to the data model.

Discounts are estimation-specific. Discounts apply at the estimate level only. Sold-as margin locks at deal close. No further discounts applied at staff or delivery stages (unless exceptional circumstances like a client mistake, which isn't a priority use case).

Change orders: separate estimate, separate margin. Each change order creates a new Estimate with its own sold-as margin. The Project shows aggregate margin across all estimates (original + change orders). Typically a separate sales opportunity in HubSpot.

Staffing trigger: 75% forecast confidence. When a deal reaches 75% confidence, it triggers the staffing team radar. Not a hard gate — a signal.

Channel partner: optional on projects. Not every project has a channel partner. channel_partner_id is nullable.

Measurables Phase 1: all manual entry. Design for future auto-calculation from CRM/PSA/Finance, but Phase 1 is 100% manual.

Rocks: simple milestones, human judgment. L1→L2→L3 hierarchy desired. Parent rock linkage via parent_rock_id.

Cost rates: currently average by role. Future: actual person-specific costs with visibility restrictions.

Fixed fee margin tracking. Track full bill rates even on Fixed Fee (what the estimate was built against). Track percent complete for revenue recognition — not the same as milestone invoicing. Percent complete can be measured by deliverables, hours, or PM judgment. Need flexibility — different project sizes may use different methods. Milestone invoicing and rev rec are separate concerns.

Margin thresholds: uniform, not by service type. Currently no variation by service type. This is a new policy just deployed. Jira workflow for deal approvals available for reference.

Multiple projects: yes, very common. No blocking constraint. Some people on 16 projects. AI opportunity to flag over-allocation but deferred to PSA phase.

DEEL: employer of record only. No impact on cost rate or how they're treated. DEEL contractors are just employees who happen to work in a country where Zaelab has no legal entity. Treat as normal employees.

Partner hierarchy: 5-7 levels deep. Org chart + sales territory mapping. Regional managers, sales teams, sales engineers covering multiple teams, partner go-to-market people per industry, product teams. Complex — think org chart plus territory map.

BambooHR access: confirmed. Access taken care of.

Jira workflows: confirmed complex. Complexity varies. Simple approval chains to conditional routing (e.g., contracts over $250K or below-target margin trigger different approver paths). More information available from Thomas and outside contractors.

Open Questions

6 remaining

Remaining open items after three feedback sessions.

Architecture & Data Model

Deal/Opportunity → Project split: downstream implications. The Estimate and Resource Allocation relationships need a dedicated discussion to map the full lifecycle flow when a Deal converts to a Project.

Role/Level reference table design. Referenced in both Employee Record and Resource Request. Should be designed as a shared Reference Data entity. Need to define the initial values (role names, level tiers, discipline mappings).

Data & Migration

HubSpot data migration scope. Evan confirmed we need to bring in old deals. What's the cutoff? All historical deals or a date range? What fields are required vs. nice-to-have?

Historical Mavenlink project migration. Active projects: yes, migrate. Historical: TBD — Evan needs to circle back on value of bringing over past projects.

How is acquired company data handled? Two acquisitions in the last year. Separate system instances? Identity merge needed?

NetSuite integration architecture. Invoice schema, GL mapping, sync triggers, failure handling. Hard dependency for Financial Transaction design.

Spec Gaps Checklist

Do not solve here

This is the implementation-gap list for turning the current tracker and data model into a buildable technical specification. These items are intentionally listed as unresolved checklist items so the team can validate them explicitly before schema, workflow, and migration work hardens.

Lifecycle & Cardinality

☐ Define the canonical Deal → Estimate → Project lifecycle. Exact conversion rules, stage triggers, and system events when a Deal reaches S7-Won.

☐ Resolve change-order relationships. Decide whether change orders create new Deals, new Estimates on the same Project, separate Projects, or some combination of those.

☐ Lock cardinalities for core entities. Especially Deal:Project, Project:Estimate, Project:Financial Transaction, and how Resource Requests span pre-sale vs post-sale.

☐ Define stage-history requirements. Current stage exists, but historical stage transitions, owner changes, close-date changes, and forecast changes are not yet modeled.

Financial Model

☐ Write the formula book for sold-as, staff, and delivered margin. Inputs, timing, rollups, rounding rules, discount treatment, and how each metric behaves on T&M vs Fixed Fee work.

☐ Clarify quote / estimate / invoice ownership. Decide which financial artifacts belong to Deal-level CRM/Estimator workflows versus Project-level PSA/Finance workflows.

☐ Define revenue recognition and milestone invoicing separately. Trigger rules, allowable recognition methods, override authority, and audit requirements.

☐ Define multi-currency behavior. Transaction currency, reporting currency, FX timing, and how rates are preserved historically.

Reference Data & Normalization

☐ Normalize Role / Level / Discipline / Region. Decide which are separate tables vs enums, their unique keys, and how they map to Rate Card entries.

☐ Replace hard-coded effort columns in estimates. Decide whether Scope Line Item effort is modeled as child records rather than fixed discipline columns.

☐ Define organization hierarchy semantics. Internal teams, departments, clients, channel partners, legal entities, and partner territory overlays need distinct rules.

☐ Define identity merge rules. Person vs Contact vs Employee Record dedupe, acquisition merges, and source-of-truth precedence by system.

Workflow & Platform Patterns

☐ Choose the persistence pattern for approvals. Approval chains, steps, routing conditions, threshold evaluation, delegation, and resubmission behavior are still conceptual.

☐ Choose the persistence pattern for polymorphic attachments. Notes, Files, Recordings, and Activity currently use generic entity references; storage and query strategy still need to be chosen.

☐ Define auditability requirements. Which entities require immutable history, field-level diffs, versioning, and actor attribution.

☐ Define reporting grain. The tracker references dashboards and reports, but the source facts, dimensions, snapshots, and refresh rules are not yet specified.

Security & Migration

☐ Produce a permissions matrix. Role-based and field-level access for Employee Record, finance data, approvals, partner views, and any future client-facing surfaces.

☐ Produce a source-to-target migration matrix. Field mappings, transforms, required vs optional fields, cutoffs, history depth, and validation rules for HubSpot, Blueprint, Mavenlink, BambooHR, and NetSuite.

☐ Define external ID strategy. Which source IDs are preserved, where they live, and how sync or back-reference behavior works during phased replacement.

☐ Decide the authoritative schema artifact. The tracker is currently the narrative source of truth; the build still needs a canonical ERD/schema spec that engineering can implement against.

Technical Reference: System Mappings

Where each entity's data lives today across existing systems. Blank cells represent gaps — data that doesn't exist in that system.

ZOS Entity / Field	90.io	HubSpot	Blueprint	Mavenlink	BambooHR	Lattice	NetSuite
Person (core identity)
Name	user.name	contact.name	Resource (named)	user.full_name	employee.displayName	user.name	entity.name
Email	user.email	contact.email	—	user.email_address	employee.workEmail	user.email	—
Type	—	contact.lifecyclestage	—	user.account_membership	—	—	—
Role / Title	user.seat	—	Role (dropdown)	user.role	employee.jobTitle	—	—
Employee Record (restricted) — primary source: BambooHR
Manager	—	—	—	—	employee.supervisorId	user.manager	—
Role (FK → Role/Level)	—	—	Role (dropdown)	user.role	employee.jobTitle	—	—
Level (FK → Role/Level)	—	—	—	—	—	—	—
Status	user.status	—	—	user.account_membership	employee.status	user.status	—
Cost Rate	—	—	Values.Cost	user.cost_rate	—	—	—
Salary	—	—	—	—	employee.payRate	—	—
Address	—	—	—	—	employee.address	—	—
Tax ID / SSN	—	—	—	—	employee.ssn	—	—
Employment Type	—	—	—	—	employee.employeeType	—	—
Start/End Date	—	—	—	—	employee.hireDate	—	—
Employee ID	—	—	—	—	employee.id	—	—
Salary History	—	—	—	—	employee.compensation	—	—
Emergency Contact	—	—	—	—	employee.emergencyContact	—	—
Documents (NDA, contracts)	—	—	—	—	employee.files	—	—
Contact (external)
Title at Company	—	contact.jobtitle	—	—	—	—	—
Company	—	contact.company	—	—	—	—	—
Deal Associations	—	association.deal	—	—	—	—	—
Lifecycle Stage	—	contact.lifecyclestage	—	—	—	—	—
Organization (hierarchy)
Client	—	company (427)	Company	account	—	—	customer
Channel Partner	—	company (partner type)	—	—	—	—	—
Department	A-Chart nodes	—	—	organization (dept tree)	employee.department	—	department
Team	team (18 teams)	—	—	—	—	—	—
Deal / Opportunity (pre-sale)
Deal	—	deal (1,447 records, $598M pipeline)	—	—	—	—	—
Pipeline (configurable)	—	deal.pipeline_stage	—	—	—	—	—
Contacts	—	association.contact	—	—	—	—	—
Project Lifecycle (post-sale)
Delivery	—	—	—	workspace (296)	—	—	—
Estimation	—	—	Approach Variant	estimate	—	—	—
Scope	—	—	Scope Line Items	—	—	—	—
Resource Request	—	—	Resource Allocation	—	—	—	—
Resource Allocation	—	—	—	workspace_resource	—	—	—
Invoicing	—	—	—	invoice (2,922)	—	—	transaction
Rate Card
Version	—	—	"2025 Rate Card"	rate_card_set	—	—	—
Role + Region key	—	—	Combined (lookup)	role	—	—	—
Cost / Bill rates	—	—	Values sheet	cost_rate / bill_rate	—	—	—
EOS
Measurable	measurable (454)	—	—	—	—	—	—
Rock	rock	—	—	—	—	—	—
Issue	issue	—	—	—	—	—	—
Meeting (L10)	meeting (165+)	—	—	—	—	—	—
V/TO	vto	—	—	—	—	—	—

Prototype Status

The current prototype (in zos/) is a 90.io clone. It replicated 126 features with a 97% scorecard feature match. That demonstrated engineering feasibility, but it missed the point.

Evan didn't hire us to rebuild 90.io. He hired us because 90.io is a data-entry form that can't connect to anything, can't surface intelligence, and forces manual input for every metric. The prototype scores well on feature parity. It scores zero on connected data, AI intelligence, and MCP access — the things that actually matter.

The prototype is a reference for how 90.io works, not the starting point for the real build. We will likely start fresh. The real build needs to deliver connected data, AI intelligence, and MCP access from day one.

What We're Actually Building — EOS Module

7 components

The EOS module rebuilt around what Zaelab actually needs: auto-populated data from other ZOS modules, AI-generated intelligence, and MCP access for programmatic interaction. Each component replaces the equivalent 90.io feature with a fundamentally better approach. EOS is part of the broader 12-week build covering EOS + CRM + Estimator (see Build Timeline below).

Status reflects the new build plan. The prototype's 126-feature count does not carry over.

Scorecard

Not Started

Weekly KPI tracking grid with period tabs, color-coded goals, inline editing, and grouping. The heartbeat of the EOS cadence — 454 measurables updated weekly across 18 teams.

Key improvement over 90.io: Auto-populated measurables from CRM, PSA, and Finance modules. Anomaly detection flags off-track metrics automatically. Trend prediction projects where measurables are headed. Data source indicators show whether each value is live from a system or manually entered.

Meetings

Not Started

Structured L10 meeting format with configurable agenda sections (Segue, Data, Rock Review, To-Do List, IDS, Conclude). Scheduling, attendance tracking, and meeting ratings. 165+ meetings for Leadership Team alone.

Key improvement over 90.io: AI-generated meeting summaries after each L10. Pre-meeting briefings that surface off-track measurables, behind-schedule rocks, incomplete to-dos, and new issues. Carry-forward context so IDS discussions include history from prior meetings.

Rocks

Not Started

Quarterly goal tracking with milestones, status (On Track / Off Track / Complete), kanban planning board, and V/TO goal linkage. 5 Company Rocks at the leadership level, individual rocks per person.

Key improvement over 90.io: Predictive completion based on milestone velocity — flag at-risk rocks at week 4, not week 11. Dependency mapping across rocks. Outcome linkage that tracks whether completing a rock actually moved the underlying measurable. Rock-to-project bridge connecting quarterly goals to PSA delivery.

To-Dos

Not Started

Task list with title, due date, owner, completion toggle, and overdue indicators. Private and team to-dos. 17 active to-dos on Leadership Team with real operational items.

Key improvement over 90.io: Meeting-generated to-dos automatically linked to the L10 and IDS discussion that created them — context is never lost. Completion nudges via notifications as due dates approach. Recurring to-dos that auto-generate for repeating tasks.

Issues (IDS)

Not Started

Short-term and long-term issue lists with priority, owner, cross-team sharing, and archive. 13 strategic issues actively tracked by the Leadership Team through the Identify-Discuss-Solve process.

Key improvement over 90.io: AI-suggested issue categorization and clustering when multiple teams raise similar problems. Resolution tracking that records what was decided and what to-dos resulted. IDS phase tracking showing how many meetings an issue has been discussed in. Auto-generated issues when scorecard measurables go off track for 3+ consecutive weeks.

V/TO (Vision/Traction Organizer)

Not Started

Strategic planning document with Core Values, Core Focus, 10-Year Target, 3-Year Picture, 1-Year Plan, 90-Day Plan, and SWOT analysis. Fully populated for Zaelab with revenue, EBITDA, and gross margin targets.

Key improvement over 90.io: Strategic alignment scoring — V/TO goals show which rocks are attacking them and their real-time status. Connected metrics pull live pipeline and revenue data instead of static numbers reviewed quarterly. The V/TO becomes a navigation root, not a static document.

Accountability Chart

Not Started

Hierarchical org chart with role titles, person assignments, photos, and accountability bullet points. Expand/collapse navigation, search, and draft charts. 7+ departments from Visionary through all teams.

Key improvement over 90.io: Built on canonical Person and Organization entities — the Accountability Chart IS the org structure for the entire platform. Shared with future HRIS module so there is no duplication. Role-based scorecard views let you click a person and see their measurables, rocks, to-dos, and issues in one place.

What We're NOT Building

5 descoped

These 90.io features have zero or near-zero usage at Zaelab. They are descoped permanently — the effort goes into connected data and AI features instead.

Headlines

Descoped

0 headlines, 0 cascading messages. Not adopted — announcements happen in Slack.

Knowledge

Descoped

Default content only, no custom content. Confluence handles this. Separate ZOS Wiki module if ever needed.

OS Toolbox

Descoped

0% mastery across all 22 EOS tools. EOS learning content is not our business to replicate.

Assessments

Descoped

1 assessment attempted in Q1 2025, never repeated. One-time experiment that did not stick.

1-on-1 Reviews

Descoped

Set up but not actively used. Lattice and BambooHR handle performance management. Will be part of the HRIS module.

Foundation Requirements

5 prerequisites

Platform capabilities that must exist before the EOS module build starts. The EOS module references these foundations — building without them creates the same isolated data problem 90.io has.

Person Entity

Canonical identity record with lightweight base + Employee Record + Contact split. Scorecard owners, rock owners, to-do assignees, meeting attendees, issue owners — everything references a Person. Must be the single golden record, not an EOS-specific user table.

Not Started

Organization Entity

Hierarchical tree structure supporting departments, teams, and companies. Every EOS artifact belongs to a team (18 teams). The Accountability Chart requires parent/child org hierarchy. Must be canonical across all ZOS modules.

Not Started

Auth / Role-Based Permissions

64 licensed seats need role-based access scoped to EOS: who can edit the V/TO, create company rocks, or view another team's scorecard. Basic auth exists but needs per-module, per-entity permission scoping.

Not Started

MCP Server Framework

Evan's day-one requirement. Programmatic read/write access to all EOS data: scorecard values, rock status, meeting history, issue lists, V/TO content. Enables Slack bots, CLI tools, and agent workflows. Build alongside the web UI, not after.

Not Started

Notification System

Overdue to-do alerts, off-track measurable warnings, upcoming meeting reminders, issue assignments. Push to web, email, and MCP channels (Slack). Basic infrastructure exists but needs EOS-specific event triggers.

Not Started

12-Week Build Timeline

4 tracks / parallel

Aggressive but aligned timeline matching Evan's expectation: EOS + CRM + Estimator within 12 weeks, with PSA foundation as a stretch goal. Tracks overlap intentionally — the shared data model (Person, Organization, Project) enables parallel work. June HubSpot deadline drives the CRM track.

W10

W11

W12

Foundation + EOS

WEEKS 1–4

CRM

WEEKS 3–8

Estimator

WEEKS 6–10

PSA Foundation

WEEKS 8–12 (stretch)

Weeks 1–4: Foundation + EOS Core

Foundation + EOS Track

Canonical Person and Organization entities. Auth and role-based permissions. MCP server framework. Scorecard with 454 measurables. Rocks with L1→L2→L3 hierarchy. To-Dos. Issues with IDS tracking. V/TO. Meetings with L10 format. Accountability Chart built on canonical entities.

Exit: Full EOS workflow live. 90.io can be sunset. Foundation entities (Person, Organization) ready for CRM and Estimator.

Weeks 3–8: CRM

CRM Track — overlaps with EOS tail

Pipeline with S1–S7 stages. Contacts and Companies built on Person + Organization entities. Deal stages, deal scoring, and pipeline board. Basic reporting and dashboards. June HubSpot deadline drives this track.

Exit: Deals pipeline operational. HubSpot CRM replacement live for sales team. Pipeline data flows to EOS Scorecard measurables.

Weeks 6–10: Estimator

Estimator Track — overlaps with CRM tail

Scope templates with SOW-ready descriptions. Rate cards with region/discipline pricing. Resource planning with skill requirements. SOW generation. Sold-as margin calculation. Margin threshold approvals (>72.5% auto-approve, 65–72.5% COO, <65% CEO).

Exit: Blueprint replaced. Deal→Estimate→SOW flow operational. Sold-as margin visible on every project.

Weeks 8–12: PSA Foundation (Stretch Goal)

PSA Track — stretch goal, scope TBD

Time tracking setup. Project creation from won deals. Basic invoicing and milestone management. Staff margin calculation from real person assignments. Active Mavenlink project migration (historical TBD).

Exit: Time tracking operational for new projects. Staff margin visible. Full Mavenlink replacement continues into Phase 2.

ZOS Project Tracker · Zaelab Operating System · Prepared by Runpoint · March 30, 2026