Initiatives

Beta

An Initiative groups related Projects so a workspace can inspect sequencing, scope, and roadmap state together. Initiatives are planning containers; they do not replace the Project lifecycle packet.

Open Spec-Driven Development -> Initiatives to see the full-width Initiative table.

What an Initiative is for

Labels are available as an Initiative filter, display property, and grouping field. Persisted table-control state stores label ids rather than copied names or colors.

Use an Initiative for work such as:

• a product area or delivery theme
• a release slice
• a dogfooding effort
• a dependency cluster that needs one shared explanation

The Initiative table shows current roadmap containers and summary context such as owner, target timing, completed-over-total Project counts, health, and active Project counts. Rows show the Initiative name; turn on the Slug display property to show each Initiative's stable slug beside it when same-named Initiatives need telling apart. When an Initiative has relations, one badge sits immediately after its name: the red number counts blockers that are still open, then come the number of Initiatives it blocks and the number of related Initiatives. When an Initiative has more than five blockers, the closed badge shows how many blockers it has in total; open the badge to see how many are still open. Click the badge to see a list for each with every Initiative's status; open blockers come first, finished ones are greyed, and restricted Initiatives show only a restricted icon. The table has Active, Planned, and Completed status badges. Completed is a planning status, not an archive: a completed Initiative stays a normal, editable Initiative.

The Projects column shows completed Projects over the Projects still in scope. Canceled Projects leave the scope, so an Initiative with four Projects, one completed and one canceled, shows 1 / 3. Click the count to open a card with the completed percentage, a progress bar, and up to four Projects still to do in the Initiative's saved order. Each row shows the Project's position and, when it has dependencies, its step, the same values as the Projects table, and links to the Project. The card also says how many more Projects remain and how many canceled Projects were left out.

Initiatives support creation, editing, and planning-status changes, and can be archived, deleted, and restored (see Archive, delete, and restore). Unlinking a Project from an Initiative keeps both the Initiative and the Project, and the Project's Issues remain independent work.

Right-click any Initiative row and open More properties -> Rename to change its name in place. The reusable Initiative row menu follows the table into its main, workspace-view, and Team-view contexts. The command selects the current name and focuses Rename first, so typing and pressing Enter is enough to save; arrow keys move between Rename and Cancel, and Escape closes the command. Rename appears only after Integrity confirms metadata edit capability, updates visible Initiative readers optimistically, and preserves the Initiative's stable URL slug.

Initiative filters narrow the current table in the browser. Supported filters include Owner, Creator, Team, Labels, Health, Dates, Blocked by, Blocking, Related, and With relations. Display grouping can shape the rendered sections by Owner, Team, or Labels, while Health grouping remains disabled until that product model exists. An Initiative with several labels appears in every matching label group, while unlabeled Initiatives appear under No labels. When grouping is active, the Grouping row exposes a settings icon that opens an in-menu ordering view with a back button, vertical-only drag ordering, static owner avatars or Team icons, row-body drag handles, and eye toggles for whether each group is visible in the table. Show empty groups appears only when grouping is selected; when it is off, groups with no visible Initiatives in the current scope are omitted. Display ordering can sort by Name, Manual, Health updated, Updated, or Target date; sortable column headers update the same ordering state shown in the Display options menu. Rows with equal ordering values keep their stable table position instead of jumping after unrelated edits.

Active, Planned, and Completed are fixed status scopes that every workspace has. Workspace members can also save their own views: select Add view beside the scope badges, choose filters and a layout, name the view, and save it. The saved view appears as another tab on the Initiative table and as a Workspace Initiative view in Views, where you can edit, duplicate, or archive it.

Active filters appear as compact predicate chips above the table. Removing the last chip removes the filter bar. If filters produce no matches, the table shows a search empty state while keeping the filter bar available for changes. When filters or display options hide rows while the table still has visible content, a bottom footer summarizes hidden counts; Show options opens Display options, and Clear Filters clears the active filter chips.

Row selection is session-only and appears after Integrity confirms Initiative metadata edit authority. Select visible Initiative rows with the row checkboxes, use Shift-click to select a visible range, and open Actions from the floating selection bar for supported existing edits such as Status and Owner. Selection follows the visible table scope and is not stored in browser-local table drafts, shared defaults, saved views, or URLs. Creating a new Initiative label from that bar additionally requires label vocabulary management authority; assigning an existing label uses metadata edit authority.

