ES-101 Activities¶
Purpose¶
This page guides the engineering work for ES-101.
Complete the activities in order. Each activity produces or improves an artifact under docs/vision/.
Activity 1 — Define the problem¶
Start with the problem, not the solution.
Create:
docs/vision/problem_statement.md
Use template:
template-library/vision/problem_statement.md
Your problem statement should answer:
- What problem exists?
- Who experiences it?
- What happens if it is not addressed?
- Why is the problem worth solving now?
- What evidence or observations support the claim?
Quality test¶
A reviewer should be able to understand the problem without knowing the proposed solution.
This activity produces problem-definition evidence that will guide requirements and scope decisions.
Activity 2 — Write the vision statement¶
Create:
docs/vision/vision_statement.md
Use template:
template-library/vision/vision_statement.md
The vision statement should describe the intended engineering direction.
It should include:
- system purpose;
- intended improvement;
- affected stakeholders;
- broad system boundary;
- trustworthiness expectation.
Quality test¶
The vision should help decide whether a proposed requirement belongs in the project.
This activity produces purpose evidence for downstream requirements, architecture, release, and governance decisions.
Activity 3 — Identify stakeholders¶
Create:
docs/vision/stakeholders.md
Use template:
template-library/vision/stakeholders.md
Identify stakeholder groups, not only individual users.
Include:
- primary users;
- affected parties;
- operators;
- maintainers;
- reviewers;
- governance stakeholders;
- people who may be harmed by system failure or misuse.
Quality test¶
A reviewer should be able to see whose needs, risks, and responsibilities must be considered.
This activity produces stakeholder evidence that will influence requirements, oversight, testing, and communication.
Activity 4 — Define scope¶
Create:
docs/vision/scope.md
Use template:
template-library/vision/scope.md
Define:
- in scope;
- out of scope;
- deferred;
- explicitly prohibited;
- open scope questions.
Scope should be specific enough to prevent uncontrolled expansion.
Quality test¶
A reviewer should be able to reject a proposed feature because it is outside the current scope.
This activity produces boundary evidence that protects later engineering stages from uncontrolled expansion.
Activity 5 — Record assumptions¶
Create:
docs/vision/assumptions.md
Use template:
template-library/vision/assumptions.md
Record assumptions about:
- users;
- data;
- operations;
- policy;
- technology;
- AI behavior;
- adoption;
- review;
- organizational support.
For each assumption, identify whether it should be validated later.
Quality test¶
A reviewer should be able to identify which claims are known and which are assumed.
This activity produces assumption evidence that later stages may validate, revise, or retire.
Activity 6 — Define success metrics¶
Create:
docs/vision/success_metrics.md
Use template:
template-library/vision/success_metrics.md
Define success in terms that can influence engineering.
Include:
- outcome metrics;
- operational metrics;
- quality or trust metrics;
- adoption or usability indicators;
- evidence required to evaluate success.
Quality test¶
A reviewer should be able to tell whether success could be evaluated after a pilot or release.
This activity produces success evidence for requirements, testing, release readiness, and stewardship.
Activity 7 — Complete the vision readiness summary¶
Create:
docs/vision/vision_readiness_summary.md
Use template:
template-library/vision/vision_readiness_summary.md
Summarize:
- what problem is being solved;
- who the stakeholders are;
- what is in and out of scope;
- key assumptions;
- success criteria;
- unresolved questions;
- readiness for ES-102.
Quality test¶
A reviewer should be able to read the summary and decide whether requirements work can begin.
This activity produces transition evidence from vision work to requirements work.
Recommended working order¶
Use this sequence:
problem_statement.md
↓
vision_statement.md
↓
stakeholders.md
↓
scope.md
↓
assumptions.md
↓
success_metrics.md
↓
vision_readiness_summary.md
Do not treat this as rigid. If success metrics reveal a scope problem, return to scope. If stakeholders reveal a missing problem dimension, update the problem statement.
Iteration is acceptable when the evidence is updated.
AI assistance¶
AI may help review each artifact for ambiguity.
Useful prompts include identifying vague claims in the problem statement, listing potentially missing stakeholders, identifying assumptions that should be validated before architecture, and checking whether success metrics are measurable or merely slogans.
Do not allow AI to invent stakeholder needs without verification.
Common pitfall¶
Do not write the readiness summary first.
The summary should synthesize evidence already produced. It should not replace the underlying artifacts.
Engineering insight¶
Vision work is complete when it makes requirements work easier, not when the wording sounds polished.