Range Day Pro

Glossary

13 min read

Glossary

Terms used across the Range Day Pro documentation. Where a term has been used ambiguously or with multiple meanings, a clarification note is included.

Product Terms

Range Day The existing free app for Android and iOS. Users create drills, track scores, and plan informal range days. Built in FlutterFlow with a Supabase backend. Being replaced by the new stack.

Note: “range day” (lowercase) also refers to the general concept of going to the range. Context determines which meaning applies.

Range Day Pro (RDP) The paid SaaS product built on top of Range Day. Provides administrative tools for organized training, instruction, and competition.

Drill A specific shooting exercise with defined scoring requirements — times, points, penalties, pass/fail criteria, diagrams, and required range items (targets, weapons, round counts).

Drill Builder The tool within the dashboard for creating and editing drills. “3D Drill Builder” refers to a future feature using Bevy/WGPU for interactive 3D target/layout visualization.

Course A bundle of drills grouped together for a range day, class, or multi-day training event.

Event A scheduled training session, range day, class, or competition. An event has an owner, a roster, a set of drills or courses, and produces scores.

Note: Not to be confused with “event sourcing” (a software pattern explicitly not used in this system — see Data Architecture).

Roster The list of participants (shooters) in an event.

Score A recorded result for one shooter on one drill — includes time, points, penalties, pass/fail, and metadata. Defined as a protobuf Score message. Scores are append-only; corrections are new entries with a void flag on the original.

Void A flag on a score entry marking it as invalid. The original score is never modified — a new void entry is appended instead.

Shooter / Participant A person being scored. May be using the free app for personal tracking or enrolled in an organized event.

Placeholder User A User record created on-the-fly for a walk-on who shows up at an event without a Range Day account. Has a real user_id from the start — scores and roster entries reference it normally. The placeholder is upgraded to an active account when the person claims an email invite. See Data Model.

RO (Range Officer) A person physically on the firing line scoring shooters during a drill. May be the instructor themselves or a delegate. Each RO is assigned a specific partition of shooters.

Owner The person with authority over an event and its scores. The owner may delegate scoring to ROs but remains the single source of truth. In product terms only — not related to code ownership.

Org / Organization A group that uses Range Day Pro — a church security team, law enforcement department, training company, or military unit. Orgs have admins, instructors, and members.

White-Label A self-hosted deployment of Range Day Pro for organizations that need private, branded instances. Ships as Docker containers with runtime configuration (YAML config file + mounted asset directories). Same codebase as SaaS — no custom builds. May run on private networks with no public internet. Billing is disabled (enterprise contracts). See White-Label Deployment.

Drill Visibility An enum controlling who can see and use a drill. Three levels: Private (owner + rostered shooters only), Public (browsable in org catalog, can’t run), Published (browsable + copyable, shooter gets their own instance). See Multi-Tenant Model.

source_<entity>_id The FK naming pattern for optional references to a source/origin entity. Example: source_drill_id on a copied drill references the original. Always optional, always means “where this was derived from.”

Score Portability Scores embed drill metadata (name, type, scoring profile name, calculation method, zone breakdown) at creation time, making them self-contained. A shooter can always display their score regardless of the drill’s current visibility or existence. See Multi-Tenant Model.

Scoring Profile A reusable template defining how a drill is scored: what zones exist (e.g. Alpha/Charlie/Delta), how many points each zone is worth, and how the final result is calculated (hit factor, time plus penalties, etc.). Built-in profiles cover standard disciplines (USPSA, IDPA, IPSC, Steel Challenge). Orgs can create custom profiles. See Data Model.

Calculation Method How a scoring profile computes the final result. Five methods: hit_factor (points / time), time_plus (raw time + penalty seconds), points_only (no time component), time_only (fastest time wins), pass_fail (threshold-based).

Hit Factor The primary performance metric in USPSA-style scoring: total points divided by total time. Higher is better. Tracked across scores for leaderboards and personal history. One of five calculation methods available via scoring profiles.

Zone A scoring region on a target. Standard USPSA zones: Alpha (center, highest points), Charlie (mid), Delta (outer), Miss (no hit), No-Shoot (penalty for hitting a non-target). Different scoring profiles define different zones.

Architecture Terms

Monorepo The single repository containing all Range Day Pro code — libraries, applications, proto definitions, and documentation.

libs/ The monorepo folder for reusable libraries. Contains code that is never deployed on its own — only consumed by apps.

apps/ The monorepo folder for deployable applications. Everything in this folder is something that gets built and deployed — the server, dashboard, PWA, marketing site, iOS app, and Android app.

Note: The cli/ folder sits alongside libs/ and apps/ as a third category — developer tooling that is neither a library nor a deployed app.

Core / Core Crate (libs/core) The shared, public Rust crate containing client-safe business logic: data models, validation, scoring, sync protocol, offline queue management, and protobuf serialization. Ships to all consumers (server, dashboard, PWA, iOS, Android). Anything in this crate can be decompiled.

