robsonkades/agent-skills/service-data-ownership

Service Data Ownership

Purpose

Turn "Orders owns these data" into a contract that legitimate consumers can use and unauthorised callers cannot bypass. The result includes effective access controls and evidence of permitted and denied operations, not only an ownership diagram.

Authority belongs to the boundary that decides an invariant and accepts corrections to its facts. Several service replicas or approved workers can implement that authority; one owner does not mean one process. A database object owner is a privilege-bearing role, not automatically the business authority. A replicated fact, derived projection or cache needs a custodian and source lineage without becoming a competing authority.

The architectural core has no imposed Java, Spring or database baseline. Inspect the target's toolchain, resolved framework/driver versions, database engine/version and deployment identities before using version-sensitive guidance. The PostgreSQL 17 and Spring Framework 6.2 references are conditional examples, not upgrade requirements.

Boundary and handoffs

Activate for ambiguous write authority, cross-service SQL, hidden integration writers, overprivileged runtime identities, or exceptions that have become permanent.

• distribution-boundaries owns whether to distribute and the initial ownership line;

this skill supplies the access contract and proof that the line holds.

• distributed-transactions-and-sagas owns coordination across authoritative writers;

do not silently replace a required atomic invariant with eventual consistency.

• cross-service-query-design owns query composition, freshness and projection recovery.

Supply approved data interfaces and authoritative versus derived facts to it.

• spring-boot-jpa and spring-transactions-and-events own persistence and transaction

mechanics; online-database-schema-migrations owns DDL rollout. This skill checks which identities may perform them and whether runtime wiring respects that decision.

• legacy-enterprise-modernization and change-data-capture-operations own transfer,

backfill and CDC operation. Supply authority before/during/after the transition; do not invent a dual-write protocol here.

• service-identity-and-trust owns workload trust; spring-security-for-apis owns its

Spring enforcement. Service credentials do not confer unrestricted user/tenant access.

These are optional specialist handoffs, not prerequisites for a small ownership review. For a local SQL performance issue with clear access authority, route to sql-query-performance instead of redesigning ownership.

Workflow

1. Identify facts and invariants. Read current ADRs, contracts, schema changes and

owning code. Name who decides validity, who can correct a fact, and which operations require authoritative state at the moment of the effect. Distinguish orders' delivery address snapshot from a customer's current address rather than assigning both by a shared column name. Record disputed ownership; do not assign it from table location.

1. Inventory actual access. Trace repositories, native SQL/JDBC, stored procedures,

triggers, scheduled jobs, batch imports, CDC sources/sinks, repair scripts, reporting, migration runners and administrative access. Join code evidence to deployed identities, effective grants/role membership, consumer contracts and available audit records. Include old deployments and dormant jobs. A repository search alone cannot establish that no external writer exists; unavailable grants or unobserved schedules stay unknown.

1. Classify each path. Record the principal, data subset, operation, business purpose,

authority or derivative status, supported interface, enforcement point and evidence. A published SQL view/export may be an explicit read contract; private base-table SQL is not made supported by widespread use. Read the access-contract reference when constructing this inventory, deciding a supported read interface, or handling exceptions.

1. Choose the smallest enforceable boundary. Retain shared infrastructure if its

capacity, recovery and trust constraints fit. Compare private tables, schemas and databases using actual permission mechanisms; separate servers are conditional on isolation needs. For every consumer, choose an owner operation, supported read surface, derivative copy, or explicitly bounded exception. Preserve adequate existing contracts.

1. Close bypasses in the requested scope. For implementation, change relevant callers,

credential references, grants, migration identity wiring and operational documentation together. Keep business checks at the authority, exposing use-case operations and contract DTOs rather than another service's JPA repository/entity model. For Java/Spring wiring or relational privilege enforcement, read enforcement and verification. For review, return evidenced gaps and proposed fixes without silently changing production access.

1. Sequence changes without losing legitimate work. Establish and test the supported

path with least-privileged identities, move callers, then revoke obsolete access with an accountable recovery plan. Do not blindly remove an unknown job's permissions or restore an unrestricted shared credential as the default rollback. A temporary exception needs a concrete exit path and enforceable expiry; migration writers require an explicit transfer protocol from the migration owner before claiming exclusivity.

1. Verify and report. Exercise allowed operations and hostile bypasses against the

intended engine and deployed identity shape in an isolated environment. Check current objects, newly created objects and exception revocation, including pooled sessions. Distinguish static/package checks, executed runtime tests, written cases and remaining operational evidence. Grant listings or successful normal traffic alone do not prove denial of prohibited access.

Decisions that change the answer

Minimum useful result

For a narrow task, return only the affected contract rows and their verification. For a broader design or implementation, provide:

• Facts/invariants, authoritative owners and derivative lineage, with unresolved disputes.
• Reader/writer inventory and supported access contracts tied to actual principals and

enforcement artifacts; include grant changes or caller changes when implemented.

• Exceptions with scope, responsible owner, expiry, replacement, revocation mechanism

and proof; operational recovery that preserves the required boundary.

• Allowed/denied test evidence, environment/version and coverage limits; next evidence

that would change the recommendation. Do not report "enforced" while a decisive identity, grant path or external writer remains unverified.

The design distinction between private data and dedicated hardware is supported by Database per service. The access-contract details here are an architectural synthesis; their enforcement must be demonstrated in the target environment, not inferred from that pattern description.