Initiatives — the finance anchor

An Initiative is the thing a human decides to fund. It is where the money, the governance, and the strategy live. A Project is the thing your PMS already knows about — an epic in Jira, a project in Linear, an area path in Azure DevOps — synced into Flowstate as a unit of delivery, not a unit of finance.

This is the core inversion of the roadmap redesign. Projects used to carry their own cost centre, their own CapEx eligibility, their own everything. Now a project is inert until a human takes responsibility for it — either by giving it a cost centre directly, or by adopting it into an Initiative. The Initiative is the anchor; the project rolls up into it.

If you are coming from the old three-layer roadmap (Driver → Initiative → Project), see the migration note at the bottom.

The split

	Initiative	Project
Created by	A human, deliberately	Your PMS sync (or a human, for manual projects)
Role	Finance + governance anchor	Delivery child
Carries	Cost centre, Finance Mode, budget, margin, committed FTE, AI budget, portfolio lens, objective	Allocations, effort/actuals, PMS tickets
Parents	At most one Objective	At most one Initiative
Children	Many projects	—

A project belongs to at most one Initiative (initiativeId). That constraint is enforced on adoption — adopting a project that already has a parent throws PROJECT_ALREADY_ADOPTED.

The inert gate

A synced project starts life inert: it has no cost centre and no Initiative, so it carries no financial signal. Inert projects are excluded from capitalisation and do not contribute cost until a human acts on them. There are exactly two ways to "activate" a project:

1. Assign it a cost centre directly — it becomes a standalone finance object on its own cost centre.
2. Adopt it into an Initiative — the Initiative's cost centre (and Finance Mode) now governs it.

isInert is derived, never stored. The rule:

isInert = sourceSystem ≠ 'manual'
          AND resolved cost centre is null
          AND initiativeId is null

A manual project (one a human created in Flowstate) is never inert — the human already took responsibility by creating it, even before assigning a cost centre.

TIP

Inert is the safety net. It means a noisy PMS sync can pull in a thousand epics and none of them silently land in your CapEx numbers or your forecast. Finance only sees what a human deliberately anchored.

The resolution chain

"Where does this project's money live?" has one answer, computed at read time, never copied onto the row:

1. If the project belongs to an Initiative and that Initiative has a cost centre → use the Initiative's cost centre.
2. Otherwise → use the project's own cost centre.

