Initiatives

An Initiative is the thing a human decides to fund, and the layer finance reads: its status, resourcing, effort, forecast, variance and capitalisation are all rolled up from the projects beneath it. A Project is the unit of delivery — an epic in Jira, a project in Linear, an area path in Azure DevOps, or one created by hand — and it is where the cost centre, the resourcing and the AI workforce are configured.

Superseded

An earlier iteration of the roadmap redesign made the Initiative the finance anchor: it carried the cost centre, and a project inherited it. That was reversed — the project is the thing people actually deliver, resource and classify, so the cost centre belongs to it. An Initiative has no cost centre of its own. See the 2026-06-22 entry in the changelog.

A project is still inert until a human takes responsibility for it — either by giving it a cost centre directly, or by adopting it into an Initiative.

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	Governance + reporting roll-up	Where delivery and finance are configured
Carries	Finance Mode, SOW budget + margin, committed FTE, AI budget, portfolio lens, objective, completion cost centre	Cost centre, allocations, AI workforce, 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 finance object on its own cost centre.
2. Adopt it into an Initiative — a human has taken responsibility for it, so it is no longer inert. Its cost centre is still its own (or the one stashed at adoption); what the Initiative adds is the reporting roll-up and, for client work, the Finance Mode.

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 — and it is a project answer. An Initiative has no cost centre to consult:

1. The project's own cost centre, when set.
2. Otherwise → the dormantCostCentre stashed when it was adopted.

LiveProject.costCentreId          (preferred)
        │
        └─ (null — the project is adopted)
                          ──► LiveProject.dormantCostCentreId  (fallback)

When a project is adopted, its own costCentreId is stashed into dormantCostCentreId and nulled; resolution falls through to the stash, so the same centre keeps governing. Detaching restores it to costCentreId intact. See Finance → Initiative finance for the full mechanic.

The derived capitalisable flag follows the category of that resolved cost centre: capitalisable = !isInert && resolved centre is capex-category. The Finance Mode does not enter into it.

Finance Mode

Every Initiative has a Finance Mode, and it governs client billing only:

Finance Mode	What it is	canBill	showsMargin
CLIENT_BILLING (Customer billed)	Agency / SOW — billed to a client with a margin	✅	✅
INTERNAL_COST (Internal)	Not billed to a customer	—	—

canCapitalise and canRdClaim are not driven by the mode — they follow the resolved cost centre's category, in either mode. The capability object is surfaced on the API as Initiative.financeModeCapabilities (canCapitalise, canRdClaim, canBill, showsMargin, showsBilling); for an Initiative, the CapEx pair is true when any child project's resolved cost centre is capex-category.

CAPEX_RD_CLAIM is legacy

CAPEX_RD_CLAIM remains in the enum only because Postgres enum values cannot be dropped safely. Every row was data-migrated to INTERNAL_COST and the value is never written again. Do not branch on it.

Client billing no longer suppresses CapEx

An earlier iteration made CLIENT_BILLING mutually exclusive with capitalisation. It is not: a Customer-billed Initiative whose projects sit on a CapEx-category cost centre can still capitalise and claim R&D. Eligibility is a cost-centre question, billing is a mode question, and they are independent.

The agency / SOW model

CLIENT_BILLING turns an Initiative into an engagement, carrying:

• 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.

This lets a services org and a product org share one platform: the product team reads capitalisation off its projects' cost centres, the services team runs CLIENT_BILLING Initiatives for client P&L, all rolling up from the same project and 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 (Settings → Resourcing → Operating Model, /settings/resourcing/operating-model) 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 adds a strategy layer above the Initiative and makes the Initiative a reporting roll-up, while leaving the cost centre on the project:

Old	New
Project carries cost centre + CapEx eligibility	Project still carries the cost centre; eligibility follows its category, and the Initiative reports the roll-up
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, for client billing

An interim iteration also moved the cost centre itself onto the Initiative; that was reversed on 22 June 2026 (see the note at the top of this page).

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.