ES-105 — Design and Technical Decisions¶
You are here¶
ES-104 defined the architecture: system context, components, boundaries, evidence flow, quality strategies, AI controls, and major architectural decisions.
ES-105 turns that architecture into implementation-ready design.
Architecture allocates responsibility across the system. Design makes those responsibilities concrete enough that implementation can proceed without guessing. It defines the interfaces, data structures, workflows, controls, error behavior, and technical decisions that developers will rely on.
Why this stage exists¶
Teams often jump from architecture directly into coding. That feels productive, but it usually pushes design decisions into the least visible place: implementation.
When design is skipped, teams discover too late that interfaces are ambiguous, data structures do not preserve evidence, access-control rules are inconsistent, AI output can bypass review, exception paths are undefined, and testing cannot trace behavior to an expected design.
ES-105 prevents those failures by making design evidence durable before implementation readiness begins.
The engineering question¶
What design decisions, interfaces, data structures, workflows, and controls are required to implement the architecture responsibly?
Design as engineering translation¶
ES-105 translates architecture into concrete engineering choices.
Architecture says where responsibility lives. Design says how that responsibility will be realized.
For trustworthy intelligent systems, design must preserve architectural intent in the details that implementation teams use every day: APIs, state transitions, data records, authorization checks, AI review behavior, error handling, and evidence creation.
What you will produce¶
ES-105 produces project artifacts under:
docs/design/
Required artifacts:
design_overview.md
interface_design.md
data_design.md
workflow_design.md
access_control_design.md
ai_interaction_design.md
error_and_exception_design.md
technical_decision_records.md
design_review.md
design_readiness_summary.md
Templates should be copied from:
template-library/design/
Completed reference examples, when available, should be reviewed under:
examples/lmu-coicp/design/
What good looks like¶
Good design evidence is traceable to architecture and requirements, specific enough to guide implementation, explicit about interfaces and data, explicit about workflow and edge cases, explicit about access and control logic, explicit about AI interaction boundaries where relevant, and reviewable before code is written.
Good design narrows ambiguity without over-specifying every line of code.
Required reading order¶
Relationship to ES-104¶
ES-104 defines the system structure. ES-105 defines how that structure should be realized technically.
Do not make design choices that contradict the architecture without recording a technical decision and updating the affected architecture evidence.
Relationship to ES-106¶
ES-106 should not have to guess whether implementation is ready. ES-105 gives ES-106 the evidence needed to confirm that implementation can begin with clear interfaces, data expectations, workflows, controls, and review obligations.
Lifecycle chain¶
ES-105 continues the ETIS lifecycle chain:
Question
↓
Evidence
↓
Decision
↓
Repository Artifact
↓
Next Stage
The question is how architecture becomes implementable design. The evidence is the design package. The decision is whether the design is ready to support implementation readiness. The repository artifact is stored under docs/design/. The next stage is ES-106.
AI may help draft interface contracts, identify missing edge cases, compare data model options, critique workflow design, and draft technical decision records. AI must not silently invent design constraints. Engineers remain responsible for final design decisions.
Do not let implementation convenience override architecture without an explicit technical decision. If the code wants to bypass evidence preservation, human review, access control, or AI controls, the design is defective.
Design is where architectural intent either becomes implementable or quietly disappears.