The same chain resolves the Finance Mode (the project inherits its parent Initiative's mode) and the derived capitalisable flag.

LiveProject.initiativeId ──► Initiative.costCentreId  (preferred)
        │
        └─ (no initiative, or initiative has no cost centre)
                          ──► LiveProject.costCentreId  (fallback)

When a project is adopted, its own costCentreId is stashed into dormantCostCentreId and nulled, so the Initiative's cost centre is the single source of truth while the link exists. Detaching restores it. See Finance → Initiative finance for the full mechanic.

Finance Mode

Every Initiative has a Finance Mode that gates which flows and fields are visible. This is the single capability gate — every "can this Initiative capitalise / bill / show margin?" question answers here, so the rules never drift between the UI and the resolvers.

Finance Mode	What it is	canCapitalise	canRdClaim	canBill	showsMargin
CAPEX_RD_CLAIM	Internal capital project — capitalise + claim R&D	✅	✅	—	—
CLIENT_BILLING	Agency / SOW — billed to a client with a margin	—	—	✅	✅
INTERNAL_COST	Pure run-cost (KTLO, ops) — neither capitalised nor billed	—	—	—	—

The capability object is surfaced on the API as Initiative.financeModeCapabilities (canCapitalise, canRdClaim, canBill, showsMargin, showsBilling).

Client-billing suppresses CapEx and R&D

A CLIENT_BILLING Initiative's projects are never capitalisable — the work is a client deliverable billed under a Statement of Work, not internal capital. CapEx/R&D surfaces hide for that Initiative, and initiativeCapexClaimCreate refuses to anchor a claim there.

The agency / SOW model

CLIENT_BILLING turns an Initiative into an engagement. Instead of CapEx, it carries:

• budgetedCost + budgetCurrency — the SOW value you committed to the client.
• marginPct — your target margin on the engagement.
• Forecast and actual roll up from the child projects exactly as for any other Initiative, but the headline is billed cost vs budgeted cost vs margin, not capitalised vs operational.

This lets a services org and a product org share one platform: the product team runs CAPEX_RD_CLAIM Initiatives for the balance sheet, the services team runs CLIENT_BILLING Initiatives for client P&L, all rolling up from the same project/effort data.

Planned commitment vs actuals

The redesign separates what you committed from what happened:

• Planned commitment sits on the Initiative — committedFte and an aiBudgetAmount, optionally broken out per subject (employee, team, contractor) over a date window via commitments.
• Effort and actuals stay at the Project and roll up to the Initiative.

The headline metric is forecast-vs-actual variance, exposed as Initiative.varianceSummary (forecastCost, actualCost, costVariance, costVariancePct, assignedFte, actualFte, fteVariance).

Initiative
  ├─ plannedCommitment   (committed FTE + AI budget)     ← you set this
  ├─ forecast            (assigned FTE + forecast cost)  ← rolls up from allocations
  ├─ effortActuals       (actual FTE + actual cost)      ← rolls up from effort
  ├─ aiSpend             (AI cost from stamped sessions)  ← rolls up from telemetry
  └─ varianceSummary     (forecast − actual)             ← the headline

All money on these rollups is gated behind FINANCIALS_VIEW_SUMMARY — a viewer without it sees FTE and counts, with cost zeroed.

Objectives and Key Results

Above Initiatives sits a strategy layer: an Objective is the "why", and its Key Results are the measure. The tree is:

Objective (Grow self-serve revenue)
  ├─ Key Result (Self-serve ARR: $4M → $6M, INCREASE)
  ├─ Key Result (Activation rate: 28% → 40%, INCREASE)
  └─ Initiative (Self-serve onboarding)            ← financeMode, cost centre…
       ├─ Project (Signup redesign)                ← synced, adopted
       │    ├─ Allocations  (Growth — 0.6 FTE)
       │    └─ Tickets      (Linear ENG-1203, ENG-1255)
       └─ Project (Billing self-checkout)

Each Key Result has a direction (INCREASE / DECREASE), a targetValue, an optional baselineValue and currentValue, and a derived normalised progress in [0, 1]. An Initiative links to at most one Objective (objectiveId).

Portfolio lens

A portfolio lens classifies an Initiative for finance-sliceable reporting — KTLO, Revenue, Cost-Reduction, Compliance, or whatever categories you define. It is the promotion of the old project "driver type" up to the Initiative grain, so you can answer "how much of the portfolio is KTLO vs revenue-generating?" against the layer that actually carries the money.

Lenses are configured per org (name, category, color, icon, isActive) and assigned to an Initiative via lensId.

Operating model — relabel the nouns

Not everyone calls them "Initiatives". A services org might say "Engagements"; a platform org might say "Programmes". The Operating Model settings let a workspace:

• Relabel the nouns (Initiative / Objective / Project and the finance terms) via entityTerminology.
• Pick a preset (operatingModelPreset) that seeds sensible defaults for an archetype (e.g. internal product company vs agency).

This is purely a presentation + defaults layer — the underlying model is unchanged. See the settings note.

Editing, scenarios, and the API

Initiatives are live finance objects — the human-authored anchor is created and edited directly (not inside a scenario), the same way cost centres and budgets are. The synced projects underneath still respect the live/plan split for allocation changes.

• Concept (this page) — the model.
• Finance → Initiative finance — cost-centre inheritance, CapEx claim flows, variance.
• API → Initiatives — GraphQL types, queries, mutations, error codes.
• Roadmap — how Initiatives and projects show up on the roadmap.

What changed from the old roadmap

The old roadmap had three peer layers — Drivers, Initiatives, Projects — where the project was the unit of cost and carried its own cost centre, and "drivers" were free-floating tags.

The redesign moves finance up to the Initiative and adds a strategy layer above it:

Old	New
Project carries cost centre + CapEx eligibility	Initiative carries them; project inherits via the resolution chain
Synced project immediately costed	Synced project is inert until a human anchors it
"Driver" tags on projects	Portfolio lens on Initiatives (finance-sliceable)
No strategy layer	Objectives + Key Results above Initiatives
One implicit cost model	Finance Mode per Initiative (CapEx/R&D, client-billing, internal)

Drivers (/api/drivers) still exist for project-level tagging where you want it, but the finance-sliceable classification is now the portfolio lens at the Initiative grain.