Note: “core” appears as a general adjective elsewhere (e.g., “Core Principle” in Data Architecture, “core sync payload”). When capitalized or referencing libs/core, it means the Rust crate. When lowercase in prose, it means “essential” or “central.”

Server / Server Crate (apps/server) The private Rust application. Contains both the Axum HTTP server and all server-only business logic — auth, billing, admin operations, database queries. Imports the core crate. This code never leaves the server.

Note: “Server” can refer to the application (apps/server), the physical/cloud machine it runs on, or the general concept of “the backend.” The docs generally use “server crate” when referring to the application specifically.

Dashboard (apps/dashboard) The admin-facing web application built with Dioxus. Used for event management, drill building, roster management, org settings, and score review. Imports the core crate only. Not the same as the PWA.

PWA (apps/pwa) Progressive Web App. The shooter-facing web application built with Dioxus. A read-heavy, light-interaction fallback for users who can’t or won’t install the native app. Deployed independently from the dashboard. Degraded at MVP; full-featured before scale.

Marketing Site (apps/marketing) Static HTML + Tailwind CSS landing page at the root domain. The public entry point — links users to the dashboard or app downloads. No framework, no JS runtime.

Client Any consumer of the core crate that is not the server: the dashboard, PWA, iOS app, or Android app. When the docs say “ships to clients” or “client-safe,” this is the meaning.

cli/ The monorepo folder for the rangeday CLI — developer tooling that wraps all build, test, serve, and setup operations. Not a library and not a deployed app.

rangeday CLI A Rust binary in cli/ that provides a single interface for all monorepo operations. Designed primarily for AI agents — an agent can discover any command via rangeday help-search <keywords>. See CLI for the full command reference.

Thin Client An app that relies on the server for business logic and only handles display. Our native apps are explicitly not thin clients — they run the core crate locally.

Data & Sync Terms

Single-Owner Write Model The principle that every score partition has exactly one authoritative writer at any time. Eliminates multi-writer sync conflicts by design. See Data Architecture.

Partition A group of shooters assigned to one RO during an event. Each partition has a single writer. The term comes from the physical range layout (relays/lanes) mapped to data ownership.

Relay / Lane Physical positions at a range. Shooters are assigned to relays or lanes, and each relay/lane group is typically scored by one RO. Used interchangeably in the docs to describe how partitions map to the physical range.

Append-Only Scores are never edited or deleted — only new entries are appended. Corrections use void entries. This makes sync a simple queue flush with no merge logic.

Read-Down Structural data (drill definitions, course structure, roster, event configuration) downloaded to devices before an event starts. Small payloads — a full event is typically under 50 KB. Locked and immutable once the event begins.

Write-Up Score data created on-device during an event and uploaded to the server. Individual score entries are 100-200 bytes.

Queue Flush The process of sending locally queued scores to the server. Scores accumulate in a local queue during poor/no connectivity and are flushed when a connection is available. No diffing or merging — just appending.

Sync / Sync Protocol The mechanism for exchanging data between devices and the server. Follows the read-down, write-up pattern. “Sync logic” and “sync protocol” refer to the implementation in the core crate. “Background sync” refers to OS-level capabilities (BGTaskScheduler on iOS, WorkManager on Android) that allow flushing the queue when the app is not in the foreground.

Deduplication Key A composite key (event_id + drill_id + shooter_id + timestamp) used to prevent duplicate score entries when a device swap occurs mid-event.

Auth Terms

Auth Module The isolated module in the server crate (apps/server/src/auth/) that handles registration, login, JWT issuance, password reset, and invite flows. The only code that touches passwords and tokens. Designed to be replaceable with an external identity provider. See Auth Architecture.

AuthContext The validated result of authentication: user_id, org_id, and role. Produced by the auth module, consumed by everything downstream. This is the interface boundary — if the auth module is swapped for Zitadel, AuthContext stays the same.

JWT (JSON Web Token) A short-lived, signed token that carries user identity. Validated without a database lookup. Used for both online API calls and offline mobile operations.

Refresh Token A long-lived token stored server-side, used to issue new JWTs when the access token expires. Can be revoked (e.g., when a user is removed from an org).

Zitadel A self-hostable, Go-based identity provider with built-in multi-tenancy, MFA, OIDC, and LDAP. Not used at MVP — evaluated as the future replacement for the in-house auth module when advanced features (MFA, federation, compliance) are needed. See Auth Architecture.

Billing Terms

Billing Module The isolated module in the server crate (apps/server/src/billing/) that handles payment provider integration and subscription state. Uses a trait-based BillingProvider interface — currently Authorize.net, with Stripe planned when revenue thresholds are met. Disabled in white-label deployments (all features unlocked). See Billing Architecture.

