CASE FILE No. 010
VANGUARD · STAR CITIZEN ORG · COMMUNITY ERP
The real job was an operating system.
THE ENGAGEMENT
WHO THEY ARE
An org that had quietly stopped fitting through its own website.
Vanguard is an eight-year-old Star Citizen organization with a full command structure — Wings, Units, Squadrons, Billets — its own books kept on top of the game’s economy, a training program, and a daily operational tempo.
When the website hit a crisis, we stepped in. The real job was an operating system for the org.
THE ORIGIN
This didn’t start with a pitch. It started with membership.
Wabbit’s founder has backed Star Citizen for thirteen years and has flown with Vanguard for three. When the org’s website hit a crisis, he stepped up with a hell of a deal: the rebuild would run on Tome, the platform already running Wabbit’s own business. Vanguard needed the rescue. We wanted the proof.
That order of operations matters: the validated insight came from being inside the org, not from a discovery questionnaire.
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 org’s own bookkeeping, 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
Not a community. A small business with a fleet and a chain of command.
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, an auditable ledger, an LMS, a documentation system, and an HR pipeline.
What it does not need is a better Discord bot.
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.
Could eight years of the org’s records survive the move? Members, ranks, units, wings, events, training: all of it lived in Wix, and none of it could be lost.
So the first thing we built was the migration. We imported two members, then the ranks, units and wings, and checked that every member still sat in the right place in the chain of command with nothing dropped. Only when the records came across intact did we build on top of them.
THE MIGRATION
Eight years of records, carried over intact.
Every member record came across from Wix: rank, unit, wing, service history, certifications. Logins couldn’t, so each member claims their own record when they come back. They prove the RSI handle is theirs, and their new login attaches to the history that was already waiting. Members who left in good standing are restored on the spot; anyone else goes to an officer first.
Carried over: 1,351 member records, 3,555 events, 10,592 certification awards, 2,491 promotions and 2,484 award presentations. 223 members have reclaimed theirs so far, and the rest are waiting for whoever comes back next.
Outside the game: moving an organization off its old tools without making anyone start over, and without losing the people who haven’t come back yet.
FROM THE FILE
One platform where five to ten tools used to be.
The records held. So we built the rest on the same foundation.
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 HONEST PREFACE
A list this long deserves your skepticism.
A list this long usually means scope creep, padded hours, or both. So every system below says what job it does for the org, and what that same job looks like outside a game.
None of it started from scratch: Vanguard runs on Tome, the platform Wabbit builds on, and the two have shaped each other ever since. How is below.
THE MECHANISM · PART 1
Running the org: structure, operations, training, and governance.
THE OPERATING SYSTEM
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.
THE ORDER OF BATTLE
The chain of command, live.
The org chart is rendered from the actual hierarchy, Wings down to billets — force disposition, command billets, and vacancies in one view. Unit and Wing commanders hold scoped permissions to manage their own sub-structures without global admin: delegated authority, enforced everywhere downstream.
Outside the game: an org chart with delegated admin, so a regional lead runs their region without holding the keys to everyone else’s.
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.
Outside the game: the HR record kept apart from the login, so offboarding someone cuts their access without erasing what they did.
A command center, not a calendar. Every operation for the week on one strip, colour-coded by what you’re committed to, what you’re commanding, and what is still open to join. Above it: your next commitment counting down, anything you owe, and your attendance rate. The hours a spreadsheet cost every officer every week come back here.
OPERATIONS DASHBOARD · MISSION PLANNING · BATTLEBOARD
The in-mission reference: comms plan, assignment, area of operations and a readiness check on one screen. For a field crew, it’s the job sheet and the site brief.
The same brief on a phone, for the person who can’t stop to open a laptop.
THE AFTER-ACTION REPORT
Every operation ends in the record.
When an operation ends, the after-action report takes over. It’s a system of record: timeline events captured live during the op, a drafting and amendment flow, clearance-based redaction on publish, and a permanent record at a stable address. The paperwork officers used to dread became the org’s institutional memory.
Outside the game: scheduling, staffing and field work, with every job closed out by a report that becomes the record.
Filing happens in the operation’s own debrief tab. The author selects a passage, grades who may read it, and can name roles that read through anyway.
The filed report, read by a member below those grades. The graded passages come through as REDACTED; the timeline the crew captured live stays.
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, and calibration audits that catch instructor drift. The training program lived in PDFs and tribal knowledge before this.
Practical exams run as tickets — a member requests one, an instructor claims it, schedules it, runs it at a live event, and grades it — with challenge-outs for testing past known material, attempt cooldowns, on-the-job sign-offs, and subject-matter-expert designations governing who may teach and examine what. Courses are authored in the platform’s own builder with version history and publish gating, not in an admin panel.
Outside the game: training and certification with prerequisites and a practical sign-off, which is the compliance-training problem every regulated team has.
A course in progress: outline, lesson, status and the next module queued. Onboarding and compliance training take the same shape.
A practical exam as a ticket: requested, claimed by an instructor, scheduled into a live session, then graded. A skills sign-off works the same way.
GOVERNANCE
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. What clears the bar lands here: promotions approved, queued for ceremony, and finalized in the record. The promotion board itself can run live inside an operation’s command view.
Outside the game: two-person approval for anything consequential, with an open list of what is pending and who is holding it.
THE CODEX
Doctrine with a review cycle, not a wiki nobody trusts.
Every governing document lives in a clearance-tiered registry with an assigned document ID, a version history, and a review cycle that flags doctrine gone stale. Amendments are proposed, reviewed, and folded in on approval; members acknowledge what they’ve read, and the record shows who has. The org’s rules stopped being a Google Doc somebody once wrote.
Outside the game: policy management with version history, review dates and read receipts. Attestation, not a shared drive.
THE MECHANISM · PART 2
The recruitment engine: built in, not bolted on.
THE RECRUITMENT ENGINE
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.
The public half of that funnel is Signal, the org’s own publication — briefs, fleet reports, operation recaps, and sector intel, published from the same platform by the same officers under the same identity.
Signal, the org’s own publication: briefings, recaps and reports, written in the same system that holds the work they describe. No separate newsletter tool to feed.
The same article on a phone, laid out for reading on the move.
THE PUBLIC SURFACE
The pitch lives where the org lives.
Wing pages and applicant-facing pathways are collections in the same platform, kept current by the officers who hold that authority — not a marketing site in another tab, drifting out of date. When the org restructures, the public surface follows, because it is the same system.
Outside the game: the careers page and the org chart are the same data, so neither one goes stale.
The public schedule. Open events show in full. Members-only operations show as classified cards with a date and time and nothing else, so a recruit sees an active org without seeing its plans.
Signed in, the same schedule opens up: every operation, filterable by type, with date, threat level and location on the card.
Vetting built in, not a Google Form — identity, demographics, and vetting steps with server-side RSI handle verification and bot defense, then a Candidate role that quarantines new applicants from member-only data until an officer inducts them. A threat-scoring engine flags risk factors before a human ever reviews.
APPLICATIONS · VETTING · INDUCTION
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.
Outside the game: meet people in the chat tool they already use. The same pattern serves Slack or Teams.
THE ACTIVATION PIPELINE
Catch the member before they ghost.
A five-state machine (New → Engaged → Converted / At Risk → Graduated) tracks the twelve-week induction window, 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.
Outside the game: recruiting, vetting and a new hire’s first twelve weeks in one funnel.
RECOGNITION
Awards designed, proposed, and presented — inside the system.
Ribbons and medals are drawn in an in-platform art editor, down to band widths, devices and finish, with a similarity check so a new design can’t shadow an existing one. Each one is proposed with the criteria that earn it and the ranks authorized to award it, reviewed, then presented to the member’s permanent record with a citation. Peer-to-peer kudos ride the same rails, down to a Discord slash command.
Outside the game: recognition that lands on the employee record instead of in a channel that scrolls away.
The certification registry: every certification the org issues, who holds it, who is in training, and the awards waiting on sign-off. The training record an auditor asks for, already kept.
An award presentation: the citation, who presented it and when, kept on the member’s record instead of scrolling away in a chat channel.
THE MECHANISM · PART 3
Why this is structurally hard to copy: the integration is the product.
THE ARCHITECTURE
We haven’t found another gaming org that runs on anything like this, and not because nobody thought of it: the surface is large, the data model has to stay coherent across forty-four distinct systems, and the security posture has to actually work, not just "we have logins." The figures below come from the codebase itself, re-measured in September 2026.
THE ARCHITECTURE (AUDIT-DERIVED)
- ~98 first-party collections sharing a single identity layer, serving 142 pages and ~190 API routes; 50+ reusable access-control policies (role-based + attribute-based hybrid), with role/permission constants centralized to prevent typo bugs across the surface.
- 29 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; GDPR tooling built in: 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; nine real-time surfaces over WebSockets — the kneeboard, battleboard, promotion board, exam queues, and triage inbox among them — and a two-service architecture with Redis pub/sub feeding a dedicated Discord sidecar so the main app stays non-blocking.
- 35 background jobs on 34 cron triggers and 27 numbered architecture decision records, running on 8 Tome platform layers, several of them extracted from this build.
THE SECURITY POSTURE
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. Nobody quietly rewrites the record either: access logs can’t be edited or deleted by anyone, and audit entries can’t be edited at all.
A unit leader sees their unit, not the one beside it. A course opens only when its prerequisites are met. Money moves only through logged, auditable transactions. Nothing about the structure is decorative; the permission model is the org chart, enforced.
Outside the game: need-to-know enforced by the server, field by field, so the same record reads differently to different roles.
THE INTEL DESK
Classified means classified — even here.
A location registry with per-section classification and compartmented access grants; member-filed intel reports that pass review and expire; threat assessments on every applicant; reference data versioned against the game’s own patches, so stale intel is marked instead of trusted. The same clearance system that redacts a member record redacts a map.
Outside the game: sensitive client or site information that only the people cleared for it can open.
Operation Black Ice as its crew sees it: the full briefing, objectives, location intel and op code.
The same page for a member below the clearance line: briefing withheld, op code blanked, location classified, and a notice listing what they can’t see. The server removes it before the page is sent, so there is nothing hidden in the browser to find.
THE AUDIT TRAIL
Every administrative action, permanently inspectable.
High-stakes decisions carry the signatures that approved them, the timestamp, and the deadline they were held to. Every administrative action and every sensitive access is logged; no one can edit a log entry, and only a super-admin can remove an audit record. Members see it too: a Decision Register lists every open proposal, its age, and who it is waiting on, so the org can audit its own leadership, not just its members.
Outside the game: audit readiness as a by-product of running the organization, not a scramble before the auditor arrives.
ALSO ON THE MANIFEST
Systems that don’t get a figure still get a line — because the org uses them every day.
THE REST OF THE SYSTEM
- A public Memoriam — the org’s fallen, remembered on the record, with anniversary posts the platform sends itself.
- A unified triage inbox — every decision owed, bucketed by deadline, resolved in place.
- An internal ledger for the org’s own books, kept on top of the game’s economy: member, unit and wing wallets, with every transfer logged.
- A media vault — every upload normalized to WebP, content-hash deduplicated, near-duplicates caught by perceptual hash, private media in its own guarded store.
- Clearance-aware global search — results filtered by what the searcher may see, not by what exists.
- Passkey sign-in alongside password and OAuth — and a veteran door that recognizes a returning member’s handle.
- A GDPR desk — versioned consent, data export, scheduled retention, and an erasure path that works even for a banned member who can no longer log in.
- A ship catalogue and per-member hangars, feeding fleet readiness on the operations board.
- Calendar feeds — every op exportable to the calendar members already use.
- Org-health snapshots — participation, attendance, retention, and training completion, graphed over time.
- An in-app style guide — the design system documented on a live page, and enforced by lint.
THE FEEDBACK LOOP
Still in production, still listening.
Vanguard is a merciless proving ground: its members say what’s broken, loudly and fast. So the bug queue lives inside the platform: any member files a report, staff triage it by severity, and every fix ships back to the same people who reported it. The feedback loop is a feature of the system, not a support inbox.
- 196
after-action reports filed
- 240
events run on the platform
- 1,014
certifications awarded on the platform
Counted from the production database: activity on the platform only. History carried over from the old site is counted in The Migration.
WHAT THIS IS PROOF OF
The structure held under a real organization.
The org runs its week on this system, and leadership keeps asking what else to move onto it rather than away from it. We aren’t claiming it grew the membership or kept people around. The numbers above are what the system holds, nothing more.
What this is proof of is the architecture question: can a team like ours design, build, 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 forty-four systems is the unique product.
Tome ran Wabbit’s own business before this build, and Vanguard became its capstone: the project meant to prove the platform end to end, under a large and very active organization using it every day. Concurrent logins, live operations, real-time boards, training in progress. The systems that held under that load went back into Tome as layers any client can start from: the org structure, the exam and certification workflow, the approval engine behind every multi-signature decision, the ledger. That is the part that matters to you. Your build starts from what Vanguard proved, not from zero.
IF YOU’RE NOT A GAMING ORG
Swap the ships for trucks and almost nothing changes.
Take the Star Citizen vocabulary out and what’s left is the operating problem of any organization where people, permissions, training and records have to agree: a membership association, a volunteer corps, a franchise network, a field-service company, a training academy.
The wings become regions, the ships become vehicles, the certifications become licences. The system underneath doesn’t change, and because it runs on Tome, neither does the head start.
MORE FROM THE FIELD
See the rest of the work.
CASE FILE
100% migrated
Re-platform · email-marketing education
Modern Marketing System
Read the case file →
CASE FILE
Trust lane
Snap-on franchise web platform
ProCut
Read the case file →
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.