---
title: Shared Personas
document_id: shared-personas
owner: Product Spec Maintainers
status: draft
created: 2026-03-16
last_updated: 2026-03-17
---

# Shared Personas

Feature specs should reference persona IDs from this document instead of re-describing common users in each PRD. Add feature-local persona detail only when a workflow, approval path, or operational constraint is unique to that feature.

## How to Use

- Reference personas by ID in PRDs, scenarios, and rollout sections.
- Use primary and secondary persona labels in feature docs when prioritization matters.
- Keep new personas broad enough to apply across multiple database, CDC, platform, and managed-service features.

## PER-001 Data Platform Engineer

Name:
Data Platform Engineer

Summary:
Builds and operates shared data infrastructure such as databases, CDC pipelines, stream delivery, and schema governance for application teams.

Responsibilities:
- Provision and configure shared data services.
- Define data movement, replication, and integration patterns.
- Validate performance, reliability, and upgrade readiness.
- Support migrations between infrastructure stacks.

Success Criteria:
- Platform services meet reliability and throughput targets.
- New features reduce custom glue code and operational toil.
- Application teams can adopt platform capabilities with clear patterns.

Common Pain Points:
- Hidden compatibility limits during rollout.
- Operational burden from bespoke integration layers.
- Difficult debugging across database and message delivery boundaries.

## PER-002 Application Developer

Name:
Application Developer

Summary:
Builds services that depend on transactional data, events, or managed infrastructure capabilities and wants predictable contracts with minimal infrastructure-specific logic.

Responsibilities:
- Integrate application code with platform APIs, schemas, and event contracts.
- Preserve business correctness during writes, reads, and event publication.
- Validate that infrastructure behavior matches application expectations.

Success Criteria:
- Application workflows remain correct under failure and retry conditions.
- Required integrations are simple to understand and adopt.
- Feature behavior is documented in terms of user-visible contracts.

Common Pain Points:
- Ambiguous behavior under failover or retries.
- Excessive application-side logic to compensate for infrastructure gaps.
- Unclear ownership boundaries between app teams and platform teams.

## PER-003 SRE / Platform Operator

Name:
SRE / Platform Operator

Summary:
Runs production infrastructure and is accountable for availability, safe changes, incident response, and operational hygiene.

Responsibilities:
- Deploy, upgrade, and recover distributed services.
- Monitor system health, lag, capacity, and error states.
- Triage incidents and coordinate rollback or failover actions.
- Enforce operational standards across environments.

Success Criteria:
- Unhealthy states are visible early and diagnosable.
- Recovery paths are documented and safe to execute.
- Features fit existing deployment and monitoring practices.

Common Pain Points:
- Silent failure modes or weak telemetry.
- Features that work only in greenfield environments.
- Unsafe upgrade paths or unclear rollback boundaries.

## PER-004 Security / Compliance Reviewer

Name:
Security / Compliance Reviewer

Summary:
Assesses whether new capabilities meet authentication, authorization, data handling, audit, and compliance expectations before production approval.

Responsibilities:
- Review security boundaries and threat exposure.
- Validate handling of secrets, credentials, and sensitive data.
- Confirm auditability and policy alignment.
- Identify exceptions that require compensating controls.

Success Criteria:
- Security-relevant behavior is explicit and reviewable.
- Sensitive data handling is minimized and justified.
- Required controls can be verified during design and rollout.

Common Pain Points:
- Security assumptions hidden inside implementation details.
- Missing audit trails for privileged or data-accessing actions.
- Broad permissions granted for operator convenience.

## PER-005 Cloud Service Team / Internal Service Operator

Name:
Cloud Service Team / Internal Service Operator

Summary:
Runs a managed service or internal shared platform where many tenants or teams depend on consistent defaults, policy control, and safe lifecycle management.

Responsibilities:
- Package product capabilities into managed service workflows.
- Set defaults, quotas, and guardrails for tenant environments.
- Coordinate multi-tenant rollout, maintenance, and support.
- Balance customer flexibility with platform safety.

Success Criteria:
- Features can be enabled with clear defaults and policy boundaries.
- Multi-tenant operations remain predictable during upgrades and incidents.
- Support teams can diagnose customer-impacting issues quickly.

Common Pain Points:
- Features that assume direct host-level access.
- Configuration models that do not scale across many tenants.
- Weak isolation or noisy-neighbor operational behavior.

## PER-006 Database Reliability Engineer

Name:
Database Reliability Engineer

Summary:
Owns production database reliability, workload performance, and cross-team diagnosis for shared or business-critical database deployments.

Responsibilities:
- Investigate slow queries, hot spots, lock contention, and workload regressions.
- Tune database configuration and workload-specific performance behavior.
- Connect database telemetry to application ownership during incidents.
- Define safe operational standards for database observability and diagnostics.

Success Criteria:
- Database issues can be attributed quickly to the right service, tenant, or workload owner.
- Performance regressions are visible before they become broad incidents.
- Diagnostic tooling helps database and application teams collaborate on one shared fact set.

Common Pain Points:
- Database telemetry lacks enough application context to identify the real owner of a problem.
- Shared clusters make it difficult to separate noisy-neighbor issues from platform issues.
- Root-cause analysis depends on manual correlation across slow logs, dashboards, and application traces.