AI project decomposition — natural language to plan

Overview

AI decomposition is how Ravel turns your project intent into an executable plan. You provide a natural-language task description and your department structure — who owns Frontend, Backend, QA, Design, and other tracks. Ravel reads both, then automatically decomposes the work into tasks your teams can actually execute, with dependencies and completion rules wired in.

When you confirm the plan, Ravel emails each department lead their assigned tasks. Owners start with clear scope and context instead of hunting through a shared backlog. The graph remains editable before and after confirm — AI accelerates setup; you keep final say on structure and assignments.

What you provide

Decomposition starts from two inputs: what you are building, and how your org is organized to ship it.

1. Project description — the goal, scope, constraints, deadlines, and anything that must ship together (feature, launch, migration, etc.).
2. Department structure — the teams involved (e.g. Frontend, Backend, QA, Design, DevOps) and who leads each department.
3. Optional context — parallel tracks, tech stack hints, compliance or review gates, and known blockers from past launches.

Ravel uses your department architecture to decide where work belongs. A login feature does not land in a flat ticket list — it becomes Frontend UI, Backend auth API, QA integration testing, and the dependency edges between them.

What AI produces

From your description and departments, Ravel drafts a dependency-aware graph — not a sorted queue. Each proposed task includes:

You review and edit the draft on the graph — rename tasks, adjust dependencies, change completion types, or add missing work. Nothing executes until you confirm.

How it works

1. Open a new project and describe the goal in chat — include scope, deadlines, and constraints.
2. Set up or confirm your department structure and department leads (names and email addresses).
3. Ravel decomposes the project: tasks grouped by department, dependencies drawn between them, completion rules assigned per task.
4. Review the graph — edit tasks, fix dependency edges, and verify owner emails before confirming.
5. Confirm the plan — Ravel emails each department lead their assigned tasks with dependency and due-date context.
6. Execute on the graph; upstream completion unlocks downstream tasks and triggers follow-up notification emails.

Department-aware decomposition

Your department structure is not metadata — it shapes how Ravel splits work. Parallel tracks (Frontend and Backend building in parallel) and sequential handoffs (API before UI integration) both come from matching tasks to the teams that own them.

This is why decomposition produces a graph, not a flat list. Merge points, blockers, and cross-team dependencies are visible from the first draft — the same model Ravel uses during execution when tasks unlock or stall.

Email notification to department leads

Confirmation is the handoff from planning to execution. After you approve the graph, Ravel sends task assignments to department leads and task owners by email — each person receives the work they own, not the entire project dump.

Emails include enough context to start: task title, dependencies, due dates, and how completion is measured. As the project runs, Ravel continues notifying owners when tasks unlock, complete, slip, or hit risk — so leads do not need to poll a board for status.

Intent and org structure first, not tickets

Traditional tools start from empty tickets and manual grooming. Ravel starts from your description and department architecture — then proposes executable tasks, wires dependencies, and distributes assignments by email. The difference is a draft plan in minutes versus hours of backlog breakdown and Slack ping-pong.