Initiative filter, grouping, group order, hidden group values, show-empty-groups preference, ordering, and display-column drafts are remembered in the current browser per workspace, user, and fixed status badge. Active, Planned, and Completed can each restore their own draft table lens, including visible columns. Team filters and group lenses store stable accessible Team IDs only; private or no-longer-accessible Team values hydrate as generic private/unavailable states or are dropped instead of exposing labels. The badges remain fixed table scopes, not user-created saved views. When the page opens, Integrity waits for that local draft lens before showing rows, so users do not briefly see the default unfiltered table before their browser-local scope restores.

Each fixed Initiative scope can also have a shared display default. In the Display options menu, Reset to default restores that scope's shared default display lens, while Set Default for Everyone lets authorized users save the current grouping, group order, hidden group values, show-empty-groups preference, ordering, and display properties as the workspace default for that specific scope. Shared default changes apply to other open tables for that same scope after realtime/refetch, while active filter chips stay private. Setting the default for Active does not change Planned or Completed.

Initiative detail page

Selecting an Initiative from the dedicated table opens a detail page at /workspace/[workspaceId]/initiatives/[initiativeSlug]. The page uses the same Spec-Driven Development shell as Project detail pages: a compact breadcrumb/action bar, a stable route, a main planning surface, and a collapsible properties panel with Initiative metadata.

Workspace members can create Initiatives and update an Initiative's name, short description, icon color, Status, Owner, Team, and Target date from the detail page when the named capabilities allow it. A creator can assign only Teams they can access. These are quiet inline edits: the changed value appears immediately, and Integrity only shows an error toast if the update fails. When edit authority is unavailable, the values render without edit menus. A workspace member who cannot access an associated private Team can still read the Initiative, while the Team value appears only as a generic private Team reference. A Team viewer who is also a workspace member retains workspace-level Initiative metadata authority.

The Initiative name and short description are intentionally constrained. Names must be 2-120 characters. Descriptions are single-line, optional, and limited to 250 characters. Over-limit paste or typing attempts are rejected with inline feedback instead of being truncated and saved.

Initiative V1 properties are deliberately small:

Status and Team use the same compact selector grammar in the Initiative table and properties panel. Planned uses the Target glyph, Active uses CircleChevronUp, and Completed uses CircleCheck. Accessible Team values link to the stable Team route; hidden private Team values do not link. Derived Project counts and health remain table/model context rather than properties-card rows.

Editable roadmap fields are only presented to users who can save them. Initiative Labels use a separate workspace vocabulary and appear in the properties panel and table controls. People who may edit Initiative metadata can assign existing labels through the shared selector; labels can also filter, group, or appear as a display property in the Initiative table. Workspace admins manage the vocabulary from the Labels card at the bottom of Initiative settings. The settings History action opens Workspace Settings -> Audit log filtered to Initiative-label configuration; assigning or removing labels on an Initiative remains Initiative Activity. The Initiative Properties + and row More properties -> Relations submenu can add Related, Blocked by, or Blocking links to other Initiatives. Dependency target search includes both the Initiative name and slug; restricted or unavailable targets retain their safe fallback instead of exposing either value. Existing relationship rows can be changed or removed after server confirmation. The add menu remains relationship-specific; Initiative V1 does not support arbitrary custom properties, Slack behavior, or phases.

The main Initiative canvas has three parts:

• Non-empty Blocked by, Blocks, and Related groups appear before Resources, with canonical routes for accessible Initiatives and safe non-routing restricted references.
• Resources lists supporting links, private attachments, and collaborative Documents that inherit Initiative access.
• Summary is the Initiative's primary collaborative narrative document.
• Projects embeds the Initiative-scoped Projects table with the same display options, grouping, ordering, and display-property grammar as the main Projects table. The plus action creates a Project in this Initiative after Project creation authority is confirmed; the section also offers an authorized picker to attach an existing Project.

The embedded Projects table uses the same session-only selection behavior as the main Project table, scoped to the current Initiative. Hidden or filtered-out rows are pruned from selection rather than kept for later actions.

Roadmap graph, Gantt, outline, log, notes, decisions, Health, authored updates, subscriptions, and activity behavior still live in existing or future Planning surfaces until their dedicated work lands.

Relationship add, change, and remove actions create endpoint-relative Activity for both Initiatives. When a blocking Initiative becomes Completed or Canceled, each incoming dependency becomes Related and receives one Activity event per endpoint. This leaves the dependent Initiative status, dates, health, progress, notifications, inbox, unread state, and email delivery unchanged. Reopening the blocker leaves the pair Related.

