Core Architecture Sketch¶
Document — instantiates Core Model First
Represents the few essential modules, interfaces, or responsibilities of a design before implementation detail is specified.
A Core Architecture Sketch is a design document that names only the handful of modules a system needs and how they divide the work — who owns what — while deliberately deferring every implementation detail. Its one idea is that the responsibility decomposition is the part that is cheap to change on a whiteboard and ruinously expensive to change once code and schemas have grown around it, so it is fixed first, as a core to which detail is later attached. Where a Minimal Causal Diagram draws the causal wiring of a system-under-study, this sketches the responsibility structure of a system-to-be-built — and its discipline is that each box must earn its boundary.
Example¶
A team is designing the backend for a ride-hailing service. Before anyone chooses a database, writes a retry policy, or picks a deployment topology, an architect sketches five modules on a whiteboard: Rider, Driver, Matching, Pricing, Trip — with a few arrows for the essential handoffs (Matching reads Rider and Driver location; Pricing reads a completed Trip). That is the entire document. Conspicuously absent: schemas, auth, error codes, message queues, which cloud.
The sketch's real work is a gate. Someone proposes a sixth module, "Surge Analytics." The architect applies a decision-relevance test: does splitting it out now change any design choice the team must make this quarter? It does not — surge is a Pricing input for the foreseeable future — so it stays folded into Pricing rather than becoming its own box (a complexity-budget call). In an hour the team agrees on the five responsibilities and the interfaces between them, and every subsequent argument about detail is anchored to a decomposition everyone already shares.
How it works¶
- Name the fewest modules that cover the responsibilities. Each module is a clear owner of one area of the design; anything without a distinct responsibility doesn't get a box.
- Show only the essential interfaces. Draw the handoffs that define the decomposition; leave contract detail for later.
- Hold a budget on the count. Cap how many modules and interfaces the sketch may carry before it stops being a sketch and becomes premature specification.
- Gate every addition on decision relevance. A proposed module or split is admitted only if introducing it now changes a design choice that must be made now.
Tuning parameters¶
- Module granularity — a few broad modules versus many narrow ones. Coarse modules keep the sketch legible but may hide a real seam; fine modules capture structure but drift toward premature detail.
- Interface commitment — whether handoffs are merely named or partly specified. Naming keeps the sketch light; specifying commits you early to contracts that may change.
- Addition-gate strictness — how hard the decision-relevance bar is set. A strict gate keeps the sketch minimal; a loose one lets speculative modules accumulate.
- Notation formality — boxes-and-arrows on a whiteboard versus a formal diagram. Formality aids shared reading but tempts teams to treat the sketch as finished.
When it helps, and when it misleads¶
Its strength is cheap alignment on the expensive-to-change part: module boundaries and responsibilities are the decisions that ramify hardest through a codebase, and settling them on a whiteboard before implementation is far cheaper than renegotiating them after.
Its central failure mode is the sketch being mistaken for a frozen, complete architecture — the big design up front[n1] trap, where a first decomposition drawn to enable conversation gets treated as a binding blueprint. Teams then either over-specify modules for needs they only imagine, or refuse to revise boundaries when reality pushes back. The classic misuse is adding a module for an anticipated-but-unproven future requirement — the very thing the decision-relevance gate exists to stop. The guarding discipline is to keep it a sketch — explicitly revisable — and to require each module to justify its boundary by changing a real, present decision rather than a hypothetical future one.
How it implements the components¶
Core Architecture Sketch fills the module-decomposition side of the archetype — it fixes the responsibility spine and gates what may be added:
core_variable— the essential modules and responsibilities are the core entities of the design; only structurally necessary ones get a box.complexity_budget— an explicit cap on how many modules and interfaces the sketch carries keeps it a spine rather than a specification.decision_relevance_test— each proposed module or split must change a present design decision to earn inclusion.
It does not draw the detailed causal or data-flow relations among components — that belongs to Minimal Causal Diagram — nor validate the design against a reference, which is Baseline Model's job.
Related¶
- Instantiates: Core Model First — Core Architecture Sketch is the archetype's core expressed as a design's essential module structure.
- Sibling mechanisms: First-Principles Model · Baseline Model · Minimal Causal Diagram · Simple Prototype · Stripped-Down Simulation · Minimum Viable Explanation · Toy Model
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Core Architecture Sketch operates as a non-executable information artifact that externalizes static or prospective structure because it represents the few essential modules, interfaces, or responsibilities of a design before implementation detail is specified.
Independent corroboration: The frozen evidence defines Core Architecture Sketch as 'Represents the few essential modules, interfaces, or responsibilities of a design before implementation detail is specified', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Architectural and systems design cohered early schematic decomposition into essential responsibilities and interfaces before detailed realization.
Related originating lineages:
- Computer Science & Software Engineering — Software architecture developed high-level component, responsibility, interface, and interaction sketches as a mature parallel practice.
Review resolution: The minimal responsibility-and-interface sketch is a general engineering-design artifact, while software architecture is a mature convergent lineage rather than the sole origin. The entry's deliberately implementation-agnostic scope supports engineering as primary and multi-domain reach.
Attribution caveat: Physical systems engineering and software architecture developed closely related high-level decomposition sketches.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Big design up front (BDUF) is the anti-pattern of fully specifying a system's architecture before building anything, treating an early sketch as a binding blueprint. A core architecture sketch is its opposite in intent: it fixes only the responsibility spine and stays explicitly revisable, guided by the complementary discipline of YAGNI — "you aren't gonna need it" — against modules added for imagined future needs. ↩