Skip to content

Functional Decomposition Workshop

Facilitated method — instantiates Inventory-Bounded Resource Recomposition

Translates the mission into required functions and performance thresholds — deliberately before looking at the stock — so on-hand resources can be matched by what they can do, not by what they are labelled.

Recomposition fails at the start when people reach for the thing that usually does the job and find it missing. Functional Decomposition Workshop breaks that reflex by working the problem from the function side first: a facilitated session that restates the mission as a tree of required functions — each with an explicit performance threshold — plus the invariants the solution must never violate, all before anyone inventories what is on hand. Its defining move is the deliberate separation of "what must happen" from "what we have": by naming a requirement as "raise 200 L of water to 70 °C for 30 minutes" rather than "the boiler," it turns a missing labelled object into a specification that many unlabelled resources might satisfy. The workshop produces the target the rest of the archetype matches against; it never touches the stock itself.

Example

A relief team reaches a flooded district a week ahead of resupply and must make river water safe to drink. The instinct is to ask for the water-treatment unit that isn't coming. Instead the team runs a Functional Decomposition Workshop. They restate the mission — "potable water for ~500 people/day" — and decompose it into functions with thresholds: remove suspended solids (turbidity below a stated target), inactivate pathogens (a required log-reduction), store treated water without recontamination (a sealed volume for a day's supply), and dispense at point of use. Against each function they mark the invariants that must hold no matter what is substituted in: no chemical dose above the safe residual, no cross-connection between raw and treated lines.

The output is a one-page function-and-threshold map, not a shopping list. It is what lets the next steps notice that a bank of settling drums can meet "remove suspended solids," that a rocket stove and a thermometer can meet "inactivate pathogens" by pasteurisation, and that clean fuel jugs can meet "store without recontamination" — matches nobody would have seen while still asking for the missing treatment unit.

How it works

  • State the mission and its sufficiency bar. Write the outcome and the level at which it counts as good enough, so the decomposition aims at adequate, not ideal.
  • Decompose into functions, not components. Recursively split the mission into the functions that must be performed, phrased as verbs on quantities, and hang a measurable threshold on each leaf.
  • Mark the invariants. For each function, record what must remain true under any substitution — the safety, legal, or integrity conditions that bound later improvisation.
  • Stop at the capability boundary. The workshop deliberately ends before matching resources; handing an unlabelled specification downstream is the whole point.

Tuning parameters

  • Decomposition depth — how finely functions are split. Deeper trees expose more substitution opportunities but cost time and can fragment a job better satisfied whole.
  • Threshold strictness — how demanding each performance bar is set. Tight thresholds protect quality but shrink the set of on-hand resources that qualify; loose ones widen the match at the risk of an inadequate result.
  • Invariant scope — how many conditions are declared non-negotiable up front. More invariants make later improvisation safer but more constrained.
  • Abstraction level of function names — how far the wording is pushed from familiar objects. More label-free phrasing surfaces more latent affordances but makes the map harder for the team to read.

When it helps, and when it misleads

Its strength is that it dissolves functional fixedness — the trap of seeing a resource only in its habitual role — by forcing every requirement into label-free, capability-based terms, which is exactly what makes a heterogeneous stock look richer than a parts list suggests.[1] It also front-loads the safety invariants, so improvisation later happens inside stated bounds rather than in the dark.

Its failure modes are quieter. A decomposition can be too clever — abstracting a function so far that the threshold loses meaning, or splitting into so many leaves that a naturally integral job is farmed out to mismatched parts. It can also smuggle the missing ideal back in through a threshold set at the ideal product's spec rather than at true sufficiency, which quietly disqualifies every substitute — the workshop run backwards to prove nothing on hand will do. The discipline that guards against this is to anchor every threshold to the mission's sufficiency bar, not to the absent product, and to treat the map as a hypothesis the later build-and-test steps are allowed to correct.

How it implements the components

Functional Decomposition Workshop realises the target-definition side of the archetype — the components that say what must be achieved, not what to achieve it with:

  • mission_and_sufficiency_criterion — its opening act: the mission stated together with the level at which it counts as good enough.
  • functional_decomposition_map — its primary output: the tree of required functions, each carrying a measurable performance threshold.
  • preserved_invariant_set — the conditions each function must never violate under substitution, recorded up front to bound later improvisation.

It deliberately does not map or assign resources — resource_affordance_map belongs to Affordance Inventory Walkthrough and Capability Catalog, and resource_to_function_assignment to the Fixed-Inventory Configuration Sprint and Cross-Training and Role Reassignment. The workshop supplies the specification those mechanisms fill.

Notes

The workshop is an input, not a build: it is finished when the target is clear, and it says nothing about feasibility. Keeping it separate from resource mapping is deliberate — a team that decomposes and inventories in the same breath tends to stop at the first familiar object and re-import the very fixedness the workshop exists to break.

References

[1] Functional fixedness, from Karl Duncker's problem-solving studies, is the tendency to see an object only in terms of its conventional use. Restating requirements as label-free functions is a standard counter, which is why the workshop phrases every leaf as a capability rather than a component. ↩