# 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.