CASE FILE

VANGUARD · STAR CITIZEN ORG · COMMUNITY ERP

The real job was an operating system.

CASE FILE

THE HONEST PREFACE

A feature list this long usually means scope creep. We’d rather you think it than swallow it.

Let’s get the obvious objection out of the way first: a list of features this long usually reads like scope creep, billable-hours padding, or both. We know. So we’re not asking you to take the scope on faith — we’re going to show you why each piece exists, what got validated before it was built, and what the org would have had to bolt together from purchased tools to get the same result. If the math holds, the scope stops being impressive and starts being obvious. That’s the test we want you to run.

One more thing to state plainly: this platform was architected and directed via AI orchestration — the modern way to ship a system of this scale. We designed the architecture, directed the build, and are accountable for every decision it reflects. We are not claiming tens of thousands of lines of hand-written code. We are claiming the judgment required to architect, direct, and deliver a coherent production platform of this complexity — and we think that’s the more interesting story.

THE ORIGIN

This didn’t start with a pitch. It started with membership.

The reason we can tell this story is that we were already in it. We joined Vanguard to play Star Citizen. When we saw the operational weight the org was carrying on a SaaS patchwork — and saw clearly what was actually needed — we offered to build it. The client relationship followed the real problem.

That order of operations matters: the validated insight came from being inside the org, not from a discovery questionnaire.

THE MARKET

Every gaming org buys the same stack — and complains about the same thing.

The standard stack for an organized gaming community looks the same wherever you find one: a Discord server, a hosted wiki, a WordPress or static site, a forum, a calendar app, a spreadsheet for the in-game economy, another for fleet tracking, maybe a third-party LMS, and three-to-seven Discord bots gluing the seams together.

Every org bigger than fifty people complains about the same thing: nothing talks to anything else. Members exist in five places with five sets of credentials. Officers spend hours each week moving data between tools by hand. The whole industry competes on which Discord bot has the prettiest embeds — and nobody asked the question underneath: what does an organization at this scale actually need to keep running?

THE VALIDATED INSIGHT

An org with a real fleet, a real economy, and a real chain of command isn’t running a community. It’s running a small business.

Deep in the org — its officer calls, its after-action reports, its onboarding bottlenecks, its slow attrition — one fact surfaced that nobody was building for. The artifacts this org produces (service records, financial transactions, training certifications, governance decisions, audit logs) have the same operational shape as the artifacts a mid-size company produces. It needs identity management, role-based access control, an immutable audit trail, multi-signature approval for high-stakes actions, double-entry finance, an LMS, a documentation system, and an HR pipeline.

What it does not need is a better Discord bot. The Discord bot is downstream of the organization. The real job was: give the org an operating system, then make Discord the place where members live inside it.

HOW WE PROVED IT BEFORE BUILDING

  • We asked the question that mattered: would leadership actually move their work into a platform we built — or snap back to the SaaS stack the moment it got in their way?
  • Officers told us, in their own words, which spreadsheets they hated, which approvals they were rubber-stamping because the workflow was painful, which bots they’d already replaced twice.
  • We rebuilt one painful workflow end-to-end — the after-action report — watched officers stop dreading the post-event paperwork, and let that result decide whether to keep going. It did.

FROM THE FILE

One platform replaced a dozen tools.

The Vanguard dashboard — the unified shell of sidebar, header, and status bar — replaces a SaaS patchwork whose pieces never talked to each other. One identity layer, one permission model, one audit trail.

THE MECHANISM · PART 1

The operating system: one system whose pieces share identity, permissions, and an audit trail.

The platform replaces the SaaS stack with a single system, built system by system — and each one exists for a reason the org was already paying for.

WHAT WE BUILT

  • Mission Control — a command center, not a calendar. A 7-day Gantt strip shows every operation at a glance; a focus grid surfaces countdown timers, the active op, the queue, the crew roster, and a readiness summary. The hours a spreadsheet cost every officer every week come back here.
  • The Interactive ORBAT — the chain of command, live. The org chart is a node graph rendered from the actual hierarchy, Wings down to billets. Unit and Wing commanders hold scoped permissions to manage their own sub-structures without global admin — delegated authority enforced everywhere downstream.
  • The ledger — a double-entry economy, not a spreadsheet. The in-game economy runs on atomic transactions and immutable logs. Every transfer is auditable; double-spending is structurally impossible; member, unit, and wing wallets reconcile automatically.
  • The Academy — a real LMS, not a course list. Courses with prerequisites and linked curricula, automated quizzes and graded assignments, certifications logged as immutable records, calibration audits that catch instructor drift, and a skill-tree visualizer over the certification pathways. The training program lived in PDFs and tribal knowledge before this.
  • Multi-signature governance — not officer DM threads. High-stakes actions (bans, high promotions, clearance changes, policy proposals) require multiple authorized signatures with tracked identity, timestamp, and an enforced deadline. Two append-only log collections make every administrative action and every sensitive access permanently inspectable.
  • The member dossier — identity, not user accounts. A user is the login object; a member is the org’s actual view of the person — ranks, standings, service records, contributions, chain-of-command relationships. Splitting the two makes a discharge instant and total without losing the immutable record of what that member did.

