{
  "schema_version": 1,
  "skill_name": "enterprise-architecture",
  "evals": [
    {
      "id": "capability-application-duplication",
      "prompt": "Our claims intake capability is supported by three applications with overlapping names. One serves a regulated region, one owns customer notifications, and one is a legacy batch system. Build a portfolio view and say whether we should consolidate them.",
      "expected_output": "An evidence-labeled capability/application portfolio view that treats duplication as a hypothesis, checks authority and constraints, and recommends an investigation or bounded action rather than automatic consolidation.",
      "assertions": [
        "The output distinguishes capability, value-stream stage, application, and information authority",
        "It tests duplication against scope, jurisdiction, consumers, ownership, lifecycle, and integration evidence",
        "It does not recommend consolidation solely because application names overlap",
        "It identifies accountable owners and evidence gaps"
      ],
      "case_set": "regression"
    },
    {
      "id": "operating-model-choice",
      "prompt": "Five domains need architecture decisions. Local teams move quickly, but incompatible customer identity and reporting choices are creating duplicated spend. Compare centralized, federated, and hybrid enterprise architecture operating models and recommend a conditional choice.",
      "expected_output": "A comparison grounded in decision locality, coordination cost, coherence, evidence, and risk, with a conditional recommendation and explicit role/authority implications without designing reporting lines.",
      "assertions": [
        "All three operating-model options are compared with benefits and costs",
        "The recommendation is tied to cross-domain duplication and shared identity/reporting constraints",
        "Roles and decision rights are named without becoming an organization-chart or compensation exercise",
        "The output states what evidence would cause a different choice"
      ],
      "case_set": "regression"
    },
    {
      "id": "decision-rights-conflict",
      "prompt": "The security team says it owns identity standards, the customer platform team says it owns the identity service, and regional business units need different verification rules. Define an enterprise decision-rights and conflict-resolution record.",
      "expected_output": "A decision record that separates outcome, enterprise constraint, implementation, and regional operating responsibilities; names consultation and authority; and provides exception and escalation paths.",
      "assertions": [
        "The conflict is decomposed into distinct decision and responsibility types",
        "The record names accountable authority, consultees, affected parties, and escalation",
        "Regional variation is handled as an explicit constraint or exception rather than silently overridden",
        "Technology standards and security implementation are handed to their specialist owners"
      ],
      "case_set": "regression"
    },
    {
      "id": "transition-architecture",
      "prompt": "We want a single customer profile platform, but four products still write different profile stores and a regulatory migration cannot happen in one release. Create a transition architecture roadmap with intermediate states, coexistence assumptions, exit evidence, and a safe execution handoff.",
      "expected_output": "A current/target/transition roadmap that makes authority, dependencies, coexistence, reversibility limits, exit evidence, owners, and migration-engineering handoff explicit.",
      "assertions": [
        "Current, target, and at least two useful intermediate states are distinguished",
        "Data authority, dual-write or coexistence assumptions, and reconciliation evidence are addressed",
        "The roadmap includes stop/defer conditions and does not claim rollback is always possible",
        "Approved execution is routed to migration-engineering and implementation-planning"
      ],
      "case_set": "regression"
    },
    {
      "id": "org-design-near-miss",
      "prompt": "Redesign our reporting structure, team topology, compensation bands, and succession plan so the architecture group can scale.",
      "expected_output": "A routing response to org-design that does not invent an enterprise architecture operating model or HR methodology.",
      "assertions": [
        "Reporting structure, team topology, compensation, and succession are routed to org-design",
        "The enterprise-architecture skill does not produce an organization redesign"
      ],
      "case_set": "regression"
    },
    {
      "id": "product-roadmap-near-miss",
      "prompt": "Turn these ten product ideas into a Now/Next/Later roadmap with confidence, capacity, and continue-or-kill criteria.",
      "expected_output": "A routing response to product-roadmapping-and-portfolio, with no capability portfolio or enterprise transition method substituted.",
      "assertions": [
        "Product bets and outcome sequencing are routed to product-roadmapping-and-portfolio",
        "The response does not reframe a product roadmap as an enterprise architecture roadmap"
      ],
      "case_set": "regression"
    },
    {
      "id": "technology-radar-near-miss",
      "prompt": "Evaluate whether we should adopt Kafka, compare it with two alternatives, and place the result on an Adopt/Trial/Assess/Hold technology radar.",
      "expected_output": "A routing response to technology-radar for technology adoption posture and radar mechanics, optionally noting enterprise capability context as an input.",
      "assertions": [
        "Technology adoption comparison and radar placement are routed to technology-radar",
        "The enterprise-architecture skill does not reproduce a technology radar method"
      ],
      "case_set": "regression"
    },
    {
      "id": "software-architecture-near-miss",
      "prompt": "Design the runtime architecture for a new order service, including service boundaries, synchronous versus asynchronous calls, consistency, retries, and failure recovery.",
      "expected_output": "A routing response to software-architecture because the task is system-level runtime and failure design, not enterprise portfolio alignment.",
      "assertions": [
        "Runtime boundaries, consistency, retries, and failure behavior are routed to software-architecture",
        "The response does not produce an enterprise capability map as a substitute"
      ],
      "case_set": "regression"
    },
    {
      "id": "strategy-near-miss",
      "prompt": "Choose whether to enter the healthcare market, acquire a competitor, or focus on our current segment using competitive analysis and capital allocation.",
      "expected_output": "A routing response to strategy-frameworks for corporate direction, competitive choices, acquisition, and capital allocation.",
      "assertions": [
        "Corporate strategy, market entry, acquisition, and capital allocation are routed to strategy-frameworks",
        "The enterprise-architecture skill does not answer the corporate strategy decision"
      ],
      "case_set": "regression"
    }
  ]
}

