Skip to content
ETIS

Part II — Engineering Practice

Requirements, architecture, planning, implementation, verification, and delivery

Part II moves ETIS from engineering mindset into engineering construction.

It shows how trustworthy intelligent systems are shaped through disciplined requirements, architecture, planning, design decisions, AI-assisted implementation, review, verification, release readiness, and release defense.

Part II is where ETIS becomes active engineering work.

Engineering artifacts are not paperwork. They are evidence.

Purpose of Part II

Part II explains how teams turn intent into a reviewable, evidence-backed system.

It establishes the engineering practices needed to build responsibly:

  • define project intent
  • clarify requirements
  • manage scope and uncertainty
  • make architectural decisions visible
  • plan work realistically
  • use AI responsibly
  • review implementation
  • verify behavior
  • prepare release evidence
  • defend release readiness

Part II teaches that a working system is not enough.

The work must be understandable, reviewable, governable, testable, and defensible.

Central Question

How do engineers build intelligent systems responsibly enough that they can be reviewed, verified, and released with evidence?

Part II answers that question by turning ETIS principles into construction practices.

What Part II Covers

Part II covers the engineering construction lifecycle from project launch through release defense.

Chapter Range Focus
Chapters 8–10 Project launch, engineering standards, repository setup, requirements, and scope
Chapters 11–13 Architecture, planning, estimation, risk, and engineering coordination
Chapters 14–18 AI governance, design decisions, AI-assisted implementation, pull requests, reviews, and verification
Chapters 19–22 Release readiness, release defense, delivery judgment, and transition toward operation

Key Themes

Part II teaches readers how to practice disciplined engineering under AI-era conditions.

Key themes include:

  • requirements as engineering evidence
  • architecture as decision structure
  • planning as risk management
  • AI assistance under human accountability
  • design decisions and ADRs
  • pull requests and review discipline
  • verification and validation evidence
  • release readiness
  • engineering defense
  • traceability from intent to release

These themes prepare readers for the operational and governance responsibilities that begin after release.

Why Engineering Practice Matters

AI can accelerate construction.

That does not mean construction becomes less disciplined.

The faster teams can generate code, tests, documentation, and design alternatives, the more important it becomes to ask:

  • What requirement does this satisfy?
  • What assumption does this depend on?
  • What architecture decision does this reflect?
  • What evidence supports this behavior?
  • What AI assistance was used?
  • How was the output reviewed?
  • What risks remain?
  • Is this ready to release?

Part II gives teams the structure to answer those questions.

Part II in the ETIS Lifecycle

Part II builds on the foundations established in Part I.

Part I — Foundations
        ↓
Part II — Engineering Practice
        ↓
Part III — Operational Trust
        ↓
Part IV — Trustworthy Intelligent Systems

Part II does not end when the software works.

It ends when the team can defend why the system is ready for release.

Who Should Start Here

Start with Part II if you already understand the ETIS foundation and want to focus on how trustworthy systems are engineered before release.

Part II is especially useful for:

  • software engineering students
  • project teams
  • developers
  • architects
  • technical leads
  • instructors
  • engineering managers
  • reviewers
  • teams adopting AI-assisted development

Readers new to ETIS should usually read Part I first.

How to Read Part II

Read Part II as an engineering operating model.

The chapters should be read as connected lifecycle activities, not isolated topics.

Requirements affect architecture.

Architecture affects planning.

Planning affects delivery.

AI use affects review.

Review affects verification.

Verification affects release readiness.

Release readiness affects operational trust.

Everything connects.

Start Reading

Begin Part II with Chapter 8.

Start Part II — Chapter 8 →

Continue After Part II

After completing Part II, continue to Part III.

Part III moves from construction into operational reality: defects, postmortems, observability, runbooks, security, AI governance, reliability, incidents, release governance, and organizational trust.

Continue to Part III →

Bottom Line

Part II teaches that engineering construction is not complete when code runs.

It is complete when requirements, architecture, implementation, reviews, verification, AI use, release decisions, and remaining risks can be inspected and defended.

That is how construction becomes trustworthy engineering.