THE MECHANISM · PART 2

The recruitment engine — built into the operating system, not bolted onto it.

The platform side gets the headlines, but the part that runs quietly underneath is built to change the org’s growth math: a recruitment funnel built into the same system.

WHAT WE BUILT

  • The applicant pipeline — vetting built in, not a Google Form. A multi-step pipeline (Identity → Demographics → Vetting) with server-side RSI handle verification, bot defense, and a Candidate role that quarantines new applicants from member-only data until an officer inducts them — supported by a threat-scoring engine that flags risk factors before a human ever reviews.
  • The public surface — the recruiter is the wing leader. Wing pages and applicant-facing pathways live in the same collection structure as the rest of the platform, so the officer responsible for a wing’s pitch edits the same surface their members see. No CMS in another tab.
  • The Discord bridge — the bot is downstream of the platform. A dedicated Discord sidecar handles the conversational half: onboarding DMs, a /verify command linking Discord identity to platform identity, role-gating after induction, and a self-healing weekly roster reconciliation. What happens in the platform shows up in Discord automatically.
  • The activation pipeline — catch the member before they ghost. A five-state machine (New → Engaged → Converted / At Risk → Graduated) tracks the first 90 days, with automatic transitions on attendance milestones, mentor assignment, and at-risk notifications that surface members the org is about to lose before they go quiet.

FROM THE FILE

The security posture is a visible feature.

Server-side field-level redaction over a six-tier clearance system: scalars masked, classified lists emptied, fail-closed on lookup failure. Tamper-prevention is a database-level constraint, not a policy — and the org can see it working.

EXHIBIT A · ACCESS MODEL

SUBJECTChain of command, encoded

ROLESHierarchical — unit-scoped

AUDITEvery access decision logged

Who can see what, and why.

A unit leader sees their unit — not the one beside it. A certification unlocks exactly the doors it names. Money moves only through atomic, double-entry transactions.

Nothing about the structure is decorative; the permission model is the org chart, enforced.

THE ACCESS MODEL AS BUILT · CAPTURABLE FROM THE LIVE PLATFORM

THE MECHANISM · PART 3

Why this is structurally hard to copy: the integration is the product.

No other gaming org runs on something like this — not because nobody thought of it, but because the surface is large, the data model has to stay coherent across thirty distinct workflows, and the security posture has to actually work, not just "we have logins." The figures below are audit-derived from an independent review of the codebase, not hand-counted.

THE ARCHITECTURE (AUDIT-DERIVED)

  • ~70,000 lines of TypeScript across ~2,670 source files, with generated types on top.
  • 85+ collections sharing a single identity layer; 48 reusable access-control policies (role-based + attribute-based hybrid), with role/permission constants centralized to prevent typo bugs across the surface.
  • 28 domain-specific sanitization utilities — every piece of data leaving the server is filtered through the viewer’s clearance, role, and relationship to the data, not "trust the client."
  • A 6-tier security clearance system with server-side field-level redaction, fail-closed on lookup failure; full GDPR compliance with versioned consent records, a 14-day deletion cooling period, data export, and scheduled retention enforcement.
  • Multi-layer rate limiting (Redis primary + MongoDB fallback) with fail-closed semantics; real-time collaboration via CRDTs and WebSockets with offline persistence; and a two-service architecture with a dedicated Discord sidecar so the main app stays non-blocking.

WHAT THIS IS PROOF OF

This is a capability showcase, not a finished outcome case.

THE EARLY SIGNAL

The org’s active community — roughly 150–200 engaged members; the broader Discord roster is larger but subject to attrition — is running real operations on the platform, and leadership is asking what else to move onto it rather than away from it. That’s a good early signal. It is not a retention statistic, and we won’t present it as one. The platform is new enough that we make no recruitment, retention, or engagement claims.

THE CAPABILITY ON RECORD

What this is proof of is the architecture question: can a team like ours design, direct, and ship a coherent platform at enterprise scale — the permission model, the member/user split, the multi-signature governance, the audit-trail shape, the recruitment funnel, the LMS schema, the Discord-bridge pattern, the field-level redaction, the GDPR plumbing? The codebase is the answer. Any individual piece is buildable; the coherent integration across thirty workflows is the unique product.

WHY AGENTIC ENGINEERING

A system of this architectural breadth is only possible at a reasonable cost and timeline when the architect directs AI tooling at scale rather than hand-writing every line. The judgment is human. The throughput is AI. The result is a production system an org of this complexity can actually own — and the patterns hardened here became the reference build for Tome, the platform Wabbit now ships to other clients.

MORE FROM THE FIELD

See the rest of the work.

WHERE THIS STARTS

Book the Architecture Sprint

The same discipline that built this — validate the real job, build only for the validated need, state only what you can show — is what we’d bring to you. The Sprint is how we figure out which system actually matters for your organization, before anyone spends a dollar building it.