# Capability, Value-Stream, and Portfolio Mapping

Use this reference when an enterprise question concerns what the organization does,
how value moves, or which applications and information support it.

## Map in layers

1. Name the outcome or stakeholder need. A capability is an enduring ability, not a
   project, team, system, or slogan.
2. Describe the value stream as a sequence of stakeholder-visible stages that turns
   a need into an outcome. Keep it outcome-oriented; do not confuse it with an
   internal process map.
3. Decompose capabilities only until owners can assess health and investment. Stop
   before the map becomes an implementation work breakdown.
4. Link each capability to applications, information assets, technology dependencies,
   owners, consumers, lifecycle status, cost evidence, and known risks.
5. Record confidence and provenance for every relationship. A plausible relationship
   is not observed evidence.

## Portfolio questions

For each capability, ask: How important is it to the stated outcome? How differentiated
or commodity is it? What is its health and change pressure? Which applications support
it, and are they authoritative, duplicative, overlapping, or merely adjacent?

Treat duplication as a hypothesis requiring comparison of scope, users, data
authority, lifecycle, integration cost, and contractual constraints. Do not recommend
consolidation merely because two systems have similar names. A shared capability may
legitimately have multiple implementations when jurisdictions, risk, latency, or
customer commitments differ.

## Minimum portfolio fields

| Field | Question |
|---|---|
| Capability | What enduring ability is being assessed? |
| Value-stream stage | Which stakeholder-visible outcome stage needs it? |
| Application | Which product or system supports it? |
| Authority | Which system or role owns the authoritative decision/data? |
| Relationship | Supports, consumes, duplicates, constrains, or depends on |
| Health | Evidence of fitness, risk, cost, or change pressure |
| Owner | Accountable business and technology roles |
| Decision | Invest, contain, converge, replace, retain, or investigate |
| Confidence | High, medium, or low with a reason |

Keep application architecture and API contract detail with their specialist owners.
This view is for enterprise alignment and investment conversation, not low-level
solution design.

# Current, Target, and Transition Architecture

Use this reference when a desired enterprise state spans multiple domains or cannot
be reached safely in one change.

## Describe each state

- **Current:** observed capabilities, applications, information, technology,
  dependencies, constraints, pain, and ownership. Mark unknowns instead of filling
  gaps with a preferred future.
- **Target:** the future arrangement tied to outcomes, principles, measurable
  constraints, ownership, and decision rights. It is a hypothesis until adopted and
  funded.
- **Transition:** a stable intermediate arrangement that reduces risk or unlocks the
  next change. It must be useful on its own, not a disguised project phase.

For every target difference, record the dependency, affected capability, change
owner, reversibility, customer or operational impact, and evidence that would permit
the next move.

## Choose transitions

Prefer increments that remove a material constraint, establish missing ownership,
reduce duplicated investment, or create evidence for a disputed target. Compare
options by value, dependency order, disruption, reversibility, coexistence burden,
and ability to stop safely. A transition may retain legacy components deliberately
when replacement would create greater risk.

Do not promise rollback when data, contracts, training, or operating behavior have
irreversibly changed. Name roll-forward, containment, or retirement alternatives and
route execution to `migration-engineering` after the target is approved.