Authorize.net The current payment provider. Handles subscription payments (web-only) and event enrollment payments (in-app). Chosen because Stripe restricts firearms-industry businesses below certain revenue thresholds.

No Usage-Based Billing A design principle: shooters never lose access to their data. No storage limits, no per-seat charges, no metered access. Subscriptions are flat-rate.

Technology Terms

Rust The programming language used for all shared logic, the server, and the web apps (via WASM). The “shared language” of the system.

Crate A Rust package. Equivalent to a “library” or “module” in other languages. The monorepo contains multiple crates under libs/ and apps/.

Axum The Rust web framework used for the server. Handles HTTP routing, middleware, and API endpoints.

Dioxus The Rust web framework used for the dashboard and PWA. Compiles to WASM for the browser. Provides SSR, server functions, and fullstack integration with Axum.

WASM / WebAssembly A binary compilation target that runs in browsers. Rust code in the core crate and Dioxus apps compiles to WASM, enabling the same logic to run in the browser as on native platforms.

UniFFI (Universal Foreign Function Interface) A Mozilla project that generates typed Swift and Kotlin bindings from Rust code. How the iOS and Android apps consume the core crate. Changes to Rust code surface as compile errors in Swift and Kotlin.

Bindings The generated Swift and Kotlin interfaces produced by UniFFI. These are the typed APIs that native apps use to call Rust core functions.

Protobuf / Protocol Buffers Google’s binary serialization format. Used as the wire format for all data exchanged between clients and server. Defined in .proto files under proto/ in the monorepo. Protobuf handles serialization; UniFFI handles type generation.

Note: Protobuf is the wire format (how data is encoded for transmission). UniFFI is the type/binding system (how platforms call Rust code). These are separate concerns.

Wire Format The serialization format for data in transit between clients and server. In this system, that’s protobuf binary encoding.

ConnectRPC The RPC framework used for all client-server communication. Generates type-safe API clients from proto service definitions. Serves JSON, protobuf binary, and gRPC wire formats from the same endpoints — the client chooses via Content-Type. See API Design.

Buf A toolchain for protobuf linting and breaking change detection in CI. Flags removed fields, changed types, or reused field numbers before merge.

UUID v7 The ID format used for all entity primary keys. A time-sortable UUID where the first 48 bits are a millisecond Unix timestamp and the remainder is random. Stored as Postgres uuid type (16 bytes). Provides sequential insert performance and rough chronological ordering while remaining fully compatible with standard UUID tooling. On the wire (protobuf), UUIDs are encoded as bytes (16 bytes), not strings.

Postgres The relational database used on the server.

SwiftData Apple’s native persistence framework, used for local storage on iOS.

Room Android’s native persistence library (part of Jetpack), used for local storage on Android.

IndexedDB Browser-based storage API, used by the PWA for local data.

SwiftUI Apple’s declarative UI framework for iOS.

Jetpack Compose Android’s declarative UI framework (Kotlin).

Tailwind CSS A utility-first CSS framework. Used in the marketing site (via Tailwind CLI for build-time minification) and in Dioxus apps (via zero-config integration).

SSR (Server-Side Rendering) Rendering HTML on the server before sending it to the browser. Dioxus supports this via its fullstack integration with Axum.

WGPU A cross-platform graphics API abstraction (WebGPU on web, Metal on iOS, Vulkan on Android). Dioxus’s WGPU-native architecture enables future 3D features.

Bevy A Rust game engine. Future use for the 3D drill builder — compiles to web (WASM/WebGPU), iOS (Metal), and Android (Vulkan).

BGTaskScheduler Apple’s API for scheduling background tasks on iOS. Used for background sync — flushing the score queue when the app is not in the foreground.

WorkManager Android’s API for scheduling background tasks. The Android equivalent of BGTaskScheduler.

Subsecond Dioxus’s hot-patching engine. Enables sub-second Rust UI reload during development without full recompilation.

WASM-Split A Dioxus feature for router-based code splitting. Reduces initial WASM bundle size by loading route-specific code on demand.

Noted Ambiguities

These terms have appeared with multiple meanings or in potentially confusing contexts:

  1. “Core” — Refers to the libs/core Rust crate when used as a noun or with “crate.” Also used as a general adjective meaning “essential” (e.g., “Core Principle”). Watch for context.

  2. “Server” — Can mean the apps/server application, the physical machine, or the general backend concept. “Server crate” is unambiguous; bare “server” requires context.

  3. “Event” — A range day or training session in product context. “Event sourcing” appears once in Data Architecture as a pattern we explicitly do not use.

  4. “App” — Used broadly: the existing free Flutter app, the native iOS/Android apps, the Dioxus web apps (dashboard, PWA), or any deployable application in apps/.

  5. “Public / Private” — Refers to the crate security boundary (core = public, server = private). Not related to API access levels or OOP visibility modifiers.

Graph View

Backlinks