How to develop and assess problem decomposition in AI-enabled work

Decompose around outputs and dependencies

NASA’s Systems Engineering Handbook describes logical decomposition as using functional analysis to build a system architecture and emphasizes that decomposition is creative, recursive, collaborative, and iterative. GOV.UK discovery guidance recommends understanding the problem and goal, breaking down assumptions, and asking questions before starting to build.

For knowledge work, a useful decomposition is not a longer to-do list. Each part should have a purpose, required input, observable output, dependency, owner, and verification route. If the pieces cannot be recombined into the required decision or deliverable, the task has been fragmented rather than decomposed.

Use the PARTS decomposition map

Create one PARTS map for a complex assignment:

| Field | Question | Evidence artifact | | --- | --- | --- | | Purpose | What whole outcome or decision must the work support? | One-sentence mission and acceptance condition | | Activities | Which distinct transformations turn inputs into outputs? | Work packages expressed as verbs and objects | | Relations | Which inputs, outputs, and assumptions connect the packages? | Dependency arrows and interface notes | | Tests | How will each package and the integrated result be checked? | Local checks, integration checks, and reviewer | | Seams | Where could information, ownership, meaning, or timing be lost between packages? | Named handoff risks and controls |

Start with the final artifact and work backward. Identify the decisions, calculations, evidence collections, comparisons, and communication steps needed to produce it. Then work forward to confirm that every package receives the inputs it needs and produces something another package or the final artifact actually uses.

An AI assistant can suggest subtasks or parallel research routes. Treat those suggestions as a draft architecture. Check for missing dependencies, duplicated work, incompatible definitions, premature conclusions, and seams where generated content could pass into the final artifact without review.

Worked example: a synthetic demand-forecast investigation

Consider a synthetic operations analyst asked to explain why a quarterly demand forecast missed actual volume and recommend a planning adjustment. The evidence pack contains forecasts, actuals, promotion dates, region definitions, inventory notes, and an email blaming a new model. This example is original and does not describe a Two Prune customer.

The first AI-generated plan says: clean data, analyze variance, identify causes, and write recommendations. These headings are too broad to expose dependencies or verification. The participant builds a PARTS map with seven packages:

The relations matter. Package two cannot be trusted until package one resolves a region-code change. Package five needs the reconciled time series and the documented model-change date. Package six consumes outputs from stockout, promotion, and model analyses rather than asking AI to invent a single cause. Package seven requires both local findings and an integration check that totals still reconcile.

The seam register identifies a further risk: the promotion file uses campaign weeks while the forecast uses calendar weeks. The participant creates a mapping table, records two uncertain dates, and prevents those cases from being used as definitive causal evidence. The recommendation becomes a bounded monitoring adjustment, not a claim that the model alone caused the miss.

• reconcile forecast and actual periods, units, and region definitions;
• calculate variance by product, week, and region;
• identify where stockouts make observed sales an incomplete demand measure;
• align promotion and pricing events to the variance periods;
• test whether the model-change date coincides with the largest errors;
• compare alternative explanations and record unresolved evidence;
• assemble a decision note with a proposed adjustment, limits, and next measurement.

Choose the right level of decomposition

Stop dividing when a work package has a clear input, one accountable output, a manageable method, and a check that can reveal failure. A package is still too large when it contains several independent judgments or produces multiple outputs with different reviewers. It is too small when coordination costs exceed the value of separation or when no meaningful check exists at that level.

Use three tests:

Parallel work is appropriate only where dependencies allow it. Independent source collection may run concurrently, while causal comparison must wait for reconciled data. AI delegation should follow the same rule. Fast parallel generation creates rework when every task assumes a different definition or evidence baseline.

• cohesion: the steps inside a package serve one output;
• coupling: dependencies between packages are explicit and limited;
• coverage: all acceptance conditions and material risks are addressed somewhere.

Practice with a missing-seam exercise

Give a learner a complex brief plus several documents with mismatched definitions. Ask for a PARTS map, then remove or alter one upstream input. The learner should identify which packages become blocked, which outputs remain usable, and which claims need revision.

Add one deliberately tempting subtask that does not contribute to the final decision. A strong learner will remove it or explain why it belongs outside scope. Add another task that appears independent but shares a definition or denominator. A strong learner will make the interface explicit before parallelizing it.

The practice artifact should include the dependency map, package outputs, seam register, and integration checklist. This makes the decomposition reviewable rather than leaving it as private intuition.

Assess the process and the integrated result

In an assessment, use a task that requires several evidence types and at least one consequential handoff between steps. Observe whether the participant:

Do not equate the number of subtasks with quality. Ten vague prompts can be weaker than four well-designed packages. Do not infer decomposition skill from a polished final document alone because hidden integration errors may survive fluent writing.

• anchors the breakdown to the final decision or deliverable;
• creates packages with distinct inputs, outputs, and owners;
• sequences dependent work and parallelizes only independent work;
• identifies shared definitions, assumptions, and data transformations;
• assigns local checks and a final integration check;
• notices seams where evidence or meaning could be lost;
• revises the structure when a dependency or missing input appears;
• uses AI for bounded components without outsourcing integration judgment.

Verify through recomposition

Rebuild the final reasoning from the package outputs. Every material statement should have a route through the dependency map to an input and a check. Recalculate totals or reconcile definitions at seams. Look for orphan outputs that no decision uses and final claims that no package produced.

Then ask whether the decomposition preserved uncertainty. If packages produced conflicting results, the integrated artifact should show the conflict rather than smoothing it away. If an upstream assumption changes, trace which outputs and recommendations must be recalculated.

Problem decomposition is task-dependent and does not establish general intelligence or future performance. In a Two Prune assessment, the map, work sequence, AI use, checks, revisions, and final artifact can contribute bounded evidence about Context Framing, AI Orchestration, Verification & Risk Control, and Judgment & Synthesis. They do not make an employment decision.

Sources

NASA Systems Engineering Handbook

• NASA System Design Processes: Logical Decomposition
• GOV.UK guidance on the discovery phase

Sources: [1] [2] [3]