Cross-Service Data Ownership Analysis Prompt

This prompt is for data architects and backend leads who need to assign clear, defensible ownership of data entities across a distributed system before writing migration scripts or API contracts. The core job-to-be-done is preventing the most expensive mistake in microservice decomposition: shared data ownership that creates a distributed monolith. Use this prompt when you have a concrete list of services, data entities, and integration points and need a structured ownership matrix that forces the model to justify every decision, flag shared kernel exceptions explicitly, and specify anti-corruption layer requirements where ownership conflicts cannot be resolved. It is a design-time analysis tool, not a runtime data catalog, and it works best when the team has already identified candidate service boundaries and needs to validate them against data coupling realities.

The ideal user brings a well-scoped input: a bounded set of services (typically 5-20), the data entities each service touches (tables, event types, read models), and known integration points between services. The prompt expects you to provide this context in a structured format, and it returns an ownership matrix with explicit justification columns, shared kernel exception flags, and anti-corruption layer specifications. Do not use this prompt when the service boundary map is still speculative or when the team has not yet agreed on domain terminology—garbage in, garbage out applies with full force here. The prompt cannot discover bounded contexts from raw business requirements; pair it with the Bounded Context Discovery Prompt if you are earlier in the design process. Also avoid this prompt when the goal is runtime data lineage or cataloging; it produces a static ownership assignment, not a dynamic metadata system.

Before running this prompt, assemble your inputs carefully: list each service with its current or proposed responsibilities, enumerate every data entity (include tables, event streams, and materialized views), and document the integration points where services read or write each other's data. The prompt's value comes from forcing explicit justification for every ownership row, so incomplete inputs produce an ownership matrix that hides rather than reveals coupling risks. After receiving the output, treat the shared kernel exceptions as a prioritized risk register—each one represents a place where two services will need coordinated schema changes, and each one should trigger a conversation about whether the boundary is correct or whether an anti-corruption layer is the cheaper path. The next step is to feed the ownership matrix into your API contract design and database-per-service migration planning workflows.

This prompt template is designed to be pasted directly into your AI tool of choice. It accepts a system design document, architecture description, or a list of services and data entities as input. The prompt instructs the model to act as a data architect and produce a rigorous ownership matrix. Before running it, ensure you have gathered the necessary context: a list of services, the data entities they interact with (tables, event types, read models), and any known integration points. This prompt is most effective when you are in the early stages of a microservice decomposition or are auditing an existing system for data ownership conflicts that could lead to a distributed monolith.

Below is the copy-ready template. Replace all square-bracket placeholders with your specific context. The [SERVICES_AND_ENTITIES] placeholder is the most critical; provide it as a structured list or a markdown table mapping service names to the data entities they currently read or write. The [CONSTRAINTS] section is where you enforce organizational rules, such as 'No service may directly access another service's database.' If you have a preferred [OUTPUT_SCHEMA], provide a JSON schema or a detailed markdown table structure. If left blank, the prompt will default to a standard matrix format.

markdownCopy
You are a senior data architect reviewing a system design for cross-service data ownership. Your task is to analyze the provided services and data entities to produce a definitive ownership matrix.

## Input Context
- Services and Data Entities:
[SERVICES_AND_ENTITIES]

- System Design Document (Optional):
[SYSTEM_DESIGN_DOCUMENT]

## Constraints and Rules
Apply the following rules strictly when determining ownership:
[CONSTRAINTS]

## Output Schema
Produce the final output in the following format. If no schema is provided, use the default matrix structure.
[OUTPUT_SCHEMA]

## Default Output Structure (if no schema provided)
1.  **Ownership Matrix:** A markdown table with columns: Data Entity, Owner Service, Justification, Access Pattern (Read/Write), and Conflict Status (Yes/No).
2.  **Shared Kernel Exceptions:** A list of data entities that are intentionally shared, with a justification for why a shared kernel is acceptable and a list of the services that share it.
3.  **Anti-Corruption Layer (ACL) Requirements:** For any entity where a non-owner service requires access, specify the owner service, the consuming service, and the required ACL contract (e.g., 'Consuming service must map OwnerService.UserCreated event to its internal LegacyUser object').
4.  **Conflict Resolution Notes:** A summary of any ownership conflicts found and a recommended resolution for each.