## Transition quality check

Each increment should state:

- entry conditions and the capability/outcome it advances;
- systems, information, roles, and decisions affected;
- dependencies and coexistence assumptions;
- user, operational, cost, and risk consequences;
- exit evidence and a named accountable owner;
- stop, defer, or proceed conditions;
- next transition enabled and residual debt accepted.

Architecture decides the coherent sequence and guardrails. Product owns product
commitments, strategy owns corporate choices, organization design owns people
changes, and delivery/migration owners execute approved work.

# Enterprise Operating Model and Roles

Use this reference when architecture work is blocked by unclear ownership or when
the organization must choose how much decision authority to centralize.

## Compare operating models

| Model | Strength | Cost or risk | Fit signal |
|---|---|---|---|
| Centralized | Coherent enterprise standards and clear escalation | Slow local decisions and distance from domain context | Shared constraints are high and local variation is costly |
| Federated | Domain expertise and faster local decisions | Divergence, duplication, and coordination burden | Domains own outcomes and can honor shared contracts |
| Hybrid | Central guardrails with local design authority | Boundary ambiguity unless rights are explicit | Enterprise coherence matters but domain variation is real |

Choose from the work: decision frequency, reversibility, cross-domain coupling,
regulatory exposure, scarce expertise, and the cost of divergence. Do not select a
model from organization size or fashion alone. Reassess when evidence shows that a
decision is repeatedly escalated, duplicated, delayed, or made without affected
owners.

## Define roles without designing the organization

Name the accountable enterprise sponsor, capability owner, domain architect,
technology or platform owner, information owner, product owner, operations owner,
and delivery owner only where their decision or evidence is relevant. For each role,
state the decision or promise, authority boundary, required consultees, evidence
owed, and escalation route. This is an architecture operating contract, not a
reporting structure, compensation plan, or talent model; route those to `org-design`.

## Test the choice

Ask whether local teams can make safe decisions with the available context, whether
shared standards are enforceable, whether exceptions are visible, and whether anyone
is accountable for cross-capability outcomes. If the answer is no, record a maturity
or capability gap rather than inventing a council that has no authority.

# Federated Governance and Decision Rights

Use this reference when multiple domains must remain coherent without routing every
choice through a central board.

## Start with the decision

For each decision record its scope, affected capabilities, reversibility, blast
radius, regulatory obligations, evidence, and accountable owner. Then select a path:

- **Local decision:** the domain owns the outcome and compatibility is bounded.
- **Federated decision:** a domain decides within published enterprise constraints
  and affected peers can raise a conflict.
- **Advice process:** the proposer owns the choice after consulting those bearing
  material consequences; advice is not an unrecorded veto.
- **Central decision:** a named authority decides when impact, irreversibility,
  mandatory control, or unresolved cross-domain conflict exceeds local authority.

These are governance choices, not maturity levels. Automate objective checks where
possible, but do not turn a judgment into a false pass/fail rule.

## Make conflicts resolvable

Every standard or decision should name the proposer, accountable owner, affected
parties, required consultation, decision authority, evidence threshold, exception
path, expiry or revisit trigger, and appeal/escalation route. When two owners have
legitimate authority over the same boundary, first separate the decision into
outcome, constraint, implementation, and operating responsibilities. If authority
still conflicts, escalate to the named enterprise sponsor; never silently choose.

Review feedback from delivery, operations, cost, incidents, adoption, and exceptions.
Revise or retire a control when it no longer prevents a meaningful failure. Keep the
historical decision and reason for change visible.

Technology standards and radar posture remain with `technology-radar`; durable
decision history remains with `adr-authoring`.

# Public Source Index and Transformation Boundary

This skill is an original, task-centered methodology. Public sources provide
terminology and prompts for comparison; they are not reproduced as instructional
text.

| Source | Use in this skill | URL |
|---|---|---|
| ISO/IEC/IEEE 42010 overview | Stakeholders, concerns, viewpoints, and architecture descriptions | https://www.iso.org/standard/74393.html |
| ArchiMate specification | Public notation vocabulary for relationships among motivation, strategy, business, application, and technology views | https://www.opengroup.org/archimate-forum/archimate-overview |
| TOGAF public overview | Enterprise architecture lifecycle vocabulary and governance context only | https://www.opengroup.org/togaf |
| Wardley Mapping public guide | Capability positioning and dependency conversation prompts; no prescribed map is reproduced | https://learnwardleymapping.com/ |
| Thoughtworks Technology Radar | Technology adoption and uncertainty vocabulary; portfolio governance remains with `technology-radar` | https://www.thoughtworks.com/radar |
| W3C Web Content Accessibility Guidelines | Accessible information and communication requirements | https://www.w3.org/TR/WCAG22/ |

