Architecture Engineer

Unearned architecture

Ask a capable agent to design a system and you get an architecture in the first reply: multi-tenant, event-driven, a queue, a cache, three services. Well presented, internally consistent, and chosen before anything was known about your problem.

Nothing in that answer is wrong. Nothing in it is earned — and unearned architecture looks exactly like the other kind while costing years to undo.

what is required  →  what the system really is
  →  the options that fit  →  the trade-offs
  →  a decision, recorded, with what reverses it
  →  the target · the migration · the evidence

The rule that does the work

Requirements are graded by how they were established, and the grade travels into every decision built on it.

A decision resting on an assumed or unknown requirement is not a decision. It is an open question with a leading candidate, and it is recorded that way. That is what stops a design session from quietly becoming a guess with a diagram.

You:    ...eventually maybe 500,000 users.

Agent:  Committed, or hoped for? It changes the answer by roughly an order of
        magnitude of cost, and designing for the hope usually costs more than
        adding it later.

The complexity budget

Every moving part is a permanent cost — another thing to deploy, monitor, secure, back up and be woken by. So each one names the requirement that forces it, or it comes out of the design.

Component        Driving requirement                          Grade
Queue + worker   R-03 payment confirmation must not be lost   STATED
Read replica     R-11 reporting must not slow checkout        OBSERVED
Redis cache      —                                            none — removed
Second service   R-09 unknown scale                           UNKNOWN — deferred

This is the anti-cargo-cult rule, made checkable. Microservices, event sourcing, CQRS, a message bus, Kubernetes — each is a legitimate answer to a specific problem and a liability without one.

Declared vs implemented

For an existing system, the most useful sentence is usually the gap between what the codebase claims and what it does.

Declared                        Implemented
domain/ application/            domain/ imports the ORM in 14 files
infrastructure/
"service layer"                 two controllers write the table directly
"orders owns orders"            billing and reporting both write order_status
"events"                        one publisher, no subscriber since March

A services/ directory is not a service architecture. A domain/ directory is not a domain model. Architecture is read from dependency direction, data ownership and call paths — directory names are a hypothesis at best.

When it activates

No slash command needed. It engages when architectural work is invited — and when it shapes the work, one ⚡ line says so. How the skills work together →

Where it fits

Project Compass notices, unprompted, that eight reasonable features have become an authorization model nobody defined, and names the decision. This skill is what you call when you want that decision answered — it is invited, never volunteered, and Compass keeps the interruption budget.

Once a boundary is chosen, Impact Map says what moving it touches, ProofBuild proves the behavior survived, and Production Guard decides whether the result ships.