Heritage Docs

Appearance

0019 — Community Ride Share & Travel ​

Status: Accepted (2026-06-18 — owner accepted during ADR review)

Date: 2026-06-17

ADO work item: AB#3101

Deciders: Kristopher Turner (platform owner)

Context ​

Heritage Virginia is a geographically dispersed rural community in Nickelsville, VA. Members frequently need to coordinate shared travel for a wide range of real needs: weekly and midweek meetings, weddings (sometimes at a distance), airport pickups and drop-offs, doctor and medical appointments, and general errands in town. No dedicated coordination mechanism exists today; ride needs circulate informally through conversation or text chains, which leaves needs unmet and visibility limited.

The platform strategy lists Community Ride Share & Travel Coordination as a signature / future feature (Epic AB#3078, Feature AB#3101), intentionally deferred to Phase 7 — after the platform core, iOS, Sermons & Music, Calendar, Messaging, and Android ship. It is forward-looking. This ADR records architectural intent, scope boundaries, and safety constraints so that when implementation planning begins the foundational decisions are already in place.

The central tension is trust and physical safety. Carpooling is an in-person, member-to-member activity. Getting the safety framing wrong — opening the feature to non-members, adding financial flows, or treating it as a transportation dispatch product — would expose the community and the fellowship to liability and harm that is outside the scope or capacity of a small ministry platform to manage. Security audit S2 (trust & safety for in-person activity) applies directly.

This is a planning/architecture decision. It introduces no code and no schema beyond noting what will eventually be needed. Detailed data model, API design, and notification integration are deferred to the implementation ADR that will be written at the start of Phase 7.

Decision ​

We will implement Community Ride Share & Travel as a ride offer/request listing and matching feature available exclusively to minister-approved members of the closed Heritage Christian Fellowship community, framed explicitly as coordination only — not a transportation service, not a dispatch product, and with no payment processing. Trust and physical safety are the primary design constraints; closed, vetted membership is the primary mitigation, supplemented by report/block controls and a mandatory waiver acknowledgement. Detailed technical design is deferred to Phase 7.

What this feature is ​

  • Ride offers — a member with a vehicle posts a trip: destination, date/time, available seats, and an optional cost-share note (text only; no payment flow).
  • Ride requests — a member without transport posts a need: destination, date/time, party size.
  • Matching — the platform surfaces compatible offers and requests. Members connect directly (via the platform's existing Messaging feature) to confirm arrangements.
  • Status lifecycle — offers and requests move through a simple status set (open → matched → completed / cancelled).
  • Scope: meetings and member life needs. Travel to and from Heritage Virginia meetings (weekly, midweek, and special gatherings — not referred to as "services"), weddings and events at a distance, airport pickups and drop-offs, doctor and medical appointments, and general errands in town. Broad enough to serve any genuine member transportation need within the community; not a general-purpose public rideshare product.

What this feature is not ​

  • Not a transportation provider or common carrier.
  • Not a dispatch or scheduling system.
  • Not a payment processor. A member may include a free-text cost-share note ("splitting gas appreciated"), but no monetary transaction occurs on the platform.
  • Not open to the public or to prospective members pending minister approval.

Safety and liability constraints (locked at design level) ​

  1. Closed membership gate. Only minister-approved members (ADR 0007 approval workflow; ADR 0006 RBAC) may post offers, post requests, or view listings. Anonymous and unapproved accounts cannot reach this feature surface.
  2. Coordination only — explicit liability boundary. The platform's terms of service and the in-feature waiver acknowledgement state that Heritage Community Hub facilitates introduction only; it is not a party to any travel arrangement and accepts no liability for outcomes.
  3. Mandatory waiver acknowledgement. On first use (and after any material terms update) a member must acknowledge the coordination-only framing and community conduct expectations before posting or viewing listings.
  4. Report/block. Members can report a listing or user through the standard platform report/block mechanism (security audit S2). Reported items are queued for minister/admin review.
  5. No payments, no rating system, no public profiles. These would shift the product toward a commercial rideshare model and introduce PCI scope, FCRA-adjacent concerns, or reputational risk inappropriate for a ministry context.
  6. RBAC enforcement is server-side. The API checks membership status and role on every request (ADR 0006). No client-side gating is authoritative.
  7. Audit log. All listing create/update/delete and all report events are written to the platform audit log (ADR 0005) for minister visibility.

Implementation timing ​

Phase 7. No implementation work begins until Phases 1–6 are complete and the platform's trust & safety foundation (security audit S2) is fully in place. The implementation ADR (a revision of this document or a successor) will be written at Phase 7 planning and will cover the data model, API endpoints, notification integration, and UI surface in full.

Alternatives considered ​

OptionProsConsWhy not chosen
Offer/request listing + matching, members only, no payments (chosen)Safe, scoped, fits closed community; no commercial liability; reuses platform auth/RBAC/messagingMembers must still confirm arrangements directly; no guarantee of fulfilment— chosen
Integrate a commercial rideshare API (Uber, Lyft, Via)Professional dispatch; liability stays with providerBreaks closed-community guarantee; exposes member data to a third party; cost; commercial terms incompatible with a ministry; non-members could be driversRejected — contradicts closed-community model (ADR 0007) and cost constraint
Add fare payment processingAllows formal cost-sharingPCI scope; positions the fellowship as a commercial transportation intermediary; liability and regulatory exposure far exceed ministry capacityRejected — out of scope; coordination-only framing is the governing constraint
Open listings to prospective / non-approved membersEasier onboarding, broader poolRe-opens the S2 trust & physical safety risk; vetting is the primary mitigation; cannot be relaxedRejected — minister-approved closed membership is a locked platform constraint (ADR 0007)
Rating or reputation system for drivers/ridersBuilds trust signal over timeReputational harm; FCRA-adjacent concerns; wrong tone for a ministry community that relies on mutual trust and pastoral relationshipRejected — inappropriate for the community context; report/block is sufficient

Consequences ​

Positive ​

  • Members gain a structured, visible way to coordinate travel that today happens informally or not at all — a genuine quality-of-life improvement for a rural community.
  • The closed-membership gate means no new identity or vetting infrastructure is needed; the existing approval workflow (ADR 0007) carries the primary safety guarantee.
  • Coordination-only framing keeps the fellowship outside commercial transportation regulation and avoids PCI scope entirely.
  • The feature composes cleanly on the platform (ADR 0008): listings are data served through apps/api; clients consume via api-client; notifications use the shared transport; all authorization is server-side RBAC.
  • Deferring to Phase 7 means the trust & safety audit (S2) and the Messaging feature are complete before this feature ships — the two dependencies it most needs.

Negative / trade-offs ​

  • Coordination-only means the platform cannot guarantee a ride is actually fulfilled; outcomes depend on member follow-through. This is an explicit, accepted limitation.
  • No payment integration means informal cost-sharing is unstructured. Members who want to recover fuel costs do so outside the platform. This is intentional.
  • Phase 7 timing means the feature is multiple years away. Members with immediate needs continue to rely on existing informal channels until then.
  • Implementation will require a careful terms-of-service addition and legal review of the liability boundary language — effort not yet estimated.

Risks ​

  • Misuse of member contact or location data. Listings reveal that a member is not home at a given time. Mitigation: restrict listing detail visibility to approved members only; do not surface home addresses (destination should be event/church address or a general area); the report/block mechanism provides recourse.
  • Scope creep toward commercial rideshare. Requests to add payments, ratings, or non-member access will recur. Mitigation: this ADR and the implementation ADR hold the boundary; any deviation requires a superseding ADR reviewed by the platform owner.
  • Liability language inadequacy. A waiver acknowledgement reduces but does not eliminate legal exposure. Mitigation: legal review of the terms addition is a Phase 7 gate; the platform does not ship this feature without it.
  • Low adoption. A small community with informal trust may not adopt a formal listing system. Mitigation: lightweight UX; no mandatory use; informal coordination continues to exist alongside the feature. Adoption is evaluated post-launch.

References ​

Heritage Community Hub — Internal. Access restricted via Cloudflare Access + Entra ID.

Heritage Virginia · Owner: Kristopher Turner