sysadmin-chronicles/docs/design/CHARACTERS.md

# Characters — Sysadmin Chronicles

Story design reference. All characters, bios, relationships, and open story hooks.
For company/world context see `COMPANY_LORE.md`. This file focuses on the people.

---

## Active Characters

These characters have an established in-game voice and presence. Any new quest work
should treat their characterization here as canonical.

---

### The Player
**Role:** New junior sysadmin hire, day one  
**Identity:** Unnamed. Player-selected portrait (5 options).

Hired to replace Dale. Nobody will explain what Dale did. Badge number is still
pending — temp credentials were handled by someone in Finance on their first day.
The player is a competent professional, not a bumbling intern. They may not know
every answer but they know how to look.

The player has no spoken lines. Their character is expressed entirely through the
choices they make when fixing things — whether they understand root causes or just
clear symptoms, whether they leave systems better or just less broken.

---

### Marcus Webb
**Role:** Senior Systems Administrator  
**Email:** `m.webb@axiomworks.internal`  
**Reports to:** Dave Kowalski (Director of IT)

Six years at Axiom Works. Hired by Kowalski. Knows where everything is, why it's
there, and which parts were a mistake. Communicates in short, precise messages.
Does not explain things twice. Trusts competence over credentials — he will give
the player more rope as they demonstrate they know what to do with it. If they
don't, the rope gets shorter.

He was the one who onboarded the player. He assigned their first ticket. He will
assign most of the tickets that follow. His messages range from brief task
assignments to late-night observations about something that's been on his mind —
the latter usually mean something is about to become a problem.

He knows what Dale did. He has decided not to discuss it.

**Personality:** Dry. Technically precise. Does not perform enthusiasm. Occasionally
wry but never jokey. Respects players who fix root causes. Mildly annoyed by
players who fix symptoms and call it done.

**Relationships:**
- Kowalski: reports to him; respectful but not deferential
- Sarah: professional; takes her tickets seriously, occasionally says quiet things when she's wrong
- Priya: mutual professional respect; they operate in the same zone of "things that matter when they go wrong"
- Phil Ruiz (Sales VP): warm; Phil owes Marcus for saving a demo once and Marcus has never mentioned it

---

### Sarah Chen
**Role:** Product Manager, AxiomFlow  
**Email:** `s.chen@axiomworks.internal`

Owns the AxiomFlow product roadmap. Coordinates between sales, engineering, and
customers. Emails Monday mornings. Cares intensely about the demo and staging
environments because those are the product she can actually see and touch. Not wrong
about their importance.

She files tickets when things break on the product-facing side. Her descriptions of
problems are accurate about symptoms and often wrong about causes — she will
confidently diagnose a permissions issue as a script bug, or a package problem as a
config error. She is not incompetent; she just doesn't have the full picture. When
the player fixes the underlying cause rather than the surface symptom, she notices.

She has a sharp edge when things get worse after someone touches them. She will say
so, clearly, without being melodramatic about it.

**Personality:** Direct. Metric-oriented. Not patient with vague timelines or "we're
looking into it." Appreciates being told what the actual problem was, not just that
it's fixed.

