Design Model¶
Artifact — instantiates Essential Structure Extraction
Shows the functional structure of a proposed solution without every implementation detail.
A design model shows the functional structure of a proposed solution — its parts, what each part is responsible for, and how they work together to produce the intended behavior — while deliberately deferring implementation detail and keeping a record of what was deferred. Its defining move is that it is prescriptive: it describes a thing that does not yet exist and is organized around function and responsibility ("what each part must do"). That makes it descriptively different from a Conceptual Model, which captures a domain that already exists, and structurally different from a High-Level Architecture Diagram, which maps a system's components and dependencies for architectural decisions rather than laying out functional responsibilities and the implementation it leaves open.
Example¶
An engineer is designing a new electric kettle and sketches its functional model before ordering a single part. The blocks are functions with responsibilities: a water reservoir holds and exposes the water; a heating element adds energy; a temperature sensor reads the water's state; a control cuts power when the water reaches boil; a dry-boil safety cutoff interrupts everything if the reservoir runs empty; an indicator signals state to the user. The relations are the interactions — the sensor informs the control, the control gates the element, the safety cutoff overrides both.
Held explicitly open — and written into an omitted-detail log — are the implementation choices: the element's wattage, the plastic grade of the housing, the exact thermostat part number. The value of the artifact is that the team can agree the solution's function is sound (the water heats, boil is detected, dry-boil is safe) before anyone commits to a bill of materials, and the log states precisely which decisions are still owed.
How it works¶
Enumerate the functions the solution must perform; assign each to a block with a clear responsibility; wire the functional interactions among the blocks. Then deliberately defer the implementation choices and log them as open, and check that the functions compose into the intended behavior. The distinctive property is that a design model is organized by the function and responsibility of a proposed artifact, and that its deferrals are tracked rather than merely forgotten — the log is what separates a principled abstraction from a hopeful sketch.
Tuning parameters¶
- Functional granularity — coarse blocks versus fine sub-functions. Finer surfaces more design risk early and multiplies the interfaces you must specify.
- Behavior versus structure emphasis — how much of the model captures dynamic behavior (sequences, state changes) versus static block structure.
- Deferral depth — how much implementation detail is logged-as-open versus pinned now. Deferring more keeps the model clean but grows the pile of unresolved decisions.
- Interface strictness — how tightly each block's responsibility and boundary are defined. Tight interfaces let functions be designed independently; loose ones invite the blocks to leak into each other.
When it helps, and when it misleads¶
Its strength is that it lets a team confirm a solution's function is coherent before sinking cost into building it, and the omitted-detail log keeps the deferrals honest rather than lost. Its failure is oversimplification: a functional model that "works on paper" but hides an implementation reality that breaks the function — a thermal, timing, or tolerance fact the abstraction assumed away — so the gap between the elegant design and a buildable thing only appears at manufacture.[n1] The guarding discipline is to keep the omitted-detail log live and resolve each open item before committing to build, and to prototype the functions whose feasibility the model is quietly assuming.
How it implements the components¶
essential_variable— the functional blocks and their responsibilities are the essential parts of the proposed solution.relation_preservation— how the functions interact (sensor → control → element, with the safety cutoff overriding) is carried as the model's core content.omitted_detail_log— the implementation choices deferred for later (wattage, materials, part numbers) are recorded as explicitly open, not silently dropped.
A design model prescribes a proposed solution's functions and logs its deferred implementation; it does NOT map the deployed system's components and dependencies at a decision altitude, nor define when to drill into a component (detail_reintroduction_trigger) — that is its nearest twin, High-Level Architecture Diagram. And unlike Conceptual Model, it describes something not yet built rather than a domain that already exists.
Related¶
- Instantiates: Essential Structure Extraction — extracts the functional skeleton of a solution ahead of its implementation.
- Consumes: Conceptual Model — a design model is built in the vocabulary of the domain concepts the conceptual model settles.
- Sibling mechanisms: Conceptual Model · Simplified Diagram · Core Schema · Problem Abstraction · Mathematical Idealization · High-Level Architecture Diagram · Executive Summary
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Design Model operates as a non-executable information artifact that externalizes static or prospective structure because it shows the functional structure of a proposed solution without every implementation detail.
Independent corroboration: The frozen evidence defines Design Model as 'Shows the functional structure of a proposed solution without every implementation detail', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Engineering design cohered prescriptive functional models that assign parts responsibilities while deliberately deferring implementation detail.
Related originating lineages:
- Architecture & Urban Planning — Architectural schematic design supplied function-first representations of proposed form.
Review resolution: Engineering design cohered prescriptive functional models that assign parts responsibilities while deliberately deferring implementation detail. The retained alternate lineages materially shaped the mechanism's form.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] "Form follows function" — Louis Sullivan's principle that a thing's shape should be dictated by what it must do. A design model works at the "function" layer on purpose; its risk is that the form eventually required to realize the function turns out to violate an assumption the model made. ↩