ES-104 Activities¶
Purpose¶
This page guides the architecture work for ES-104.
Complete the activities in order. Iterate when architecture decisions reveal requirement gaps, planning weaknesses, hidden dependencies, unmanaged risks, or missing evidence paths.
Activity 1 — Create architecture overview¶
Create:
docs/architecture/architecture_overview.md
Use:
template-library/architecture/architecture_overview.md
Summarize architecture goals, source requirements, major constraints, planning assumptions, risks, architectural priorities, and known tradeoffs.
The overview should explain what the architecture must make possible, not simply describe the system.
Bridge evidence from requirements and planning into architecture.
Activity 2 — Define system context¶
Create:
docs/architecture/system_context.md
Use:
template-library/architecture/system_context.md
Identify users, external systems, organizational boundaries, operational context, trust boundaries, governance stakeholders, and external dependencies.
The context record should make clear what is inside the system, what is outside the system, and where responsibility changes.
Context, boundary, and trust-boundary evidence.
Activity 3 — Define component model¶
Create:
docs/architecture/component_model.md
Use:
template-library/architecture/component_model.md
Define major components, responsibilities, interfaces, dependencies, and accountability boundaries.
Each component should exist because it owns a meaningful responsibility. Avoid components that merely reflect implementation habits or technology preferences.
Structural decomposition and responsibility allocation evidence.
Activity 4 — Map data and evidence flow¶
Create:
docs/architecture/data_and_evidence_flow.md
Use:
template-library/architecture/data_and_evidence_flow.md
Show where data and evidence are created, processed, reviewed, stored, accessed, retained, and consumed.
This artifact should distinguish ordinary data flow from evidence flow. Evidence flow matters because trustworthy systems must support review, accountability, governance, and operations.
Data-flow, evidence-flow, retention, and review evidence.
Activity 5 — Define quality attribute strategy¶
Create:
docs/architecture/quality_attribute_strategy.md
Use:
template-library/architecture/quality_attribute_strategy.md
Explain how architecture supports major nonfunctional requirements and trustworthiness qualities.
Address qualities such as reliability, security, privacy, availability, auditability, maintainability, accessibility, observability, recoverability, human oversight, and governance visibility where relevant.
Quality strategy and nonfunctional-requirement support evidence.
Activity 6 — Define AI-control architecture¶
Create:
docs/architecture/ai_control_architecture.md
Use:
template-library/architecture/ai_control_architecture.md
If AI is not used, explicitly state that and explain whether future AI use is prohibited, deferred, or out of scope.
If AI is used, define boundaries, inputs, outputs, human review, evidence, monitoring, fallback behavior, and prohibited uses.
AI-control, human oversight, and AI-use evidence.
Activity 7 — Record architecture decisions¶
Create:
docs/architecture/architecture_decision_records.md
Use:
template-library/architecture/architecture_decision_records.md
Record major architecture decisions and rationale. ADRs should capture engineering tradeoffs, not only technology choices.
A strong ADR explains context, options considered, decision, rationale, consequences, affected requirements, affected risks, and review status.
Architecture decision and engineering tradeoff evidence.
Activity 8 — Review architecture¶
Create:
docs/architecture/architecture_review.md
Use:
template-library/architecture/architecture_review.md
Review architecture for requirements alignment, quality support, evidence flow, AI control, trust boundaries, access control, operational feasibility, governance visibility, risk handling, and design readiness.
Architecture review evidence.
Activity 9 — Complete architecture readiness summary¶
Create:
docs/architecture/architecture_readiness_summary.md
Use:
template-library/architecture/architecture_readiness_summary.md
Summarize completed artifacts, unresolved architecture issues, accepted tradeoffs, known risks, and readiness for ES-105.
Transition evidence from architecture to design.
Recommended working order¶
architecture_overview.md
↓
system_context.md
↓
component_model.md
↓
data_and_evidence_flow.md
↓
quality_attribute_strategy.md
↓
ai_control_architecture.md
↓
architecture_decision_records.md
↓
architecture_review.md
↓
architecture_readiness_summary.md
AI may help critique architecture options, identify unsupported requirements, find missing trust boundaries, detect weak AI-control paths, suggest quality strategies, and draft ADR language. AI should assist and challenge. Engineers decide and remain accountable for the final architecture.
Do not create ADRs only for technology choices. Record structural decisions that affect trust, evidence, control, quality, maintainability, and future operations.
The strongest architecture activities allocate obligations to system structure. If a responsibility has no place in the architecture, it will probably have no reliable place in operation.