## Analysis Instructions
1.  Identify a single owner for each data entity based on the principle of high cohesion and low coupling. The owner is the service responsible for the entity's lifecycle, schema, and consistency.
2.  Flag any entity that is written by multiple services as a conflict.
3.  For read-only access by non-owners, recommend an integration pattern (e.g., event subscription, API query, ACL) instead of direct database access.
4.  Justify every ownership decision with a brief, concrete reason tied to business logic or transactional boundaries.

After pasting the prompt, the most critical adaptation step is to populate the [SERVICES_AND_ENTITIES] placeholder with high-fidelity data. A vague input like 'User service uses the orders database' will produce a vague analysis. Instead, provide a detailed mapping such as 'UserService writes to the users table and publishes UserCreated events. OrderService reads from users via an API and writes to the orders table.' The quality of the output matrix is a direct function of the granularity of this input. For high-risk systems, you should add a [CONSTRAINTS] rule requiring that the final matrix be reviewed by a human architect before implementation, and you can use the [OUTPUT_SCHEMA] to enforce a machine-readable JSON format that can be automatically validated against your service catalog.

This prompt is designed to run as a batch analysis job triggered by architecture review milestones, not as a real-time user-facing endpoint. The typical integration pattern is: a platform engineer or architect uploads a service inventory and data catalog (as structured JSON or YAML), the harness injects them into the [SERVICE_INVENTORY] and [DATA_CATALOG] placeholders, and the model returns a structured ownership matrix. Because the output directly informs service boundary decisions and database migration planning, the harness must enforce schema validation, log every run for auditability, and require human review before any implementation work begins.

Model choice and tool use. Use a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and enable structured output mode with the OwnershipMatrix schema defined in the Output Contract section. Do not rely on unstructured text parsing. If the model supports tool calling, register a submit_ownership_matrix tool with the exact schema rather than hoping the model emits valid JSON in the chat stream. For large service inventories (50+ services, 200+ data entities), split the input into bounded context groups and run the prompt once per group to stay within context windows and reduce hallucination risk. Do not use RAG for this prompt—the entire service inventory and data catalog must be in-context for the model to reason about cross-service conflicts.

Validation and retry logic. After the model returns an ownership matrix, run a deterministic post-processing validator that checks: (1) every data entity from the input catalog appears in the output with exactly one owning_service, (2) no shared_kernel_entities reference a service not in the inventory, (3) every acl_required entry includes a non-empty translation_rules field, and (4) conflict_notes are present for any entity where ownership_confidence is below 0.7. If validation fails, retry once with the validation errors injected into a [PREVIOUS_ERRORS] placeholder appended to the prompt. If the second attempt also fails, escalate to a human reviewer with the partial output and error log. Never silently accept an invalid matrix.

Human review and approval gate. This prompt's output is a decision-support artifact, not an automated decision. After validation passes, the ownership matrix must be routed to the owning architecture team for review. The harness should render the matrix as a readable table (with color-coded confidence scores and conflict flags) and require explicit approval before the matrix is committed to the architecture decision record. Store the approved matrix, the raw model output, the validation results, and the reviewer's identity in a versioned artifact repository. This creates an audit trail for future service boundary changes and makes it possible to revisit ownership decisions when the system evolves.

Logging and observability. Log the full prompt (with placeholders resolved), the model response, validation results, retry count, and human review outcome to your prompt observability system. Key metrics to track: validation pass rate on first attempt, average ownership confidence scores, frequency of shared kernel exceptions, and time-to-review. If you see ownership confidence scores trending downward across runs, it may indicate that your service inventory or data catalog has grown too large for the model's context window—split the analysis into smaller groups. If conflict notes are consistently empty even for low-confidence assignments, your prompt's conflict-detection instructions may need strengthening.