**Relationships:**
- Marcus: professional; trusts that her tickets will be handled, doesn't ask for much
- Player: initially impersonal (they're new); warms or cools based on outcomes
- Nikhil Sharma: upstream dependency — his build pipeline affects her deployments

---

### Priya Nair
**Role:** Head of Security & Compliance  
**Email:** `p.nair@axiomworks.internal`  
**Direct report:** James Osei (Security Analyst)

Leads all security reviews, access audits, and compliance programmes. Has a standing
Thursday meeting with David Park (CTO) that has existed since 2017. Was brought in
after an incident nobody discusses in public. Has been building the security function
from something informal into something that can survive a SOC 2 audit.

She frames everything in terms of what happens when things go wrong, not whether they
will. She assumes breach. She assumes misconfiguration. She is often right. She is
not someone who appreciates hearing about a production change after it has already
happened.

She will tell the player when a fix is correct and why. She will also tell them when
a fix works but leaves the environment in a worse position than before. She is not
punitive about this — she just states it.

She does shift reviews at end-of-shift and grades the player's overall performance.
Her criteria: did the work move forward, did the environment stay stable, did the
player create extra problems.

**Personality:** Precise. Consequence-focused. Calm in tone even when the content
is not calm. Economical with words. Does not use exclamation marks.

**Relationships:**
- Player: evaluative; her trust is earned by demonstrating that security is a
  consideration, not an afterthought
- Marcus: peer respect; they operate in different domains with overlapping concerns
- Dave Kowalski: reports indirectly up through him for infrastructure decisions
- David Park: standing Thursday meeting; she has the CTO's ear

> **Name note for developers:** The in-game email service and some ticket files
> previously used "Priya Kapoor" and the onboarding doc used "Priya Singh."
> These are all the same character. **Priya Nair** is the canonical name.
> Email should be `p.nair@axiomworks.internal`. Update references in
> `server/src/services/EmailService.js`, `content/tickets/T007.json`, and
> `content/docs/onboarding.json`.

---

### Dave Okonkwo
**Role:** Internal employee, non-technical  
**Email:** `d.okonkwo@axiomworks.internal`

A regular Axiom Works employee who notices when things aren't working and files
tickets about it. He doesn't know enough to diagnose the problem — he reports
symptoms accurately and assumes the wrong cause. His reports are useful precisely
because they represent what a non-technical user actually experiences.

He is not on the company website (280 employees, most of them aren't). He's
somewhere in operations or general staff. He's not in Finance, not in IT.

> **Open decision:** Dave Okonkwo is currently the only employee-level character who
> submits tickets. The company website has Dave Kowalski as Director of IT Operations
> (Marcus's boss), which is a completely different person. This is not a naming
> inconsistency — they're two different people. However: if the story wants Kowalski
> to become an active character who also files tickets or escalates issues, that's a
> separate thread. Okonkwo and Kowalski coexist.

---

## Named Background Characters

On the company website. No current in-game presence. Available for story use —
they can send emails, appear on CC lines, be referenced in dialogue, or become
active characters in new quests.

Listed in rough order of story relevance to the IT/sysadmin context.

---

### Dave Kowalski — Director of IT Operations
Marcus's manager. The player's skip-level. Background is network engineering —
has Cisco certifications he will not volunteer unless provoked. Oversees systems
(Marcus's domain), networking (Tom Malaney), and IT support. Has been at Axiom
Works since 2015. Describes the infrastructure as "mature." Sends weekly status
emails in bullet points that never quite answer the question. When things go wrong
he schedules a meeting to "talk through the situation," which everyone has learned
is worse than a direct message.

Has said "we should really document that" more times than he can count. Has
documented very little personally. Maintains a mysterious Tuesday 2–3pm calendar
block.

Story use: source of policy pressure, indirect escalation, the person who asks
questions that reveal Marcus hasn't told the player everything.

---

### Nikhil Sharma — Platform Engineer
Owns the internal build and release pipeline, the CI infrastructure, and the
parts of deployment that nobody else wants to think about. Strong opinions about
reproducible builds. Sends Slack messages at 6am. Occasionally at 11pm.

He is the engineer most directly connected to what happens on vulcan — if a build
is broken, it's probably something Nikhil built or maintains. He has never met the
player. He almost certainly doesn't know the player exists.

Story use: the author of broken packages the player has to debug; a character who
can explain (or fail to explain) what went wrong upstream; an escalation path when
a build problem is genuinely his fault.

---

### Tanya Okafor — Head of Customer Success
Manages post-sale relationships for all AxiomFlow customers and the twelve legacy
AxiomSync accounts that haven't migrated. Uses the word "partnership" a lot.

Usually the first person to know when something is wrong in production, because a
customer has already called her before IT knows there's a problem. Her call log
is an early warning system. She is not hostile to IT but she has learned that
"we're looking into it" is not an answer she can give a customer.

Story use: pressure vector from the customer direction; source of urgency that
doesn't come from Marcus or the ticket queue; demonstrates real-world stakes when
things go down.

---

### Phil Ruiz — VP of Sales
Has been promising features to prospects since 2016. Maintains a warm relationship
with the infrastructure team because Marcus once fixed the staging environment with
twenty minutes to spare before a major demo — Phil has never forgotten this. Travels
frequently. Expense reports submitted promptly, which Marcus has noted approvingly.

Story use: indirect beneficiary when demos work; pressure source when a sales demo
is scheduled and something is broken; the person who will tell the CTO what IT did
right in a room the player will never be in.

---

### Yusuf Halabi — Engineering Manager
Reports to David Park (CTO). Manages the core AxiomFlow platform team. Runs the
Thursday architecture review. Has opinions about test coverage. Leaves pull request
comments that are technically correct and diplomatically suboptimal.

Story use: engineering-side escalation; source of tickets about internal tooling;
the person who will ask why a config change broke a downstream process.

---

### Derek Ashford — Financial Controller
Does not appear at team meetings. Does appear on CC lines of every email that
mentions cloud costs, hardware procurement, or infrastructure budget. Always
replies-all. His manager is Rachel Brandt (CFO).

Story use: background texture on procurement requests; the voice that makes any
infrastructure spending feel like a negotiation.

> **Note on "Dave from Finance":** Marcus's day-one message references "Dave from
> Finance" as the person holding the player's temp credentials. This is almost
> certainly Derek Ashford — Marcus using his first name informally, or a
> continuity error. Derek Ashford is the only Finance character plausibly holding
> IT credentials. His first name is Derek, not Dave — either the message should
> be corrected, or "Dave from Finance" is a third unnamed Finance employee.

---

### Rachel Huang — Systems Administrator
Marcus's peer on the IT team. Handles provisioning, patch cycles, and the ongoing
negotiation with Finance over cloud consolidation. Came from a managed services
background. Has strong opinions about monitoring dashboards, most of which are
correct.

Story use: the person who set something up that the player now has to maintain;
a colleague who can provide context Marcus won't; someone whose provisioning
decisions the player will encounter as infrastructure.

---

### Tom Malaney — Network Engineer
Responsible for network infrastructure across the office and hosted environments.
On-call for more holiday weekends than he would like. Thorough in documentation
when he finds time for it.

Story use: DNS, firewall, or routing problems that are not the player's fault
but become the player's problem; someone who can be reached but is slow to
respond.

---

### James Osei — Security Analyst
Priya's direct report. Handles vulnerability assessments, access reviews, and
quarterly compliance reporting. Methodical. Has a spreadsheet for everything,
which is not a criticism.

Story use: the person who runs the actual audit that Priya will summarize to the
player; a source of detailed (sometimes overwhelming) security findings.

---

### Ellen Marsh — CEO & Co-Founder
Built the first version of AxiomFlow after a decade in operations. No CS background.
Attends all-hands twice a year. Does not use Slack. Has final say on pricing and
major customer commitments.

Story use: the distant authority whose priorities shape everything; never interacts
with the player directly, but her decisions land as constraints.

---

### David Park — CTO & Co-Founder
Wrote the original rules engine in 2011. Now manages engineering managers. Still has
opinions about the data model. Has a standing Thursday meeting with Priya that hasn't
moved since 2017.

Story use: architectural decisions from above; the person Priya reports significant
security findings to.

---

### Karen Volkov — COO
Joined 2014. Responsible for the fact that the company has documented processes for
anything at all. Has opinions about infrastructure costs that surface in IT's world
via Finance. Prefers decisions with clear owners and deadlines.

---

### Rachel Brandt — CFO
Joined 2016. Approves all capital expenditure over $5,000. Working to consolidate
cloud spend. Does not enjoy surprises in the infrastructure budget. Derek Ashford
reports to her.

---

### Mei Lin — Senior Software Engineer
Has maintained AxiomSync's integration layer since 2018. Knows more about it than
anyone would prefer, including herself. Currently leading the migration tooling
project for the remaining legacy accounts.

---

### Cora Reyes — Software Engineer
Works on the AxiomDash reporting pipeline. Has submitted more internal RFCs than
anyone else on the team in the past year. Moving toward senior.

---

### Ben Portillo — Product Manager, AxiomDash
Leads product development for the analytics add-on. Works closely with large
accounts to understand what they actually want from dashboards (usually different
from what they asked for).

---

### Annika Gosse — UX Designer
Responsible for AxiomFlow's interface. Has been advocating for a redesign of the
workflow builder since 2022. Patient.

---

### Sandra Wu — HR Manager
Manages hiring, onboarding, and employee relations since 2016. Runs the new-hire
onboarding process (three days, thorough). Sends birthday emails on time, every time.

---

### Owen Blake — Office Manager
Keeps the office running. Has fixed more things than his job title implies. The
person to contact if conference room equipment stops working.

---

### Mike Kawamoto — Account Executive
Handles mid-market manufacturing accounts in the northeast. Believes strongly in
the demo environment. Closes more deals in Q4 than any other quarter.

---

### Lisa Ferreira — Customer Success Manager
Manages onboarding for new AxiomFlow deployments. Has a talent for understanding
what customers mean rather than what they say.

---

## Unresolved Characters (Story Hooks)

These are referenced in existing content but never defined. They represent the
strongest open narrative threads.

---

### Dale — The Previous Sysadmin
**Reference:** Marcus's day-one message — "You're replacing Dale. Nobody will tell you
what Dale did because it's complicated."

Dale is gone. The player has their desk, their access provisioning slot, and
apparently their reputation — people know the player is "Dale's replacement" before
they know the player's name. The systems the player inherits are the systems Dale
last touched.

What Dale did is unknown. It is described as "complicated." Marcus knows. Possibly
Kowalski knows. Possibly Priya knows, if it was security-related.

This is the strongest existing narrative mystery in the game. It has setup and no
payoff. Dale's story could be:
- A technical incident (something Dale broke and couldn't fix)
- A policy violation (something Dale did that wasn't malicious but wasn't right)
- A trust collapse (competent but burned bridges)
- Something personal
- Any combination

The player finding out what Dale did — gradually, through the systems they work on,
through things people let slip — is a natural story spine for the whole game.

---

### "Dave from Finance" — Day One Reference
**Reference:** Marcus's day-one message — "Dave from Finance has your temp credentials.
He's on three today."

Almost certainly Derek Ashford (Financial Controller), referred to informally. But
Derek's first name is Derek, not Dave — this is either Marcus being casual with
names, a continuity error, or a genuinely separate unlisted Finance employee.

Needs a decision: correct "Dave" to "Derek" in Marcus's message, or introduce a
separate "Dave from Finance" as a minor character.

---

## Key Relationships Map

```
Ellen Marsh (CEO)
  └── David Park (CTO)
        └── Yusuf Halabi (Eng Manager)
              ├── Mei Lin
              ├── Cora Reyes
              └── Nikhil Sharma
  └── Karen Volkov (COO)
  └── Rachel Brandt (CFO)
        └── Derek Ashford (Financial Controller)
  └── Phil Ruiz (VP Sales)
        ├── Mike Kawamoto
        └── Tanya Okafor
              └── Lisa Ferreira

Dave Kowalski (Director of IT)
  ├── Marcus Webb  ←── Player's manager
  │     └── [Player]
  ├── Rachel Huang
  └── Tom Malaney

Priya Nair (Head of Security)
  └── James Osei

Sarah Chen (Product, AxiomFlow)  ←── frequent ticket source
Ben Portillo (Product, AxiomDash)
Annika Gosse (UX)
```

---

## Tone Notes for New Story Work

- **Marcus talks like someone who has answered this question before.** Precise, low
  affect, no wasted words. Never condescending — just efficient.
- **Sarah talks like a PM: outcome-focused, slightly impatient, specific about
  what she needs.** She is not a villain. She has real deadlines.
- **Priya talks like someone who has already thought about what goes wrong.** She
  doesn't speculate — she states. She's not alarming, she's matter-of-fact.
- **Dave Okonkwo talks like someone who doesn't know what the problem is** but is
  trying to be helpful by reporting exactly what he observed. He should never be
  made to look stupid — he's doing the right thing.
- **The company takes itself seriously.** Humor comes from the gap between official
  language and reality, not from anyone being a cartoon.
- **Problems have plausible causes.** Systems broke because someone made a
  reasonable decision under time pressure, not because they were careless idiots.
  The player should feel like a professional, not a janitor.