architecture-decisionlisted

# Architecture Decision Use this skill when a choice can alter boundaries, APIs, data ownership, deployment, security, reliability, performance, cost, or operational responsibility. Produce a decision that another engineer can verify and revisit; do not turn a tool preference into an architectural requirement. ## Establish the decision frame 1. State the decision to make and the deadline. 2. Describe the current context, users, components, data flows, and relevant dependencies. 3. Record constraints: compatibility, regulation, team capability, delivery window, budget, latency, availability, and migration limits. 4. Identify up to five prioritized quality attributes and measurable targets (for example p95 latency, recovery time, availability, cost per request, or deploy frequency). 5. List assumptions and missing evidence. If evidence is insufficient, record an investigation, owner, deadline, and decision criterion. Do not claim a quality attribute without a measurement plan. Separate requirements from preferences and reversible experiments from durable commitments. ## Compare options Compare at least two viable alternatives and the option of not changing. For each, cover: - boundary and contract changes; - data ownership, consistency, migration, and rollback; - security, privacy, reliability, performance, and cost implications; - developer and operator experience, dependencies, and failure modes; - implementation effort, time to value, reversibility, and lock-in. Use