The Living Execution Plan
Each Workspace has one Living Execution Plan — the shared, continuously-updated view of what the Workspace is actually doing, who owns what, and what matters right now.
What it is
In Parallel maintains one Living Execution Plan per Workspace. It exists to answer the questions that teams constantly ask — and often can't answer quickly:
What are we actually doing right now?
What matters most?
Who owns what?
What's at risk?
What changed recently, and why?
Unlike a static document or a project board, the plan is designed to stay truthful as work evolves. It updates from meetings, connected systems, and your review — not from someone manually rewriting it.
What's in the plan
The plan organizes execution reality in a hierarchy: Goals → Priorities → Activities, with obstacles and owners attached at each level. Goals anchor direction. Priorities rank what matters most. Activities are the concrete work being executed.
Two principles keep the plan legible at scale:
The 30-second rule — the plan's current state should be readable in under 30 seconds. If it can't be, the Workspace is carrying too much detail or is too broad.
Top 3 priorities — the plan surfaces the three highest-priority items prominently. This forces real ranking rather than everything becoming equally urgent.
Section | What it shows |
Goals and commitments | The outcomes the Workspace is accountable for — anchors the plan so priorities don't drift into activity without direction |
Priorities | What matters most right now, ranked — forces tradeoffs and prevents everything from becoming urgent |
Tasks and milestones | Concrete work and checkpoints at a high-signal level — delivery detail stays in Jira/Asana/etc. |
Risks and dependencies | Blockers, constraints, cross-team dependencies, and confidence issues |
Ownership | Who is accountable for each area — explicit, never implied |
Recent changes | What shifted in the plan and when — so change is visible and reviewable rather than silently overwritten |
Observation widgets on the dashboard have an arrow (→) in the widget header that links directly to the relevant Findings list for that observation type.
Diagrams inside the plan
When a visual makes the plan easier to read, In Parallel embeds Mermaid diagrams directly in the plan document. The AI planner uses them most often to show:
Dependency graphs — which teams, decisions, or deliverables block each other, often with status-labeled edges ("Resource Dependency — Blocked", "Outgoing — At Risk"). Useful for seeing at a glance where a Workspace is held up and by whom.
Phase sequencing — step-by-step gates like an A/B ramp (10% → 50% → go/no-go → 100% → launch) or a cross-team handover flow.
Cross-cutting work lanes — independent chains that converge on the same milestone (for example, supply-chain confirmation and support-team hiring both feeding into a campaign launch).
The diagram is part of the plan document, not a separate widget. It updates as the plan updates — re-rendering to reflect the current set of dependencies, blockers, and phases. You don't maintain it by hand.
You can also insert a Mermaid diagram yourself anywhere in the plan document: type / in the editor and choose Mermaid, or select an empty code block and use the bubble-menu action. Manual diagrams sit alongside AI-generated ones.
How it stays up to date
Three mechanisms keep the plan current:
Meeting Intelligence Pipeline — the Transcriber captures signals from each connected meeting; observations become structured proposals delivered as a changelog To-Do for you to approve or reject
Connected tools — your calendar and connected communication tools feed signals into the plan
Drift Detection — the AI compares stated priorities against observed activity and surfaces divergence before it compounds into a larger problem
Meetings produce signals. When the Transcriber joins a connected recurring meeting, it captures decisions, actions, risks, and ownership shifts — and links them to the Workspace as execution signals, not meeting notes.
Reports turn signals into structured outputs. After each meeting, a post-meeting report is published and a changelog To-Do appears on your Personal Dashboard. You review the proposed changes, approve or reject individual observations, and only approved items update the plan. Tasks are assigned and stakeholders can be notified.
Human review keeps it trustworthy. Nothing material changes silently — every meeting changelog requires explicit approval before the plan updates. You can approve or reject observations individually, so you stay in control of what enters the plan. Email and attachment changelogs remain auto-approved. This is what makes the plan durable: it's a traceable evolution, not whatever someone last edited.
Weekly review habit
A strong weekly review takes minutes and prevents drift.
Review what changed. Scan what moved in priority, what changed in risk, what shifted in ownership, and what new actions appeared since the last session.
Confirm priorities still match reality. Ask: are we working on the right things? Is the ranking honest? Has anything become urgent that isn't reflected yet?
Scan risks and dependencies. Identify anything that needs a decision, cross-team coordination, or escalation.
Close loops. Confirm that actions have owners, blocked items are explicitly marked (not silently stalled), and completed items are closed.
Tip: If you review the plan weekly and confirm after key meetings, clarity compounds quickly — the plan becomes the default answer to "what's happening?" rather than something you reconstruct each time.
Related