Priya Platformson — Platform Operator

Name: Priya Platformson
Quote: “If it pages me at 3am it had better be real, and if it’s real it had better page me.”

Unlike the other personas on this page, Priya is internal to Arda. The kanban-loop personas are customers; Priya is the engineer who keeps the platform those customers depend on running. She is included in the catalog because OAM-plane work has a genuine user, and designing for her was previously impossible — there was no entry to point at.

Professional Background

Job Role/Title: Platform engineer with on-call responsibility. In a team of Arda’s size this is not a dedicated role — it is a hat worn in rotation by whoever is closest to the infrastructure. Distinguished from a backend or frontend engineer by concern: they own a component’s behavior, Priya owns whether the platform as a whole is healthy, observable, and recoverable.
Company Information: Arda itself. A small engineering team operating a multi-tenant platform across four partitions (dev, stage, demo, prod) on two AWS infrastructures, with customers whose daily operations depend on the system being available.
Responsibilities: Responding to production faults; maintaining the alerting configuration that decides what constitutes a fault; deploying and operating infrastructure through amm.sh and the CDK tree; investigating incidents across CloudWatch, Sentry, and Kubernetes; keeping the OAM plane’s own tooling honest. Owns the question “would we find out if this broke?”
Career Path: Came from backend or infrastructure engineering. Comfortable in Kotlin and TypeScript, fluent in AWS, reads Helm charts without flinching. Has been paged by a badly-configured alert enough times to hold strong opinions about signal-to-noise.

Goals and Motivations

Professional Goals:
- Every real fault produces exactly one actionable notification. Not zero, and not five.
- Know the state of alerting configuration without opening a vendor UI and clicking through seven rules.
- Change alerting the same way everything else changes — a reviewed diff, not a click in someone’s browser.
- Reduce mean time to detection. A fault the team learns about from a customer is a failure of her work, not the customer’s patience.
- Keep the OAM plane’s tooling boring. It is what she reaches for when things are already going wrong.
Motivations:
- Trust in the alerting. An alert she has learned to ignore is worse than no alert, because it teaches the whole team to ignore that channel.
- Recoverability. Every change she makes should be reversible, and she should know how before she makes it.
- Not being the only person who understands the setup. Configuration in a repo is knowledge the team shares; configuration in a UI is knowledge she is personally responsible for remembering.

Challenges and Pain Points

Obstacles:
- Alerting configuration lives in vendor UIs. Seven Sentry rules across two projects, edited by hand over months by whoever needed something. No history of intent, no review, no way to answer “what changed?”
- Silent misconfiguration. The failure mode she fears most is a rule that looks correct and fires on nothing — an environment filter naming an environment that project never emits, a rule attached to no detector, a disabled rule everyone assumes is live. Nothing alerts you that your alerts are broken.
- Duplicate and overlapping rules produce multiple notifications for one fault, which trains the team to dismiss them.
- Cross-cutting configuration is invisible. A rule attached to two projects looks like one thing in the UI and behaves like two, and the difference only shows up when one half stops working.
- No drift detection. A colleague fixing something at 2am in the UI is indistinguishable from intended state a week later.
- Divergent conventions between components. The frontend and backend name their environments differently for historical reasons, so any cross-component configuration has to absorb the divergence or silently break.
Fears/Objections:
- Deleting alerting configuration and discovering afterward that something depended on it.
- A destructive change with no snapshot to restore from.
- Automation that mutates production alerting without an explicit confirmation step.
- Tooling that proposes deleting rules it does not own.

How Arda Serves Priya

Priya does not use the Arda product. She operates the platform that delivers it. Her surfaces are the infrastructure repository, the OAM plane’s tooling, and the observability vendors it configures.

The design principles that follow from her needs:

Dry-run by default. Nothing mutates without explicit intent.
Snapshot before mutation. Every destructive action has a recorded prior state.
An explicit managed set. Tooling touches only what it owns and reports the rest as untracked.
Loud failure over silent success. A configuration that cannot match anything is an error at plan time, not a mystery at incident time.
Reviewable diffs. Alerting changes arrive as pull requests.

Relationship to Other Personas

Priya has no direct contact with the kanban-loop personas. Her work reaches them only through absence: when it goes well, Sam scans a card and it works, and Priya is invisible. She shares an interest in reliability with Owen Ownerton, whose business case assumes the platform is available, and she is the escalation point behind Charlie when a support issue turns out to be a platform fault rather than a user problem.