Skip to content

Engineering Stage

ES-105 — Activities

Create the design evidence that makes implementation readiness review possible.

Activities
Design Evidence
Next: Evidence

ES-105 Activities

Purpose

This page guides the design work for ES-105.

Complete the activities in order. Iterate when design exposes architecture gaps, requirement ambiguity, or implementation risk.

Activity 1 — Create design overview

Create:

docs/design/design_overview.md

Use:

template-library/design/design_overview.md

Summarize architecture inputs, design priorities, design assumptions, implementation-relevant risks, and the design decisions that must be made before ES-106.

Evidence produced

Bridge evidence from architecture to design.

Activity 2 — Define interface design

Create:

docs/design/interface_design.md

Use:

template-library/design/interface_design.md

Define component interfaces, inputs, outputs, validation rules, authorization expectations, error behavior, evidence produced, and related architecture components.

Evidence produced

Interface contract evidence.

Activity 3 — Define data design

Create:

docs/design/data_design.md

Use:

template-library/design/data_design.md

Define core data structures, fields, relationships, evidence fields, timestamps, AI markers, retention considerations, provenance expectations, and access implications.

Evidence produced

Data structure and evidence-preservation evidence.

Activity 4 — Define workflow design

Create:

docs/design/workflow_design.md

Use:

template-library/design/workflow_design.md

Define normal, alternate, and exception workflows. Include state transitions, human review points, AI-assisted steps, evidence creation, and failure handling.

Evidence produced

Workflow and oversight evidence.

Activity 5 — Define access-control design

Create:

docs/design/access_control_design.md

Use:

template-library/design/access_control_design.md

Define roles, permissions, protected actions, protected data, denied-action behavior, audit expectations, and review obligations.

Evidence produced

Access-control design evidence.

Activity 6 — Define AI interaction design

Create:

docs/design/ai_interaction_design.md

Use:

template-library/design/ai_interaction_design.md

If AI is not used, explicitly state that.

If AI is used, define inputs, outputs, markers, review workflow, acceptance, rejection, failure handling, prohibited uses, and evidence.

Evidence produced

AI interaction and human-review design evidence.

Activity 7 — Define error and exception design

Create:

docs/design/error_and_exception_design.md

Use:

template-library/design/error_and_exception_design.md

Define how the system handles invalid actions, denied access, unavailable services, AI failures, missing evidence, workflow conflicts, partial completion, and recovery paths.

Evidence produced

Failure behavior evidence.

Activity 8 — Record technical decisions

Create:

docs/design/technical_decision_records.md

Use:

template-library/design/technical_decision_records.md

Record important design decisions and rationale. Include tradeoffs, alternatives, consequences, and downstream verification implications.

Evidence produced

Technical decision evidence.

Activity 9 — Review design

Create:

docs/design/design_review.md

Use:

template-library/design/design_review.md

Review design for architecture alignment, implementation clarity, access control, evidence preservation, AI review, failure handling, edge cases, and testability.

Evidence produced

Design review evidence.

Activity 10 — Complete design readiness summary

Create:

docs/design/design_readiness_summary.md

Use:

template-library/design/design_readiness_summary.md

Summarize completed artifacts, unresolved design issues, risks carried forward, and readiness for ES-106.

Evidence produced

Transition evidence from design to implementation readiness.

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
AI assistance

Use AI to critique design, identify missing edge cases, check interface ambiguity, examine data evidence coverage, and look for access-control or AI-review bypass paths. Engineers decide and remain responsible.

Common pitfall

Do not defer error handling until implementation. Failure behavior is part of design.

Engineering insight

Design is strongest when it exposes the decisions implementation should not have to rediscover.

Continue to Evidence

Review what counts as sufficient ES-105 design evidence.

Continue to Evidence →