Target-State Principles

Target-state principles describe the direction of travel before detailed architecture is finalized. They help teams make consistent decisions when implementation details are still changing.

Principle format

Each principle should include:

Statement.
Why it matters.
What it implies.
What it does not imply.
Example decision it affects.

Example principles

Prefer managed services for undifferentiated operations

Use managed services when they satisfy security, compliance, reliability, and portability needs. Do not self-operate complex infrastructure just because the team can.

Promote immutable artifacts

Build once, scan once, and promote the same artifact through environments. Avoid rebuilding per environment unless traceability and reproducibility are preserved.

Make ownership queryable

Services, infrastructure, data, cost, and alerts should map to owners through service catalog records, tags, labels, or other systems of record.

Automate evidence from normal workflows

Audit evidence should come from pull requests, pipeline runs, deployments, access reviews, and infrastructure records wherever possible.

Validate principles with engineering, security, product, and operations stakeholders. Principles should be opinionated enough to guide decisions but not so rigid that every real system becomes an exception.

Watchouts

Principles without examples are easy to misinterpret.
Too many principles dilute decision value.
Principles should change when evidence proves they are wrong.