## Transformation boundary

Purchased ebooks and the private synthesized comparison report may inform research
only. This repository does not reproduce their prose, tables, diagrams, examples,
taxonomies, chapter order, or distinctive presentation. The deliverable was written
from user tasks, public sources, repository ownership boundaries, and fresh examples.
Do not read or quote purchased ebooks while using or extending this skill.

The method keeps only cross-source decision pressures: connect capability to
outcome, distinguish evidence from aspiration, choose a reachable transition, place
authority near the decision while protecting enterprise coherence, and publish
information that people can actually use. Future edits should be rewritten from the
user task if they resemble a source's distinctive structure or wording.

# Stakeholder Engagement and Architecture Information

Use this reference when the architecture must be understood and used by people
with different decisions, vocabulary, access needs, or levels of technical detail.

## Engage by decision job

Identify who decides, who supplies evidence, who is affected, who operates the
result, and who can block adoption. Ask each stakeholder what decision they need to
make, what evidence would change it, and what consequence they cannot accept. Use
`product-discovery` for raw product or stakeholder discovery when that is the primary
task; this reference focuses on architecture alignment.

Create audience-specific views from one traceable model:

- executive: outcome, material choices, investment, risk, and unresolved authority;
- capability owner: health, dependencies, applications, and decision rights;
- product or delivery team: transition slice, constraints, dependencies, and exit evidence;
- operator: runtime ownership, support impact, recovery assumptions, and signals.

## Publish information people can use

Every view should have an owner, purpose, scope, as-of date, evidence links,
confidence, decision status, and next review trigger. Prefer plain language, stable
terms, text alternatives for diagrams, headings that expose structure, keyboard- and
screen-reader-friendly tables in rendered outputs, sufficient contrast, and no
meaning conveyed by color alone. Link related views rather than copying facts into
multiple uncontrolled documents.

Architecture information is successful when a stakeholder can find the relevant
decision, understand what is known versus proposed, identify their responsibility,
and challenge it through a visible route. A polished repository with no user or
review behavior is not an architecture capability.

# Capability Portfolio View

## Scope
- Outcome or value stream:
- Assessment date:
- Portfolio owner:
- Evidence limitations:

## View
| Capability | Value-stream stage | Applications and relationship | Information authority | Owners | Health/risk/cost evidence | Decision | Confidence |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

## Duplication hypotheses
| Items compared | Similarity observed | Material difference or constraint | Evidence needed | Proposed action | Owner |
|---|---|---|---|---|---|
| | | | | | |

## Portfolio decisions
- Invest:
- Contain:
- Converge or retire:
- Investigate:
- Decisions routed to `software-architecture`, `data-architect`, `api-design-and-evolution`, or `technology-radar`:

# Enterprise Context Brief

## Decision and outcome
- Enterprise question:
- Desired outcome:
- Decision owner and authority:
- Scope and exclusions:
- Decision horizon:

## Context
- Strategic or product inputs (link):
- Current operational evidence (link):
- Regulatory, contractual, or customer constraints:
- Known dependencies:

## Stakeholders
| Stakeholder | Decision or evidence needed | Consequence | Engagement owner |
|---|---|---|---|
| | | | |

## Evidence ledger
| Claim | Type (evidence/assumption/decision/open) | Source or gap | Confidence | Owner |
|---|---|---|---|---|
| | | | | |

## Boundaries and handoffs
- Enterprise architecture owns:
- Specialist owners:
- Unresolved authority conflict:
- Next validation:

# Transition Architecture Roadmap

## Target and constraints
- Target outcome and principles:
- Current-state constraints:
- Non-negotiable safety or compliance conditions:
- Target owner:

## Transition increments
| Increment | Capability/outcome advanced | Systems, information, and roles affected | Dependencies | Coexistence assumption | Exit evidence | Owner | Stop/defer condition |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

## Sequence rationale
- Why this order:
- Options rejected and why:
- Customer and operational impact:
- Reversibility, roll-forward, or containment path:

## Governance and handoffs
- Decision rights and escalation:
- Product commitments: `product-roadmapping-and-portfolio`
- Organization changes: `org-design`
- Technology posture: `technology-radar`
- Approved implementation/migration execution: `implementation-planning` / `migration-engineering`
- Review trigger and date: