Enterprise transport capability research

Purpose and evidence boundary

This Phase 1 report turns official transport, ticketing, mobile-platform, accessibility, security, and vendor documentation into a product and architecture baseline for ShamBus. It supplements, but does not replace, the owner-supplied FlixBus inventory in Enterprise feature traceability.

The numbered FlixBus inventory is a product requirement and comparison input, not independent evidence about FlixBus. Where this report describes a current Flix capability, it links directly to a Flix-owned source. Where it proposes a ShamBus design, it labels the statement as a recommendation.

There is no finite, objectively complete list of every transport-platform feature on the internet. “Full coverage” must therefore mean:

1. every accepted capability has an owner and canonical domain contract;
2. every material state and exceptional case has an explicit outcome;
3. every user surface is a projection of the same operational records;
4. every release claim is backed by tests and production evidence;
5. new requirements enter the traceability ledger instead of becoming undocumented exceptions.

Evidence labels

Label	Meaning
Official fact	Directly supported by a linked primary or official source.
Benchmark	A practice from another jurisdiction or mode that may inform ShamBus but is not automatically applicable in Syria.
Recommendation	A proposed ShamBus architecture or product requirement derived from the evidence.
Counsel required	A Syrian legal, tax, licensing, consumer, employment, accessibility, retention, or fiscal decision that engineering must not invent.

Priority labels

Priority	Meaning
P0	Required before an honestly production-ready connected booking and operating flow.
P1	Required for enterprise reliability, scale, and operational efficiency after the P0 transaction boundary is stable.
P2	Differentiating or advanced capability that should reuse the P0/P1 domain model.

Executive conclusion

The largest gap beyond the supplied FlixBus inventory is not another page. It is a single, atomic operational contract for:

Stop-to-stop offer
  → authoritative quote
  → inventory allocation
  → booking
  → payment collection
  → fulfillment/ticket
  → receipt or invoice
  → check-in/control
  → trip execution
  → reconciliation, quality, and settlement

Official OSDM documentation separates offers, bookings, confirmation, fulfillment, control numbers, ticket documents, after-sales actions, and document types; it also allows confirmation without immediate fulfillment. That is strong evidence for keeping a reservation record, a right-to-travel credential, and a financial document distinct rather than treating one PDF or QR as all three. See OSDM requirements, OSDM processes, and the OSDM fulfillment document code list.

For ShamBus, the same contract must work through customer web, customer mobile, a dashboard office sale, a reseller, or a driver-created walk-up/onboard sale. The sales channel changes permissions and interaction design; it must not create a second booking, fare, inventory, QR, or settlement truth.

What official sources establish

Connected platform and operating roles

Flix describes a platform centered on commercial management, network planning, pricing, marketing and sales, quality, customer service, and traffic control, with a partner model that connects operator supply to customer demand and includes revenue sharing. Its current official report also describes online/app/shop booking, seat reservations, bulky luggage, rebooking, automated delay management, and live journey tracking. These are current Flix claims, not proof that ShamBus implements them. See the Flix 2025 ESG report and Flix Tech.

Flix's operator documentation demonstrates a connected operational projection: partners can inspect bookings, contact affected passengers, understand connections, follow cancellation/rebooking history, check passengers in by name or QR, and open station coordinates in Google Maps. It also makes check-in read-only after the driver closes a station or 24 hours after final arrival. See the official Flix partner operations documentation.

Recommendation: ShamBus should preserve its canonical graph:

Journey → Journey Leg → Trip → Stop Calls → Inventory → Quote
        → Booking → Passenger → Fulfillment/Ticket → Control Event
        → Telemetry/Disruption → Completion → Feedback/Quality
        → Cash Reconciliation/Settlement

Platform, company, driver, traveler, support, finance, and reseller applications should issue commands against, and receive role-scoped projections from, these records. They must not maintain independent status enums or shadow copies.

Stops, pickup points, and trip-specific changes

GTFS Schedule distinguishes a physical stop from a trip's ordered stop times and supports pickup/drop-off rules, coordinates, booking rules, and location groupings. GTFS Schedule reference.

GTFS Realtime can scope an alert to a specific trip, route, and stop, and defines effects including STOP_MOVED, detour, no service, modified service, delay, and accessibility issue. GTFS Realtime Service Alerts.

GTFS Realtime Trip Modifications can represent replacement stops and modified stop sequences, but the feature is marked experimental. ShamBus should not make an experimental external feed its internal source of truth. It should own a stable Stop Call override model and export standards-compatible data later. GTFS Trip Modifications and GTFS Realtime reference.

Google Maps URLs can open a cross-platform pin, map, or directions experience using a name, coordinates, or Place ID. Google Maps URL documentation. Plus Codes encode a location for places without conventional street addresses and can work offline; Google's open-source implementation describes use where streets are unnamed or buildings unnumbered. Official Plus Codes site and Google Open Location Code.

Recommendation: Model a reusable stop separately from a dated trip_stop_call. Every Stop Call may override the base stop's customer-facing pickup/drop-off data for that trip without mutating other trips.

Minimum trip-specific location fields:

• stop_id, stop_call_id, and ordered sequence;
• latitude, longitude, map provider reference, and optional full Plus Code;
• Arabic and English display name;
• plain-language landmark and meeting instructions;
• boarding side, entrance, gate/vehicle rendezvous description, and optional photo;
• accessibility notes and assistance contact;
• pickup/drop-off permission and scheduled time;
• geofence/radius for operations, but never as the only customer instruction;
• source (base_stop, schedule_override, live_override);
• version, effective interval, reason, actor, approval, and audit timestamp.

For every move or material instruction change, the system should preserve old and new values, target the exact affected Trip/Stop Calls, notify affected passengers and assigned crew, expose a map/directions action, record delivery and acknowledgment per channel, and surface unacknowledged high-risk changes to control staff. This recommendation follows the granular targeting and STOP_MOVED model in GTFS Service Alerts.

Onboard and in-person sales

Flix officially advertises onboard ticket purchase in supported markets, as well as official reseller and shop purchase. Flix ticket sales points. Its reseller program describes a dedicated login, in-person connection selection, printed or electronic ticket delivery, and integrated payments and commissions; it also says a reseller needs internet and a printer. Flix travel agencies and reseller partners.

The UK Department for Transport's official bus data guide distinguishes advance-purchase and onboard-only products. It models fare variation by route, duration, passenger type/count, payment method, discounts, and caps, and notes that fare data commonly resides in electronic ticket machines. This is an England-specific data benchmark, not Syrian law. DfT Bus Open Data implementation guide.

Recommendation: A driver-created walk-up/onboard booking should be a first-class channel over the central Journey transaction, not a free-text passenger row added to a manifest.

Required driver sale flow

1. Driver authenticates to an assigned shift, vehicle, and active Trip.
2. Driver selects one or more passengers.
3. Every passenger receives an explicit boarding Stop Call and alighting Stop Call; board.sequence < alight.sequence is mandatory.
4. Driver selects passenger category, required assistance declarations, seat/resource products, and contact details only when operationally necessary.
5. The server prices a versioned fare product for the exact stop pair, passenger composition, sales channel, currency, and payment method.
6. If the company permits a manual amount, the driver enters it as a controlled fare override with permission, reason, expected amount, variance, and supervisor rule. The override must not replace the fare catalogue.
7. Central inventory allocates seats and extras atomically. If the device is offline, only a bounded pre-authorized inventory lease may issue a guaranteed ticket.
8. Cash is the default ShamBus payment method. The driver records tendered amount, change, currency, collector, shift, and device; online adapters remain disabled/development-only until approved.
9. A booking and payment record are created idempotently.
10. The booking is confirmed or left pending according to company policy.
11. A fulfillment/ticket is issued only when the right to travel exists.
12. The driver displays, prints, or securely shares the ticket and separately produces the payment receipt when required.
13. The manifest, capacity, cash drawer, company dashboard, support view, audit log, and settlement projection update from the same transaction.

OSDM supports bookings containing admissions, reservations, and ancillaries and treats fulfillment as a stateful resource with a unique control number and ticket documents. It also supports confirmation without fulfillment, where no document or control number is issued yet. OSDM requirements and OSDM confirmation/fulfillment processes.

Company-approval edge: if a company requires manual confirmation, a reservation request must be visibly PENDING_CONFIRMATION and cannot masquerade as a valid boarding ticket. For a passenger already standing at the bus, the company must either authorize the assigned driver to confirm that sale, provide a real-time approval path, or disable onboard sales for that policy. A pending request with a ticket-looking QR is unsafe and misleading.

Fare authority and operator-entered amounts

Recommendation: company users control fare catalogues and permitted overrides; drivers select valid products. An unconstrained “enter total price” field is not enterprise fare management.

The minimum price snapshot should contain:

• fare product and immutable fare-version IDs;
• operating company, Trip, boarding and alighting Stop Calls;
• passenger category and quantity;
• seat and ancillary lines;
• list amount, adjustments, discounts, taxes/fees when legally applicable, and final amount;
• currency and rounding rule;
• sales channel and payment method;
• override actor, permission, reason, and approver;
• issued-at and expires-at times;
• idempotency key and server signature/hash.

The DfT benchmark explicitly represents onboard availability, passenger types, route/duration, payment-method variation, and complex fare rules, while OSDM models priced offers, product conditions, reservations, ancillaries, and refunds. DfT guide and OSDM requirements.

Fulfillment, QR, ticket control, and document semantics

UIC's official Flexible Content Barcode material distinguishes Security in Data (authenticity in signed ticket data), Security in System (a server-side reference), and hybrid use. It supports static paper/screen barcodes and dynamic on-screen barcodes. UIC Flexible Content Barcode and UIC Passenger Experts.

UIC's public-key service explains that tickets are digitally signed with private/public key pairs and that public keys are distributed to control organizations. UIC Public Key Management Website. Its electronic Ticket Control Database exchanges real-time ticket verification, use, cancellation, refund, validity, and repeated-use information between issuers and carriers. UIC eTCD.

Google Wallet supports visual, static QR, and rotating barcode transit passes; Apple Wallet supports signed, distributable, and updateable passes. Google Wallet transit passes and Apple Wallet Passes.

Recommendation: ShamBus should use hybrid control:

• a signed, PII-minimized credential for offline authenticity;
• an online ticket-control record for current state, revocation, prior use, and after-sales changes;
• versioned signing keys with a pre-synchronized public verification keyset;
• a revocation/control snapshot with a visible freshness timestamp for offline scanners;
• a unique control event for every accepted, rejected, duplicate, manual, or overridden scan;
• dynamic on-screen QR as a later anti-copy option, while retaining valid static printable credentials for passengers without compatible phones.

The QR is a credential, not the booking record. It should identify a single Passenger, Journey Leg, and fulfillment/control number. Booking references, family names, phone numbers, and full passenger details should not be encoded when an opaque identifier is sufficient.

Distinct document types

OSDM explicitly distinguishes a ticket, boarding pass, booking receipt, voucher, and information document. OSDM fulfillment document types. ShamBus should therefore never label one artifact ambiguously as “invoice/reservation/ticket.”

Recommended document inventory:

Artifact	Meaning	May contain boarding QR?
Booking acknowledgment	Request received; may still await company confirmation.	No
Booking confirmation	Commercial reservation is confirmed.	Only if fulfillment is issued at the same time
Boarding ticket	Current right to travel for a Passenger and Journey Leg.	Yes
Payment receipt	Evidence of money collected and method/tender/change.	Optional reference, not the boarding authority
Tax invoice	Fiscal document only when legally applicable and based on validated billing details.	No
Refund/void receipt	Financial reversal and linked original transaction.	No
Reissue/exchange document	Links old and new fulfillment and states which credential is valid.	New ticket only
Driver manifest	Role-scoped operational document, not customer proof.	Control references only
Settlement statement	Company/platform reconciliation.	No

Professional billing details should remain optional unless the payment method or applicable legal/fiscal rule requires them. Whether a Syrian cash receipt or tax invoice requires specific numbering, wording, retention, or device certification is counsel required.

Printing and printer reliability

Official Epson documentation exposes web/native printer control and spooler behavior, including job IDs and print-result/error states. Epson ePOS SDK reference. This proves that printer adapters and status-aware spooling are feasible; it is not a ShamBus vendor endorsement.

Recommendation: introduce a printer adapter boundary rather than embedding a specific vendor SDK into booking logic.

Document service
  → immutable rendered artifact + hash
  → print job (idempotency key)
  → printer adapter
  → pending / accepted / printed / failed / unknown
  → retry, reprint, or fallback delivery

Record printer/device ID, document ID/hash, requested-by, sale ID, attempt number, adapter job ID, last status, timestamps, and reprint reason. If the printer produced paper but the acknowledgment was lost, retrying must reprint the same document, not create another booking or payment. Reprints require an audit event and should be visibly marked as copies when counsel or company policy requires it.

Fallback order:

1. show the signed QR and concise ticket on the customer's device;
2. share the existing PDF/Wallet artifact;
3. send a protected retrieval link through an enabled notification channel;
4. record “document delivery pending” for later retry;
5. never convert printer failure into booking failure after the sale committed.

Secure phone-to-phone delivery and sharing

Google Nearby Connections supports direct data exchange between Android and iOS devices without internet. Google warns that unverified connections are insecure and recommends mutual comparison of a verification code. Nearby overview and Nearby connection verification.

Google's Nearby guidelines call for explicit user initiation and advise against broadcasting sensitive values, recommending authorization tokens or transaction identifiers instead. Nearby developer guidelines. Android's official secure file-sharing guidance uses content URIs and temporary, receiver-scoped permissions rather than broad file access. Android secure file sharing.

Recommendation: support two different concepts and name them correctly:

• Share a copy: sends an already issued PDF, Wallet pass, or protected link. The original credential remains valid.
• Transfer ownership: an authenticated after-sales command that revokes/reissues or relinks a ticket under policy. A screenshot or copied PDF is not a transfer.

For direct nearby delivery:

1. both users explicitly start the flow;
2. both devices show and confirm the same verification code;
3. send only a signed ticket artifact or one-time claim envelope, not the entire booking/passenger record;
4. show recipient identity/device context before final confirmation;
5. audit sender, recipient/endpoint pseudonym, artifact, time, result, and whether it was copy or transfer;
6. expire discovery promptly and do not advertise passenger data;
7. provide QR-on-screen and platform share-sheet fallbacks.

Public ticket URLs must not reveal a booking from a predictable identifier alone. Guest management should require booking code plus family name, while authenticated travelers see owned bookings. A PDF can be intentionally shared as a bearer copy, but the underlying manage-booking, refund, passenger-data, or ticket-reissue endpoints remain authenticated or protected by the booking lookup proof.

Offline operations and conflict control

Android's official offline-first guidance recommends a local data source for core reads, queued/persistent work, explicit synchronization, versioning, and conflict resolution. It also warns that offline writes are more complex than reads. Android offline-first architecture.

Recommendation: driver offline mode must pre-synchronize a bounded operational package, not cache arbitrary API responses.

Pre-trip package:

• assigned Trip, vehicle, crew, Stop Calls, pickup overrides, and schedule version;
• passenger manifest with least-privilege operational fields;
• ticket-control numbers, signed credential data, and current control/revocation snapshot;
• public verification keyset and key validity windows;
• fare catalogue versions permitted for onboard sale;
• seat/resource inventory lease and its hard limit;
• company policies, driver permissions, and approval rules;
• document templates and printer configuration;
• server time anchor and package freshness/expiry.

Offline command envelope:

command_id
device_id
driver_id / shift_id
trip_id / stop_call_id
sequence_number
idempotency_key
local_monotonic_time
anchored_utc_estimate
payload_version
payload_hash
previous_command_hash (optional tamper-evident chain)
sync_state / conflict_state

Offline reads may remain available from a stale package with a visible freshness warning. Offline writes must be classified:

Class	Offline rule
Check-in against preloaded valid ticket	Allow and queue control event; detect duplicate locally.
Incident/checklist/telemetry	Allow and queue.
Cash sale with leased capacity and valid fare/key package	Allow within the device's explicit lease.
Cash sale without capacity authority	Create a provisional/waitlist record only; do not guarantee a seat or issue a valid ticket.
Refund, high-value override, account ownership transfer	Online-only unless a separately approved risk policy exists.
Pickup move or trip cancellation	Online control command; cached clients consume the signed/versioned change.

An inventory lease should be scoped to Trip, segment/Stop Calls, resource/seat set, device, shift, and expiry. Two offline devices must never receive overlapping guaranteed inventory. On synchronization, central reconciliation consumes the lease, preserves idempotent replays, rejects out-of-lease sales into an exception queue, and never silently chooses “last write wins” for money or seat rights.

Time, ordering, and stale-state safety

Android documents that wall-clock time can move backward or forward and recommends monotonic elapsed time for intervals. Android SystemClock. Network Time Security is an IETF standards-track mechanism for authenticating NTP synchronization. RFC 8915.

Recommendation: use server-assigned event time as authority after sync, monotonic device time for local ordering/durations, and a signed/authenticated server time anchor for offline validity estimates. Never accept a refund cutoff, ticket validity, fare expiry, or key expiry solely because a driver's editable wall clock says it is valid.

Audit, cash, fiscal, and settlement controls

NIST SP 800-53 includes an Audit and Accountability control family and calls for organization-defined audit-record retention consistent with records policy and investigation/operational needs. NIST SP 800-53 Revision 5. NIST is a security-control benchmark, not Syrian tax law.

Recommendation: use an append-only business event ledger for every money, entitlement, and control transition, separate from mutable application logs.

Required auditable events include:

• fare catalogue publish/retire and fare override;
• inventory lease grant/consume/expire/conflict;
• booking create/confirm/reject/expire/cancel/rebook;
• cash tender/change/collection/void/refund;
• ticket issue/revoke/reissue/share/transfer;
• QR accepted/rejected/duplicate/manual override;
• printer job/retry/reprint/fallback;
• pickup/Stop Call change, notification, and acknowledgment;
• driver shift open/close, float, declared cash, expected cash, variance, and supervisor resolution;
• offline package issue and command synchronization;
• settlement include/exclude/adjust/pay and post-settlement correction;
• legal-document publish and acceptance/withdrawal.

Cash closeout should reconcile, per driver/shift/device/currency:

opening float
+ cash sales
- cash refunds
- recorded change impact (according to accounting policy)
= expected drawer
vs declared drawer
= variance

Company finance should see the source sale, Trip, passengers/segments, collector, receipt, cash shift, variance, refunds, and settlement treatment without joining spreadsheets manually. Platform staff should see cross-company risk and settlement projections without permission to rewrite company cash history.

Receipt/invoice numbering, tax fields, retention, allowed voids, currency rules, and whether any fiscal device is required in Syria are counsel and accounting review required. Engineering should implement configurable sequences and immutable correction links only after that review.

Card payments are not a production ShamBus method in this phase. If card adapters are enabled later, PCI DSS applies to entities that store, process, transmit, or can affect the security of cardholder data. PCI DSS. The safest adapter boundary minimizes ShamBus card-data scope and never stores sensitive authentication data; actual provider and compliance design require a separate review.

Cross-surface capability inventory

The following is the recommended official-source baseline. “Must” means P0/P1 enterprise coverage, not that the capability is already implemented.

Traveler web and mobile

Priority	Capability	Required connected behavior	Evidence basis
P0	Search before authentication	Preserve search and checkout state through authentication; guest and account use the same Journey.	Flix describes app/web booking; OSDM separates offer and booking: Flix ESG, OSDM processes.
P0	City → stop hierarchy	Search cities and concrete pickup points, not city strings only.	GTFS Schedule.
P0	Exact trip pickup	Show pin, landmark, instructions, directions, Plus Code, scheduled time, and change state.	Google Maps URLs, Plus Codes, GTFS alerts.
P0	Comparable journeys	Times, duration, leg/transfer, operator, stop, price, capacity, conditions, and accessibility.	OSDM requirements, Flix ESG.
P0	Passenger-specific booking	Multiple passengers, categories, Stop Calls, seats, extras, assistance, and contact owner.	OSDM requirements.
P0	Company-approval clarity	Pending request is visually and semantically different from confirmed booking and issued ticket.	OSDM confirmation without fulfillment.
P0	Secure ticket	Signed QR, current status, offline copy, print/share fallback, and booking confirmation QR when issued.	UIC FCB, UIC eTCD.
P0	Secure booking lookup	Account-owned bookings or booking code + family name; no predictable public ticket URL.	ShamBus security recommendation; OSDM supports booking/control reference search: OSDM requirements.
P0	Disruption continuity	Pickup move, delay, cancellation, rebooking options, map update, and acknowledgment.	GTFS Service Alerts, Flix Tech.
P0	Offline travel day	Ticket, itinerary, pickup instructions, support path, and latest status remain readable offline.	Android offline-first.
P0	Same feature contract on web/mobile	Same domain outcomes, terminology, policies, and data; interaction pattern may differ.	ShamBus architecture recommendation.
P1	Wallet fulfillment	Apple/Google Wallet with updates and revocation-aware in-app status.	Apple Wallet, Google Wallet transit passes.
P1	Self-service after-sales	Change/cancel/refund/reissue/contact/seat/extras actions with policy quote and history.	OSDM after-sales, Flix manage booking.
P1	Accessibility journey	Search/booking filters, assistance request, accessible stop/vehicle detail, alternate information formats.	GTFS accessibility, WCAG 2.2, UN CRPD Article 9.
P1	Location/time-aware home	Upcoming, travel-day, boarding, in-trip, arrival, and post-trip home states.	Flix reports live tracking and automated delay management: Flix ESG.
P1	Structured support	Claims, refund, lost item, accessibility, disruption, baggage, and booking case types linked to the Journey.	Flix Help Center, EU road rights benchmark.
P1	Post-trip feedback	Dimensions for trip, driver, vehicle, cleanliness, comfort, stop, and support feed quality cases.	Flix describes post-travel feedback and quality across the journey: Flix sustainability report.
P2	Secure nearby share	Verified, explicit, minimal-data phone-to-phone ticket delivery.	Nearby Connections, Nearby verification.
P2	Multimodal offers	Through Journey with leg ownership, transfer protection, and separate fulfillment/conditions.	OSDM, TOMP API.

Driver app

Priority	Capability	Required connected behavior	Evidence basis
P0	Individual authentication and assignment	Driver, shift, Trip, vehicle, role, and device are attributable; demo policy may relax 2FA without sharing accounts.	Audit recommendation informed by NIST SP 800-53.
P0	Stop-aware manifest	Board/alight counts and Passenger states at every Stop Call, not one flat list.	GTFS Schedule stop times, Flix Booking Reports.
P0	QR and manual control	Valid, duplicate, revoked, wrong Trip/leg/stop/date, offline-stale, and manual outcomes.	UIC eTCD, Flix QR check-in.
P0	Walk-up/onboard sale	Per-passenger board/alight, category, seat/extras, controlled fare, cash, booking, ticket, receipt.	Flix onboard sale, DfT fare model.
P0	Cash shift	Float, sale/refund, tender/change, expected/declared cash, variance, supervisor resolution.	ShamBus audit/reconciliation recommendation.
P0	Offline core	Manifest, ticket verification, bounded sales lease, command queue, conflicts, and freshness.	Android offline-first, UIC hybrid ticket security.
P0	Pickup instructions	Exact pin, landmark, approach note, move alert, acknowledgment, map launch.	Google Maps URLs, GTFS Stop Moved.
P0	Trip lifecycle	Pre-trip inspection, boarding open/closed, depart, stop arrival/departure, delay, complete, exception.	Flix operator docs demonstrate station close/control; realtime standards expose arrival, vehicle and disruption state: Flix operations, GTFS Realtime.
P0	Receipt/ticket delivery	Display, print, secure share, fallback, printer state, reprint audit.	Epson ePOS reference, OSDM documents.
P1	Incident and defect reporting	Category, severity, Stop Call/GPS, timestamp, notes, media, passenger impact, control response.	GTFS alerts provide operational cause/effect taxonomy: GTFS Service Alerts.
P1	Live telemetry and ETA	Location, next stop, schedule deviation, GPS freshness, delay reason, offline state.	GTFS Realtime, Flix Tech.
P1	Crew communication	Priority control messages, acknowledgement, break/detour/stop announcements, immutable timeline.	Connected operations recommendation supported by Flix's traffic-control model: Flix ESG.
P1	Device health	App version, sync age, battery, connectivity, storage, camera/GPS/printer permissions, keyset age.	Offline and operational recommendation.
P2	Verified phone delivery	Explicit verified nearby handoff where internet/SMS is unavailable.	Nearby verification.

Company/operator portal

Priority	Capability	Required connected behavior	Evidence basis
P0	Live exception control	Missing driver/vehicle, pickup move, late start, GPS offline, capacity conflict, incident, approval queue.	Flix describes traffic control, live tracking, and delay management: Flix ESG.
P0	Stop and trip pickup editor	Base stop plus versioned Trip override, map pin, landmark, change propagation, approval.	GTFS Schedule, GTFS Service Alerts.
P0	Fare catalogue	Stop-pair/channel/passenger/payment products, effective dates, versioning, publish workflow.	DfT fare model, OSDM products.
P0	Driver sale policy	Roles, maximum override, offline allowance, inventory lease, confirmation authority, refund/reprint limits.	ShamBus control recommendation.
P0	Booking approval	Rich context, SLA, conflicts, payment state, passenger impact, approve/reject reason, notification.	OSDM confirmation/fulfillment.
P0	Connected booking detail	Journey, legs, Trip, Stop Calls, vehicle, driver, passengers, seats/extras, payment, ticket, documents, notifications, audit, support.	Canonical ShamBus recommendation; Flix Booking Reports demonstrate operational cross-context: Flix operations.
P0	Onboard-sales ledger	Sale/receipt/ticket/driver/shift/Trip/Stop Calls/cash/reconciliation in one drilldown.	ShamBus finance recommendation.
P1	Printer/device fleet	Assignment, compatibility, health, paper, last success, queued jobs, reprint anomalies.	Epson ePOS.
P1	Fleet/crew planning	Conflict-free vehicle/driver assignment, capacity and accessibility compatibility, replacements, audit.	Flix partner/platform role model: Flix ESG.
P1	Quality and feedback	Punctuality, check-in, no-show, cancellation, complaints, vehicle/driver/stop dimensions, corrective actions.	Flix sustainability report.
P1	Finance and settlement	Cash variance, trip revenue, adjustments, refunds, documents, payout/settlement eligibility.	Flix describes revenue sharing: Flix ESG.
P1	Company legal/policies	Company-controlled carriage, cancellation, baggage, support and public-profile content with platform oversight.	Flix operator policy configuration.
P2	Data exports/API	GTFS/GTFS-RT, fare, booking/control, finance, audit, and BI exports with stable IDs.	GTFS, OSDM, Flix affiliate integration.

Platform admin, network control, and support

Priority	Capability	Required connected behavior	Evidence basis
P0	Tenant and role isolation	Every read/command is company/role scoped; platform oversight is audited.	ShamBus security requirement informed by NIST SP 800-53.
P0	Network source of truth	Cities, stops, routes, Trips, Stop Calls, operating company, restrictions, and versions.	GTFS Schedule.
P0	Central inventory authority	Web/mobile/office/driver/reseller consume the same seats and ancillary capacity.	OSDM models reservations/ancillaries and fulfillment against booking parts: OSDM requirements.
P0	Ticket issuer/control authority	Signing keys, issuance, revocation, control history, fraud rules, key rotation.	UIC PKMW, UIC eTCD.
P0	Cross-company control center	Active Trips, exceptions, affected passengers, communication, replacement, and audit.	Flix describes traffic control and connected platform operations: Flix ESG.
P0	Support workspace	Booking/Journey/Trip/Passenger/ticket/payment/notification/control timeline with least privilege.	Flix Booking Reports, Flix Help Center.
P0	Legal center	Versioned localized documents, audience/action requirements, acceptance evidence, withdrawal/supersession.	App-store requirements below.
P1	Distribution channels	Reseller/office/driver channels use central offers, inventory, fulfillment, commission and audit.	Flix reseller program, OSDM roles.
P1	Fraud/risk operations	Duplicate control, ticket copy, abnormal reprint/refund/override/cash variance, device compromise.	UIC eTCD.
P1	Standards boundary	Stable internal model with GTFS/GTFS-RT/OSDM-compatible import/export adapters.	GTFS, OSDM.
P1	Data quality	Referential validation, freshness, completeness, route/stop/Trip reconciliation, quarantine, lineage.	DfT emphasizes matching timetable/location identifiers and data quality: DfT guide.
P2	Demand/yield/network optimization	Forecast, schedule, capacity, price, and service experiments with human controls.	Flix describes demand forecasting, optimized schedules, and yield optimization: Flix Tech.

Exceptional-case catalogue

These are required acceptance scenarios. They are product recommendations derived from the state boundaries above, not claims that any one benchmark implements them exactly.

Stop, pickup, map, and timing cases

Case	Required outcome
Base stop has no street address	Require pin plus landmark/instructions; optionally generate full Plus Code; directions must work from coordinates.
Company changes only one Trip's pickup	Create Stop Call override; do not mutate the base stop or other Trips.
Pickup changes after booking	Preserve old/new values, notify every affected booking and crew member, update ticket/Wallet/passenger itinerary, record delivery/acknowledgment.
Passenger does not acknowledge move	Escalate in control center and provide contact workflow; do not silently mark informed.
Driver remains offline with stale pickup	Show package age and high-priority conflict on reconnection; control staff see stale-device risk.
Map provider unavailable	Show coordinates, Plus Code, landmark, text directions, and call/support action.
Coordinates and landmark disagree	Block publish or require an explicit reviewed override; retain data-quality incident.
Pickup move makes accessible boarding unavailable	Mark accessibility impact, contact affected passengers, and require operational resolution.
Stop skipped after some passengers boarded	Create disruption and passenger-specific handling; do not simply delete the Stop Call.
Bus already departed when pickup moves	Reject ordinary edit; require incident/control command with affected-passenger plan.
Device time differs from server	Display authoritative schedule/server anchor; use monotonic time for elapsed timers.
Duplicate route has different rendezvous on same day	Every result, ticket, notification, and driver view shows Trip-specific point and service number.

Driver sale, fare, passenger, and inventory cases

Case	Required outcome
Boarding equals or follows alighting	Reject before quote.
Boarding Stop Call already passed	Require control-authorized exception or choose current/next valid stop; audit reason.
Group members have different destinations	Create passenger-specific segments and prices; never force one group destination.
Passenger has no phone/email	Permit company-policy walk-up identity minimum; print/show artifact and record delivery method.
Passenger provides duplicate name	Use distinct Passenger IDs/control numbers; name is not identity.
Child/minor category selected	Apply versioned company/legal policy and required guardian data; counsel defines rules.
Accessibility resource required	Reserve actual capacity/resource and verify vehicle/stop eligibility before confirmation.
Bus is full	Reject guaranteed sale; offer next service/waitlist only if supported.
Free seat exists but segment capacity conflicts	Segment/Stop Call inventory is authoritative; do not rely on total bus capacity alone.
Replacement bus has different layout	Reconcile seats/resources, identify displaced passengers, notify, and require resolution before departure.
Driver enters a lower/higher fare	Require permission, expected-vs-entered variance, reason and approval policy; preserve both amounts.
Fare changes while driver is offline	Existing leased fare version remains bounded until expiry; otherwise reconnect or create provisional sale.
Two devices sell offline	Inventory leases must be non-overlapping; out-of-lease sync becomes a visible exception, never silent oversell.
Same sale command retries	Return the original booking/payment/fulfillment via idempotency key.
Company approval is required	Pending booking has no valid ticket; onboard flow needs delegated confirmation or is unavailable.
Approval rejected after cash collected	Produce linked refund/void workflow and customer communication; never delete history.
Approval expires	Release inventory, resolve cash, notify customer/driver, preserve audit.
Passenger no-show	Mark Passenger/segment no-show independently; booking and other passengers remain intact.

Cash, receipt, print, and document cases

Case	Required outcome
Passenger tenders more than fare	Record tender and calculated/confirmed change according to company policy.
Driver lacks change	Require passenger decision or approved adjustment; never falsify tender.
Wrong currency	Reject or invoke configured conversion policy with rate/version; no ad hoc arithmetic.
Payment recorded but booking fails	Atomic rollback or compensating exception; cash cannot disappear into an unlinked record.
Booking commits but printer is offline	Sale stays valid; queue print and use display/share/protected-link fallback.
Printer prints but response is lost	Query/reconcile job; retry same document, not sale.
Paper runs out midway	Mark job failed/unknown, allow audited reprint, provide digital fallback.
Reprint requested repeatedly	Flag anomaly, require reason/permission, watermark copy if policy requires.
Receipt and ticket requested together	Render two semantically distinct documents linked to one sale.
PDF generation fails	Ticket credential remains available in app/QR; document job retries independently.
Arabic font missing in PDF	Fail document QA/job rather than emit unreadable or substituted glyphs.
Refund after shift close	Create adjustment tied to original shift and current actor; update settlement exception.
Offline sale syncs after settlement close	Reopen via adjustment period/exception, not historical mutation.
Driver declares cash variance	Require reason, evidence and supervisor resolution; preserve original declaration.

QR, control, sharing, and ownership cases

Case	Required outcome
QR belongs to wrong Trip/leg/date	Reject with precise operational reason and safe manual lookup option.
Passenger boards at wrong Stop Call	Apply policy; never silently consume a different segment.
Credential already checked	Show prior control time/device/stop within driver permissions; require override reason if allowed.
Ticket cancelled/refunded/reissued	Online control rejects old credential; offline snapshot shows freshness and queues exception if stale.
Signing key rotated	Preload overlapping verification keys and validity windows; never invalidate legitimate cached tickets abruptly.
Scanner is offline too long	Degrade from definitive “valid” to policy-defined stale/risk state after freshness threshold.
Printed QR is damaged	Manual lookup by control/booking reference plus passenger verification; audit manual check.
Screenshot copied	Online duplicate control and optional dynamic on-screen QR mitigate reuse; printed static ticket remains supported.
Customer shares PDF	Treat as copy of bearer artifact, not account or booking ownership transfer.
Customer transfers ticket	Validate policy/identity, revoke/reissue or relink, notify both parties, preserve history.
Nearby wrong recipient selected	Require matching verification code and final recipient confirmation before payload.
Nearby connection unverified	Refuse sensitive artifact transfer.
Phone lost after ticket issued	Authenticated recovery or booking-code + family-name lookup can re-display current credential and revoke old dynamic session.
Public ticket URL guessed	Return no booking; require ownership session or booking proof.
Family name has Arabic/Latin variants	Use normalized comparison rules with rate limiting and support fallback; do not expose which field matched.

Operations, disruption, support, and quality cases

Case	Required outcome
No assigned driver/vehicle	High-priority pre-departure exception with accountable resolution.
GPS offline	Show last point/time and confidence; do not display a moving/real-time claim.
Delay crosses threshold	Create one canonical disruption event; passenger, driver, company, platform, support, and analytics consume it.
Driver reports a different delay cause	Preserve source and review history; authorized control can resolve canonical cause.
Missed connection caused by first leg	Identify affected Journey passengers and offer/review protected rebooking; do not treat legs as unrelated bookings.
Trip cancellation	Release/transfer inventory, update fulfillment, communicate, expose self-service/support actions, reconcile finance.
Passenger incident	Restrict sensitive details by role, preserve evidence, link response and follow-up.
Lost item	Structured case links Trip/vehicle/seat/Stop Calls without exposing manifest broadly.
Complaint arrives before Trip completion	Accept and link to live Journey; do not require completed status.
Feedback is abusive or fraudulent	Moderate and audit; separate public review from private quality signal.
Driver/vehicle/company changes after sale	Update every role projection and document disclosure; keep historical assignment.
Notification provider fails	Retry/fallback by channel policy, show delivery status to support, never claim delivered on enqueue only.

Additions beyond the supplied 154-feature benchmark

These should be added to the traceability ledger as separate acceptance rows rather than hidden inside larger features.

New ID	Priority	Additional capability	Why it is distinct
E-01	P0	Versioned Trip Stop Call pickup/drop-off override	A reusable stop and a dated rendezvous are different domain objects.
E-02	P0	Pickup-change propagation and acknowledgment	Editing a pin is incomplete without passenger/crew/control delivery evidence.
E-03	P0	Driver/reseller/office point-of-sale channel	Central booking must support legitimate non-self-service sales.
E-04	P0	Per-passenger boarding and alighting on walk-up sales	A group booking may contain different segment rights and prices.
E-05	P0	Versioned fare catalogue and controlled driver override	Operator-entered price needs governance, not free text.
E-06	P0	Cash shift, drawer, variance, and reconciliation	Payment collection is incomplete without custody and closeout.
E-07	P0	Confirmation separated from fulfillment	A pending company decision must not issue a valid-looking ticket.
E-08	P0	Booking/ticket/receipt/invoice semantic separation	Documents have different operational and financial authority.
E-09	P0	Hybrid signed QR plus online control registry	Offline authenticity and current revocation/use state solve different problems.
E-10	P0	Offline inventory lease for guaranteed sales	Queued writes alone cannot prevent two devices selling one seat.
E-11	P0	Idempotent offline command/reconciliation ledger	Retries and delayed synchronization must not duplicate money or rights.
E-12	P0	Versioned legal center and consent evidence	Every app/channel needs the same current legal documents and acceptance truth.
E-13	P1	Printer adapter, spooler, health, and audited reprint	Printing is a device workflow, not a synchronous button side effect.
E-14	P1	Secure artifact copy versus authenticated ownership transfer	Sending a PDF and transferring a ticket are materially different.
E-15	P1	Verified offline phone-to-phone ticket delivery	Useful where connectivity and conventional station infrastructure are weak.
E-16	P1	Time trust and offline freshness policy	Editable device clocks cannot decide financial or credential validity.
E-17	P1	Ticket-control lifecycle and fraud operations	Issue, use, duplicate, revoke, refund, reissue, and key rotation need one ledger.
E-18	P1	Device/keyset/package freshness control center	Offline-capable field apps require observable operational health.
E-19	P1	Standards import/export adapters with internal-model isolation	GTFS/OSDM interoperability must not dictate unstable internal behavior.
E-20	P1	Connected data-quality and lineage workflow	Bad stop, fare, Trip, and identity data must be quarantined and corrected visibly.

Centralized, versioned legal center

Platform-policy evidence

Apple requires an accessible in-app privacy policy, disclosure of collection/use/sharing and retention/deletion practices, a way to revoke consent or request deletion, and in-app account deletion when an app supports account creation. Apple also asks account-based apps to provide App Review with an active demo account or fully featured demo mode and supporting resources such as sample QR codes. Apple App Review Guidelines and Apple account deletion guidance.

Google Play requires accurate user-data disclosures, a privacy policy, prominent disclosure/affirmative consent for unexpected sensitive-data use, Data Safety declarations, and account-deletion paths for apps that create accounts. Google Play User Data policy, prominent disclosure guidance, and account deletion requirements.

WCAG 2.2 is a W3C Recommendation for accessible web content across devices. WCAG 2.2. UN CRPD Article 9 explicitly includes access to transportation, information, and communications in urban and rural areas. UN CRPD Article 9.

EU Regulation 181/2011 covers information, complaint handling, cancellation/delay, and assistance/accessibility for bus and coach passengers in its jurisdiction. It is useful as a product-policy benchmark but is not presented as Syrian law. European Commission road passenger rights and Regulation (EU) 181/2011.

Counsel boundary

The legal center is technical infrastructure, not a substitute for Syrian counsel. Counsel must review, at minimum:

• contract formation and when a booking becomes binding;
• company-versus-platform contracting roles and liability;
• carriage, cancellation, delay, refund, no-show, baggage, and passenger assistance rules;
• minors, guardians, identity requirements, and emergency data;
• privacy, consent, location/telemetry, biometrics/camera/QR, retention, access, deletion, and cross-border processing;
• marketing, cookies/analytics, loyalty, reviews, and public company profiles;
• cash receipts, invoices, taxes, document numbering, refunds, currency, fiscal-device rules, and accounting retention;
• driver/employee monitoring, GPS, incidents, photos, and workplace notices;
• transport licensing, insurance, vehicle/driver documents, and safety reporting;
• Arabic legal text, English translation precedence, governing law, dispute and complaint paths;
• app-store country availability and third-party provider terms.

Do not copy EU/GDPR/Flix wording and label it Syrian compliance. The GDPR may be used as an international privacy architecture benchmark only where counsel decides it is relevant.

Recommended document inventory

Audience	Versioned documents
All visitors/travelers	Privacy notice; cookie/analytics notice; accessibility statement; support and complaint policy; acceptable-use/security notice.
Booking purchaser/passenger	Terms of carriage; booking terms; cancellation/rebooking/refund/no-show policy; pickup/boarding policy; baggage/special-item policy; accessibility/assistance policy; minor/family policy; cash/payment policy; ticket/QR and identity policy.
Traveler account	Account terms; identity linking; account deletion/data request; saved passenger/profile rules; Google/phone/email sign-in notice.
Company/operator	Platform agreement; company data-processing/privacy roles; service/quality rules; fare/loyalty/promotion rules; settlement/commission terms; public-profile content/review policy; document retention.
Driver/staff	Driver app terms; acceptable use; location/background telemetry notice; camera/QR and incident-media notice; offline/device policy; cash/printer custody; training acknowledgment.
Reseller/office agent	Sales authority; fare/override/refund/reprint limits; commission; cash/reconciliation; customer-data access; device/security rules.
Marketing/loyalty	Promotion-specific terms; company loyalty terms; optional marketing consent; channel preferences and withdrawal.

Recommended legal data model

legal_document
  id, stable_key, owner_scope(platform|company), audience, purpose

legal_document_version (immutable after publish)
  id, document_id, semantic_version, locale, rendered_content
  content_hash, summary_of_change, materiality_class
  published_at, effective_at, retired_at, status
  approved_by, approval_record

legal_requirement_rule
  action (book, create_account, enable_tracking, join_loyalty, etc.)
  role, app, company, market, passenger_category
  required_document_version, acceptance_kind

legal_acceptance_event (append-only)
  actor/account/guest proof, role, company, booking/action
  document_version_id, exact content_hash, locale
  presented_at, accepted/declined/withdrawn_at
  app/channel/version, evidence metadata (minimized)

legal_supersession
  old_version, new_version, material_change, reacceptance_rule

Rules:

1. Published legal versions are immutable; corrections create a new version.
2. Store the exact content hash and version accepted, not only termsAccepted = true.
3. Required contract acceptance and optional marketing/location consent are separate events.
4. Declining optional consent must not block unrelated core functionality; Google recommends graceful degradation when permissions are declined. Google prominent disclosure guidance.
5. Ask for acceptance at the action where it matters, using the correct company/platform document set.
6. Reacceptance is driven by counsel-approved materiality rules, not every typo.
7. Provide a public current version and accessible archive, and expose current accepted versions in account/company/driver settings.
8. Withdrawal or account deletion does not erase records that counsel requires ShamBus to retain; the user-facing flow must explain the reviewed outcome.
9. Company-owned documents may apply only to that company's Journey Legs, while platform documents apply across the booking; mixed-operator Journeys must present this clearly.
10. Every web/mobile/driver/dashboard/admin/notification/PDF surface resolves content from the same version service.

Delivery sequence

P0 — transaction and safety boundary

1. Stop Call override and change propagation: exact trip pickup, maps, landmarks, versioning, acknowledgment, accessibility impact.
2. Atomic multi-channel sale: customer, office, driver, and reseller share quote/inventory/booking/payment/fulfillment contracts.
3. Driver onboard POS: per-passenger Stop Calls, controlled fares, cash, company approval semantics, receipts, and manifest updates.
4. Ticket trust: signed PII-minimized QR, control registry, revocation/reissue, duplicate control, key lifecycle.
5. Offline authority: pre-trip package, command idempotency, bounded inventory leases, stale-state policy, reconciliation.
6. Cash custody: shift/drawer closeout, variance, refunds/voids, settlement linkage, immutable audit.
7. Document semantics: booking acknowledgment, confirmation, ticket, receipt, invoice, refund, and settlement templates/services.
8. Legal center: counsel-reviewed initial document set, immutable versions, action rules, consent/acceptance evidence, deletion paths.

P1 — enterprise operations

1. Printer adapters, spooler, printer/device fleet health, fallback and audited reprints.
2. Wallet passes, protected document retrieval, secure share-copy and authenticated transfer.
3. Live exception control, support workspace, missed-connection/disruption orchestration.
4. Structured feedback, quality cases, driver/vehicle/company/stop analytics.
5. Reseller/agent permissions, commission, reconciliation, and reporting.
6. GTFS/GTFS-RT/OSDM adapters, data-quality validation, lineage and quarantine.
7. Fraud/risk views for duplicate QR, override, refund, reprint, cash and device anomalies.

P2 — differentiation

1. Verified offline phone-to-phone ticket delivery.
2. Dynamic/rotating on-screen QR and richer Wallet journey updates.
3. Through/multimodal offers and protected transfer handling.
4. Demand forecasting, network optimization, yield experimentation and price alerts.
5. Contextual travel-day assistant and automated but human-reviewable recovery.

Minimum end-to-end acceptance journeys

No capability above is complete until the applicable journey passes domain, API, UI, device, offline, permission, audit, and production checks.

1. Traveler searches an exact pickup point, books multiple passengers with different Stop Call destinations, pays cash later, receives pending status, company approves, and every Passenger receives the correct QR/ticket.
2. Company moves one Trip's pickup pin and landmark; booked travelers, driver, support, and control receive one canonical change, and acknowledgment/escalation is visible.
3. Driver sells a cash ticket onboard for two passengers with different alighting stops, assigns capacity, prints one receipt plus Passenger tickets, and the shift/company/platform ledgers reconcile.
4. The same driver sale repeats after a timeout and returns the same sale, documents, and inventory consumption.
5. Driver performs the sale offline within a non-overlapping inventory lease, checks the Passenger in, reconnects, and central reconciliation produces no duplicate booking/payment/control event.
6. A second offline device attempts the same capacity and is prevented by lease design or routed to a visible provisional exception.
7. Printer produces paper but returns an unknown status; the app reprints the same document without collecting cash or issuing a ticket twice.
8. Passenger shares a PDF copy; the recipient can present the credential but cannot manage, refund, or view private booking data without booking proof/account ownership.
9. Passenger performs a policy-approved ownership transfer; the old credential becomes invalid and the new holder receives a reissued one with full audit history.
10. QR is validly signed but cancelled; online control rejects it. Offline control shows revocation-data freshness and follows the documented stale policy.
11. Company-required confirmation is rejected after cash collection; inventory, ticket state, refund/void receipt, notifications, shift ledger, and settlement exception remain consistent.
12. A Trip is delayed, pickup moves, and a connection is missed; every app displays the same Trip/Stop Call/disruption truth and support sees the affected Journey.
13. An Arabic/English user reads the same legally effective document version, and acceptance stores exact version/hash/locale. Optional location consent can be declined without blocking unrelated booking.
14. Traveler deletes an account from iOS/Android; the flow meets current store-policy paths, while counsel-reviewed retained operational/financial records are explained and handled correctly.
15. A driver app remains offline through process death, restores its encrypted package and queued commands, preserves sequence/idempotency, and exposes freshness without leaking another company's manifest.

Production-readiness evidence required

For every traceability row promoted to released:

• schema migration and backfill evidence;
• RLS/authorization tests for traveler, driver, every company role, platform admin, reseller, support, and anonymous caller;
• server-side pricing/inventory/idempotency tests;
• booking/fulfillment/payment/control state-machine tests;
• Arabic and English content, Latin-digit, RTL/LTR, accessibility, and PDF checks;
• desktop, tablet, narrow mobile, Android, and iOS interaction evidence;
• offline, reconnect, process-death, stale-data, duplicate-command, and clock-skew evidence;
• printer disconnected/out-of-paper/unknown/retry/reprint tests when printing applies;
• QR signed/revoked/duplicate/wrong-leg/wrong-stop/stale-key tests;
• notification enqueue/provider/delivery/failure/fallback evidence;
• cash closeout, variance, refund, settlement, and audit reconstruction tests;
• observability showing correlation IDs without secrets or unnecessary PII;
• production deployment identifier, smoke results, role credentials held in the approved secure inventory, and clean rollback procedure;
• traceability ledger update with honest G, P, V, or R status—never a blanket “everything tested” claim.

Source-selection note

This report intentionally relies on primary/official sources: Flix-owned product/corporate/operator documentation; GTFS/MobilityData; OSDM/UIC; Google, Android, and Apple developer documentation; W3C and UN accessibility sources; European Commission/EUR-Lex benchmarks; NIST/IETF security guidance; DfT transport-data guidance; PCI SSC; and printer-vendor technical documentation. Vendor examples prove feasibility and interaction requirements, not procurement preference. Jurisdiction-specific benchmarks are not presented as Syrian legal requirements.