Service Boundary Team Topology Alignment Prompt

List of services with current ownership, dependencies, and criticality tier

payment-service (Team Alpha, Tier 1), notification-service (Team Alpha, Tier 2), fraud-detection (unowned, Tier 1)

Must include service name, owning team or null, and tier label. Null ownership is a valid signal for gap detection.

Current team roster with headcount, capability profile, and cognitive load indicators

Team Alpha: 5 engineers, backend-specialist, 4 owned services, on-call rotation active

Each team entry requires headcount, skill profile, and owned service count. Missing on-call status defaults to false.

Desired Team Topologies interaction modes for each team-to-service or team-to-team relationship

Team Alpha -> payment-service: stream-aligned; Team Alpha -> Team Beta: collaboration on shared-kernel

Valid modes: stream-aligned, enabling, complicated-subsystem, platform, collaboration, x-as-a-service, facilitating. Reject unrecognized modes.

Service-to-service call graph with direction, protocol, and coupling type

order-service -> payment-service: sync HTTP, runtime coupling; order-service -> inventory-service: async events, data coupling

Each edge requires source, target, protocol, and coupling type. Cyclic dependencies must be flagged in pre-processing.

Actual communication paths between teams derived from chat tools, meeting cadence, and PR review patterns

Team Alpha <-> Team Beta: daily standup overlap, shared Slack channel, joint PR reviews weekly

Paths must include frequency indicator and channel type. Missing paths between teams that share service dependencies is a key risk signal.

Per-team limits for service ownership count, domain complexity score, and on-call burden

Team Alpha: max 3 Tier-1 services, max domain complexity score 12, on-call rotation minimum 4 engineers

Thresholds must be numeric or null. Null threshold means no limit enforced for that dimension. Used for overload detection.

Immutable org boundaries, compliance zones, or regulatory separations that override topology recommendations

PCI-compliant services must remain under compliance-team ownership; EU-data services restricted to EU-resident teams

Each constraint must specify scope and enforcement rule. Constraints override topology alignment recommendations when in conflict.

string (UUID v4)

Must match regex ^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$

string (ISO 8601)

Must parse as valid UTC datetime; reject if future-dated by more than 5 minutes

array of objects

Must contain at least 1 object; max 50 objects; each object must have team_name, topology_type, owned_services, and alignment_score fields

string

Non-empty; max 100 characters; must match [TEAM_NAME] input list if provided

enum string

Must be one of: stream-aligned, enabling, complicated-subsystem, platform; reject unknown values

array of strings

Each string must match a service name from [SERVICE_CATALOG] input; empty array allowed only if topology_type is enabling

number (0.0-1.0)

Must be between 0.0 and 1.0 inclusive; parse as float; reject if NaN or out of range

string

Non-empty; max 500 characters; must contain at least one reference to a Team Topologies interaction mode (collaboration, x-as-a-service, facilitating)

array of strings

Each string must match a service name from [SERVICE_CATALOG] input; empty array allowed; reject if any service appears in both owned_services and orphaned_services

array of objects

Each object must have team_name and overload_factors fields; team_name must match [TEAM_NAME] input list

string

Non-empty; must match a team_name from team_topology_alignment array

array of strings

Non-empty; each string max 200 characters; must describe a specific overload factor (e.g., 'owns 7+ services', 'no enabling team support')

string

Non-empty; max 2000 characters; must summarize at least one gap if orphaned_services or overloaded_teams is non-empty; must state 'No gaps identified' if both are empty

array of objects

Min 1 object if gaps exist; max 10 objects; each object must have action, target_team, and priority fields

string

Non-empty; max 300 characters; must describe a concrete topology adjustment (e.g., 'Assign service X to stream-aligned team Y', 'Introduce enabling team for Z domain')

string

Non-empty; must match a team_name from team_topology_alignment array or be 'new' for proposed new teams

enum string

Must be one of: critical, high, medium, low; reject unknown values

Each team is classified into exactly one Team Topologies type (stream-aligned, enabling, complicated-subsystem, platform) with a justification grounded in the team's stated responsibilities and interaction patterns.

A team is assigned multiple conflicting types, classified as 'other' without rationale, or the justification contradicts the team's described function.

Manual review by a platform architect against the Team Topologies reference definitions. Spot-check 3 random teams per output.

Every service listed in [SERVICE_CATALOG] is mapped to exactly one owning team. No service appears in the 'unowned' list unless it genuinely lacks an owner in the provided [TEAM_STRUCTURE] input.

Services are missing from the ownership matrix, mapped to non-existent teams, or incorrectly flagged as unowned when an owner is present in the input.

Parse the output JSON. Cross-reference the service list against the input [SERVICE_CATALOG]. Validate that each service ID appears exactly once in the ownership mapping.

Each stream-aligned team receives a cognitive load score (low/medium/high/overloaded) with specific evidence: number of services owned, domain complexity, and cross-team dependencies.

Cognitive load scores are assigned without evidence, all teams receive the same score, or an overloaded team has no corresponding recommendation for splitting or enabling support.

Schema validation: check that the cognitive_load field is present and valid for every stream-aligned team. Manual review of evidence quality for teams scored 'overloaded'.

Each team-to-team relationship is classified with the correct Team Topologies interaction mode (collaboration, X-as-a-Service, facilitating) based on the described workflow and dependency direction.

Interaction modes are missing, inverted (e.g., platform team described as collaborating with every stream-aligned team), or conflict with the team type classification.

Parse the interaction graph. Validate that platform teams use X-as-a-Service mode for their consumers. Check that enabling teams use facilitating mode. Flag any stream-aligned-to-stream-aligned relationships missing a collaboration or X-as-a-Service designation.

The output identifies specific gaps: services without clear ownership, teams with no aligned services, missing platform or enabling capabilities, and overloaded teams.

The output reports zero gaps when the input [TEAM_STRUCTURE] and [SERVICE_CATALOG] contain obvious mismatches (e.g., 20 services and 2 teams). Gaps are described vaguely without actionable specifics.

Inject a test input with a known gap (a service with no owning team). Verify the output flags it. Check that each gap includes a severity and a recommended action.

Each recommendation includes a concrete next step, the team(s) involved, and a suggested sequencing priority (now/next/later).

Recommendations are generic advice ('improve communication') without specific owners, steps, or priority. Recommendations contradict the identified team types.

Extract all recommendations. Validate that each has a non-empty action, owner, and priority field. Manual review for internal consistency with the team type classifications.

The output strictly matches the [OUTPUT_SCHEMA] structure. All required fields are present. No additional top-level keys are introduced.

The output is missing required fields, contains malformed JSON, or includes hallucinated fields not defined in the schema.

Automated JSON Schema validation against [OUTPUT_SCHEMA]. Run as a CI check. Fail the output if validation errors are present.

Every claim about team responsibilities, service dependencies, or interaction patterns is traceable to the provided [TEAM_STRUCTURE] or [SERVICE_CATALOG] input. No invented teams, services, or relationships.

The output references a team, service, or dependency not present in the input data. A recommendation is based on an assumed constraint not stated in [CONSTRAINTS].

Parse all team and service identifiers from the output. Diff against the input identifiers. Flag any additions. For a sample of 5 claims, trace the justification back to the source input.