Engineering Strategy Brief
Use When
- Business outcomes and technical constraints require an explicit engineering direction before detailed design.
Do Not Use When
- Do not use as an HLD, delivery plan or generic technology wish list.
Required Inputs
| Artefact |
Source or provider |
Required? |
Missing behaviour |
| Business goals, product outcomes and architecture evidence |
Approved strategy and current-system evidence |
Required |
Stop if the decision horizon or accountable sponsor is unknown. |
| Constraints, risks and operating capability |
Engineering, security and operations owners |
Required |
Present bounded options when evidence is incomplete. |
Workflow
- Read the named inputs and confirm their approval, version and unresolved decisions.
- Apply the decision rules below before drafting; stop on a missing authority, unsafe assumption or unresolved scope driver.
- Produce the Engineering Strategy Brief and ADR agenda through the existing domain procedure and load only the references needed for the chosen branch.
- Trace each material statement in the Engineering Strategy Brief and ADR agenda to an input, decision or explicitly qualified assumption.
- Verify the observable acceptance conditions, record unassessed checks, and hand the artefacts to their named consumers.
- If validation fails, recover by correcting the source decision or artefact and rerun the affected check; do not weaken the acceptance condition.
Outputs
| Artefact |
Consumer |
Observable acceptance condition |
| Engineering Strategy Brief and ADR agenda |
Sponsor, architecture and delivery leadership |
Diagnosis cites evidence; each policy has an operating mechanism, owner, decision trigger and consequence for HLD sequencing. |
Evidence Produced
| Evidence |
Consumer |
Acceptance condition |
| Source and decision trace |
Reviewer and downstream owner |
Each material statement cites an approved input, named decision or qualified open issue. |
| Completed verification record |
Release or phase gate owner |
Every applicable check records pass/fail; unavailable checks remain not assessed. |
Capability and permission boundaries
Read-only is the default for analysis, review, evaluation and planning. Read and search access to authorised project artefacts are required. Editing is limited to an explicitly requested project deliverable. Execution may run document, syntax or validation checks. Network access is used only for facts that require current verification. Do not publish, spend, change production, approve policy, or claim certification without explicit authority.
Degraded mode
If any required capability is unavailable, return the narrowest useful qualified Engineering Strategy Brief and ADR agenda draft plus a gap register showing the missing item, affected sections, risk and owner. Never convert an unassessed check into a pass.
Decision Rules
| Choice |
Action |
Failure or risk avoided |
| Choice is directional and cross-cutting |
Set policy and open ADRs |
Detailed design shares one direction |
| Choice is local and reversible |
Defer to HLD/LLD |
Strategy avoids implementation noise |
Quality Standards
- Preserve repository terminology and trace every material choice to project context.
- Use deterministic acceptance conditions; replace vague quality claims with an observable check, threshold or named approval.
- Cover error, empty, edge, recovery and operational cases relevant to this skill.
- Verify standards, citations, APIs and package names before relying on them; qualify what cannot be checked.
- Stop release for a failed safety, security, legal, financial, accessibility or data-integrity gate.
Anti-Patterns
- Listing technologies without diagnosis. Fix: connect each policy to a named constraint.
- Writing goals with no operating mechanism. Fix: name cadence, owner or gate.
- Calling an aspiration a decision. Fix: state chosen direction and rejected alternative.
- Ignoring current-team capability. Fix: include adoption and ownership constraints.
- Turning the brief into a full HLD. Fix: keep component detail downstream.
References
Output Shape
Write projects/<ProjectName>/<phase>/<document>/Engineering_Strategy_Brief.md with diagnosis, guiding policy, coherent actions, operating mechanisms, ADR candidates, and evidence gates.
1---2name: 08-engineering-strategy-brief3description: Use when major HLD, platform, SaaS, AI, public-sector or modernisation work needs a concise diagnosis, guiding policies, operating mechanisms, ADR agenda and implementation sequence; use HLD after strategy choices are approved.4---5# Engineering Strategy Brief6<!-- dual-compat-start -->7## Use When89- Business outcomes and technical constraints require an explicit engineering direction before detailed design.1011## Do Not Use When1213- Do not use as an HLD, delivery plan or generic technology wish list.1415## Required Inputs1617| Artefact | Source or provider | Required? | Missing behaviour |18|---|---|---|---|19| Business goals, product outcomes and architecture evidence | Approved strategy and current-system evidence | Required | Stop if the decision horizon or accountable sponsor is unknown. |20| Constraints, risks and operating capability | Engineering, security and operations owners | Required | Present bounded options when evidence is incomplete. |2122## Workflow23241. Read the named inputs and confirm their approval, version and unresolved decisions.252. Apply the decision rules below before drafting; stop on a missing authority, unsafe assumption or unresolved scope driver.263. Produce the Engineering Strategy Brief and ADR agenda through the existing domain procedure and load only the references needed for the chosen branch.274. Trace each material statement in the Engineering Strategy Brief and ADR agenda to an input, decision or explicitly qualified assumption.285. Verify the observable acceptance conditions, record unassessed checks, and hand the artefacts to their named consumers.296. If validation fails, recover by correcting the source decision or artefact and rerun the affected check; do not weaken the acceptance condition.3031## Outputs3233| Artefact | Consumer | Observable acceptance condition |34|---|---|---|35| Engineering Strategy Brief and ADR agenda | Sponsor, architecture and delivery leadership | Diagnosis cites evidence; each policy has an operating mechanism, owner, decision trigger and consequence for HLD sequencing. |3637## Evidence Produced3839| Evidence | Consumer | Acceptance condition |40|---|---|---|41| Source and decision trace | Reviewer and downstream owner | Each material statement cites an approved input, named decision or qualified open issue. |42| Completed verification record | Release or phase gate owner | Every applicable check records pass/fail; unavailable checks remain `not assessed`. |4344## Capability and permission boundaries4546Read-only is the default for analysis, review, evaluation and planning. Read and search access to authorised project artefacts are required. Editing is limited to an explicitly requested project deliverable. Execution may run document, syntax or validation checks. Network access is used only for facts that require current verification. Do not publish, spend, change production, approve policy, or claim certification without explicit authority.4748## Degraded mode4950If any required capability is unavailable, return the narrowest useful qualified Engineering Strategy Brief and ADR agenda draft plus a gap register showing the missing item, affected sections, risk and owner. Never convert an unassessed check into a pass.5152## Decision Rules5354| Choice | Action | Failure or risk avoided |55|---|---|---|56| Choice is directional and cross-cutting | Set policy and open ADRs | Detailed design shares one direction |57| Choice is local and reversible | Defer to HLD/LLD | Strategy avoids implementation noise |5859## Quality Standards6061- Preserve repository terminology and trace every material choice to project context.62- Use deterministic acceptance conditions; replace vague quality claims with an observable check, threshold or named approval.63- Cover error, empty, edge, recovery and operational cases relevant to this skill.64- Verify standards, citations, APIs and package names before relying on them; qualify what cannot be checked.65- Stop release for a failed safety, security, legal, financial, accessibility or data-integrity gate.6667## Anti-Patterns6869- Listing technologies without diagnosis. Fix: connect each policy to a named constraint.70- Writing goals with no operating mechanism. Fix: name cadence, owner or gate.71- Calling an aspiration a decision. Fix: state chosen direction and rejected alternative.72- Ignoring current-team capability. Fix: include adoption and ownership constraints.73- Turning the brief into a full HLD. Fix: keep component detail downstream.7475## References7677- [Strategy brief template](references/engineering-strategy-brief-template.md)78- [SaaS architecture assumptions](references/saas-architecture-assumptions-and-scaling-checklist.md)79- [Java enterprise requirements overlay](../../02-requirements-engineering/references/java-enterprise-requirements-overlay.md) -- use for Java platform policy, modernisation stages, evidence gates and implementation handoff80- [HLD neighbour](../01-high-level-design/SKILL.md)81<!-- dual-compat-end -->828384858687## Output Shape8889Write `projects/<ProjectName>/<phase>/<document>/Engineering_Strategy_Brief.md` with diagnosis, guiding policy, coherent actions, operating mechanisms, ADR candidates, and evidence gates.90
peterbamuhigire