Bounded Context Autonomy Assessment Prompt

Use this prompt when you need a structured, repeatable assessment of a bounded context's autonomy. It is designed for domain architects and platform engineers who must evaluate whether a context can operate, evolve, and scale independently. The prompt produces an autonomy scorecard across four dimensions: data ownership, deployment independence, team alignment, and runtime coupling. It also identifies specific blockers that prevent full autonomy. This is not a general architecture review prompt. It assumes the bounded context boundaries are already defined and focuses strictly on independence characteristics. Run this before committing to a context's implementation strategy, before a planned extraction from a monolith, or as part of a quarterly architecture health check.

The prompt requires a defined bounded context as input, including its name, domain responsibilities, current data stores, deployment characteristics, owning team structure, and known integration points with other contexts. Without this context, the assessment will produce vague or misleading results. The prompt works best when you can provide concrete details: database names, deployment pipelines, team composition, and specific API or event contracts. Vague inputs like 'the context uses a shared database' will produce vague outputs. Instead, specify which tables, which schemas, and which other contexts also access them. The prompt is designed to be run against one context at a time. Running it against multiple contexts simultaneously dilutes the analysis and produces cross-context confusion rather than focused autonomy scoring.

Do not use this prompt when bounded context boundaries are still being discovered or negotiated. Boundary discovery requires a different prompt focused on cohesion, coupling, and domain alignment. Do not use it for greenfield contexts that have no existing implementation to assess — the prompt evaluates current state, not aspirational design. Do not use it as a substitute for a full architecture review that must cover security, scalability, or cost. The prompt focuses narrowly on autonomy characteristics. If the context handles regulated data, financial transactions, or safety-critical operations, add a human review gate after the assessment. The scorecard identifies blockers but does not prescribe remediation steps — pair it with a refactoring impact analysis prompt when blockers are found.

This prompt template is designed to be the core instruction you send to an LLM. It evaluates a single bounded context against four pillars of autonomy: data ownership, deployment independence, team alignment, and runtime coupling. The placeholders in square brackets allow you to inject the specific details of the context under review, the desired output format, and any organizational constraints. Treat this template as a starting point; you will likely need to iterate on the instructions based on the model you are using and the specific failure modes you observe.

markdownCopy
You are a domain-driven design architect evaluating the autonomy of a single bounded context. Your goal is to produce a structured assessment that identifies blockers to independence and provides a clear autonomy scorecard.

## Context Under Review
- **Context Name:** [CONTEXT_NAME]
- **Business Domain:** [BUSINESS_DOMAIN]
- **Core Responsibility:** [CORE_RESPONSIBILITY]
- **Owning Team:** [OWNING_TEAM]

## Context Details
[CONTEXT_DETAILS]

## Assessment Criteria
For each of the four pillars below, assign a score from 1 (fully dependent) to 5 (fully autonomous). For any score below 4, you must identify specific blockers.

1.  **Data Ownership:** Does this context own its data store and schema? Can it change its internal data model without forcing changes on other contexts?
2.  **Deployment Independence:** Can this context be deployed, scaled, and rolled back independently of other services? Does it have its own CI/CD pipeline?
3.  **Team Alignment:** Is a single, cross-functional team fully empowered to build, test, deploy, and operate this context without external dependencies on other teams?
4.  **Runtime Coupling:** Is the context resilient to the failure of other contexts? Does it rely on synchronous calls that could cascade failures, or does it primarily use asynchronous, event-driven communication?

## Output Schema
Return your analysis as a JSON object conforming to the following structure. Do not include any text outside the JSON object.

[OUTPUT_SCHEMA]

## Constraints
- Be specific and evidence-based in your blocker descriptions. Reference the provided [CONTEXT_DETAILS].
- If a score is 5, the blocker list must be empty.
- Do not propose solutions in the blocker list; only identify the problems.
- If the provided details are insufficient to assess a pillar, set the score to 0 and note "Insufficient Information" as the single blocker.

To adapt this template, start by replacing the [CONTEXT_DETAILS] placeholder with a rich description of the context's architecture, including its data stores, APIs, deployment pipeline, and team structure. The [OUTPUT_SCHEMA] placeholder is critical for application integration; replace it with a concrete JSON Schema that your application's parser expects, such as an object with autonomy_scorecard (an array of pillar objects) and overall_autonomy_score (a number). For high-stakes architectural decisions, always route the final output for human review and use this prompt as part of a broader evaluation that includes synchronous architecture review meetings.

This prompt is designed to run as a structured analysis step within a broader architecture review pipeline, not as a standalone chat interaction. The primary integration point is a CI/CD or documentation workflow where architecture artifacts (context maps, ADRs, deployment diagrams, team topology charts) are submitted for review. The prompt expects a pre-assembled [CONTEXT] block containing the bounded context definition, its dependencies, data ownership model, deployment topology, and team assignment. This context should be assembled programmatically from your architecture knowledge base, service catalog, or documentation repository before the prompt is invoked.

Model selection and invocation: Use a model with strong reasoning capabilities and support for structured output (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature=0.1 to reduce variance in the autonomy scoring. The prompt's [OUTPUT_SCHEMA] placeholder should be replaced with a JSON schema matching the expected scorecard structure: autonomy dimensions (data ownership, deployment independence, team alignment, runtime coupling) each scored 1-5, a list of blockers with severity, and a summary recommendation. Enforce this schema using your model's structured output feature or a post-generation validator. Validation layer: After the model responds, run a schema validator to confirm all required fields are present, scores are within range, and blocker descriptions are non-empty. If validation fails, retry once with the validation errors appended to the prompt as additional [CONSTRAINTS]. After two failures, flag the assessment for human review rather than retrying indefinitely.

Integration with review gates: The autonomy scorecard output should be written to your architecture decision log or review system with a timestamp, model version, and the full prompt context for auditability. If any autonomy dimension scores below 3 or a blocker is marked HIGH, route the assessment to a human architect for review before accepting the recommendation. For lower-risk assessments, the scorecard can be auto-appended to the bounded context's documentation as a living autonomy health check. Logging and observability: Log the full prompt, response, validation status, and any retry attempts. Track autonomy scores over time to detect architectural drift. What to avoid: Do not use this prompt on contexts where the input data is incomplete or stale—the model will produce plausible but incorrect assessments. Do not skip the human review gate for high-severity blockers. Do not treat the autonomy score as a permanent label; re-run the assessment when dependencies, team structures, or deployment topologies change.