Archive, delete, and restore

An Initiative has a lifecycle that is separate from its planning Status. Archiving keeps it as a readable record outside active planning; deleting hides it from active work while it can still be restored; permanent deletion removes its own content for good.

Initiatives archive automatically after 30 untouched days by default, once their Status is Completed or Canceled and every member Project is archived. There is no manual Archive action. A workspace administrator can change the delay or turn it off under Workspace Settings → Initiatives → General → Automation.

Open … → Archived Initiatives on the Initiatives table, at /initiatives/archived, to find archived work. Its normal page keeps the Status, linked Projects, Resources and Activity history read-only. You cannot edit, comment, or change Project membership until you choose Restore in the banner. Restoring starts a new inactivity delay. See Archive and delete for automatic archive, release timing and recovery.

Deleting an active or archived Initiative moves it to Deleted initiatives for 30 days. A deleted Initiative is read-only and can be restored by any workspace member; restoring returns it to its former state (active or archived, with the original archive date), keeps the Teams and labels that still exist, and drops dependency links whose other Initiative is no longer active. If every Team the Initiative belonged to has been archived, restore is refused until a Team is restored. Linked Projects stay live through archive and delete: only the Initiative's own membership is affected, never the Project itself.

Workspace owners and admins can permanently delete a deleted Initiative from the Deleted list or the detail page. This removes the Initiative's Summary and documents, attachments, saved views, labels, favorites, dependencies, Project memberships, and its Activity comments and reactions, and leaves a generic Deleted Initiative reference in history. Its old link no longer opens anything, and the name may be reused by a new Initiative. Initiatives that stay in Deleted for 30 days are permanently deleted automatically.

While an Initiative is archived or deleted it sends no update reminders. Archiving moves its activity and reminder rows out of your active Inbox; deleting also moves mentions and replies about it. Neither changes whether you read a row, restoring brings none of them back, and reminders resume on its schedule. After permanent deletion, a Meeting Minute that linked the Initiative in Linked context keeps the link but no longer shows its name.

Connected coding agents can prepare unarchive, delete, restore and permanent delete with a confirmation that shows the affected work before it is applied. Asking an agent to archive an Initiative returns guidance about automatic archive without changing the Initiative.

Initiative membership

Projects can belong to Initiatives through roadmap membership state. One membership is the Project's home placement. Additional memberships are references so the same Project can appear in more than one planning context without becoming duplicate work.

Removing a Project from an Initiative other than its home changes only that membership, and the Project keeps its home Initiative, even when that home is archived or deleted. Removing a Project from its active home Initiative leaves it without a home. A Project cannot be removed from an archived or deleted Initiative itself; unarchive or restore that Initiative first.

Each Initiative keeps its own order of Projects and shows the dependency step of each one. See Project order and Flow to reorder Projects, group them by step, and read the Initiative as a Flow.

When a Project in an Initiative is archived or deleted, it leaves the Initiative's Projects, counts, and order, and the remaining Projects number without a gap and can still be reordered. Restoring the Project brings it back to its previous place in the Initiative. Permanently deleting it removes it from the Initiative and from the Initiative's history; the Initiative and the Project's Issues are not deleted.

Integrity owns current Initiative membership and planning state. Coding agents read that canonical scope instead of treating an external planning document as the current membership list.

Integrity also owns the connected backlog, priority, owners and planning dates. Initiative Owner and Target date are the in-product planning fields; the Planning target-date picker supports day, month, quarter, half-year and year values.

Roadmap views

Opening an Initiative from roadmap context shows the current planning roadmap views:

The later timeline/Gantt redesign is separate work. The current views are useful for traceable context, but they are not a full scheduling engine.

Review the whole Initiative

An alignment review checks whether the Initiative's Projects cover its goal and have clear boundaries and handoffs. An integration review checks whether their finished workflows work together. For example, a Project that saves a view and another that reopens it may each pass review while the saved filters still fail to reach the reopened view.

The Integrity coding plugin no longer runs these reviews. The optional checkpoints that ran them were retired on 2026-10-13 with the earlier plugin that provided them, and completing an Initiative through the plugin no longer waits for one. You can still write an alignment or integration assessment in an existing Initiative document or Update; approving it, accepting the result and completing the Initiative stay separate decisions.

Related