Product Scope Approval Register
Product: Flight Booking Platform
Version: 3.0
Date: 2026-03-09
Document Type: Commercial scope-freeze and approval register (not a PRD)
Alignment basis: Product Model v3.0 and PRD v3.0.
1. Executive Scope-Freeze Summary
| Decision Area | Approved Direction | Approval | Notes |
|---|---|---|---|
| Authoritative baseline | Product Model v3.0 + PRD v3.0 | ☐ | These documents supersede redirect-era assumptions and govern scope interpretation for current planning. |
| Product model | Verteil-powered direct-booking flight retail and servicing platform | ☐ | Checkout, payment, booking continuity, support, and commercial controls are core scope, not future exceptions. |
| Primary supply model | Verteil-first supply and servicing backbone | ☐ | Launch with Verteil as the initial provider path; broader multi-provider expansion is later by default. |
| Checkout model | On-platform checkout with payment orchestration | ☐ | The governing journey is search → validate/reprice → pay/reserve credit → book → confirm → manage → service. |
| Commercial model | Direct transaction revenue | ☐ | Primary economics are markup, service fee, negotiated margin, and approved commercial program economics; click-out/affiliate is not the governing baseline. |
| Role model | Consumer + Agent + Admin/Ops | ☐ | The platform must support B2C and B2B/B2B2C operating layers with finance, support, and security workflows. |
| Launch language / locale | English-first UI; localization preferences allowed | ☐ | English-only launch remains acceptable, while currency and localization preferences are still in scope. |
| Support model | Ticket-led support mandatory; live chat optional | ☐ | Unified support ticketing is current scope; universal live chat is not a required MVP baseline. |
| Later-by-default record | Multiple Providers + AI only | ☐ | These are the only default later buckets unless explicitly approved to move forward. |
2. Governing Alignment Summary
- The old approval-register structure has been rebuilt around the v3 direct-booking model rather than lightly edited.
- The approved product position is a Verteil-powered, direct-booking, flight retail and servicing platform with platform-owned checkout, payment, booking continuity, markup/discount/credit governance, unified support ticketing, and Admin/Agent/User operating layers.
- Only two capability buckets remain later by default: Multiple Providers beyond Verteil, and AI.
3.1 Core Search, Results, Transparency & Merchandising
| Domain | Capability | Scope Status | Dependency / Gate | Business Effect | Risk | Approval |
|---|---|---|---|---|---|---|
| Core Search | One-way, round-trip, and multi-city search | MVP | Supplier-backed | Conversion / parity | Med | ☐ |
| Core Search | Passenger & cabin selection | MVP | None | Usability | Low | ☐ |
| Core Search | Airport autocomplete + nearby airport assist | MVP | Airport data | Conversion / parity | Low | ☐ |
| Core Search | Flexible dates / calendar pricing support | MVP | Supplier + UX | Conversion / trust | Med | ☐ |
| Results | Filters: price, stops, airline, departure/arrival, duration, layover | MVP | Search core | Parity / usability | Low | ☐ |
| Results | Sorting: price, duration, departure/arrival, best value | MVP | Ranking rules | Conversion | Med | ☐ |
| Transparency | Fare breakdown, baggage, restrictions / refundability visibility | MVP | Supplier-dependent | Trust / compliance | High | ☐ |
| Validation | Reprice / validate before checkout or payment confirmation | MVP | Supplier + booking flow | Trust / dispute reduction | High | ☐ |
| Continuity | Booking continuity after checkout with itinerary / status visibility | MVP | Booking core | Trust / retention | High | ☐ |
3.2 Checkout, Payment, Booking & Servicing
| Domain | Capability | Scope Status | Dependency / Gate | Business Effect | Risk | Approval |
|---|---|---|---|---|---|---|
| Checkout | Traveler details capture inside platform | MVP | Checkout core | Transaction completion | Med | ☐ |
| Payments | Payment gateway integration | MVP | Gateway + legal | Revenue realization | High | ☐ |
| Payments | Payment intent / auth / capture / failure / refund / reversal tracking | MVP | Payment state machine | Finance / support | High | ☐ |
| Booking | Verteil-backed booking creation and confirmation / ticket visibility | MVP | Verteil + supplier support | Core product | High | ☐ |
| Booking Mgmt | Booking retrieval / management portal visibility | MVP | Order store | Support / retention | High | ☐ |
| Servicing | Cancel / refund / reschedule / modify flows | MVP-Gated | Supplier support + ops playbooks | Trust / retention | High | ☐ |
| Servicing | Ancillaries where supported | MVP-Gated | Supplier-dependent | Margin / parity | Med | ☐ |
| Held / Pay-later | Held booking / pay-later paths | MVP-Gated | Market + supplier + finance approval | Conversion / B2B | High | ☐ |
| Notifications | Booking confirmation and status notifications | MVP | Email baseline | Trust / support | Med | ☐ |
3.3 Roles, Identity, Portals & Security Controls
| Domain | Capability | Scope Status | Dependency / Gate | Business Effect | Risk | Approval |
|---|---|---|---|---|---|---|
| Identity | Consumer authentication and profile management | MVP | Auth service | Continuity / retention | Low | ☐ |
| Identity | Agent organization model and sub-user controls | MVP | RBAC + org model | B2B enablement | High | ☐ |
| Identity | Admin / Ops portal with provider, booking, finance, and support oversight | MVP | RBAC + admin | Operational control | High | ☐ |
| Security | MFA / 2FA support | MVP | Auth + policy | Security / compliance | Med | ☐ |
| Security | SSO activation | MVP-Gated | Identity provider + policy | Enterprise / internal ops | Med | ☐ |
| Experience | Consumer web, Agent workspace, and Admin/Ops experience layers | MVP | Portal segmentation | Role clarity | High | ☐ |
3.4 Commercial, Finance, Credit & Settlement Controls
| Domain | Capability | Scope Status | Dependency / Gate | Business Effect | Risk | Approval |
|---|---|---|---|---|---|---|
| Pricing | Markup governance | MVP | Policy engine | Primary revenue | High | ☐ |
| Pricing | Discount management including corporate/private fares | MVP-Gated | Commercial approval + supplier support | Revenue / channel strategy | High | ☐ |
| Finance | Agent credit ledger: top-up, approval, reserve, consume, release, adjust | MVP | Finance approval + ledger | B2B transaction model | High | ☐ |
| Finance | Settlement reporting and booking-linked financial traceability | MVP | Finance data model | Reconciliation / control | High | ☐ |
| Revenue | Service fee configuration | MVP | Pricing rules | Revenue | Med | ☐ |
| Reporting | Operational and financial reports / exports | MVP | Reporting layer | Ops / finance | Med | ☐ |
| Governance | Merchant-of-record and liability model approval | Formal Decision | Legal + finance + commercial | Risk envelope | High | ☐ |
3.5 Support, Operations, Audit, Integration & Reporting
| Domain | Capability | Scope Status | Dependency / Gate | Business Effect | Risk | Approval |
|---|---|---|---|---|---|---|
| Support | Unified support ticketing | MVP | Ops workflow | Supportability | High | ☐ |
| Support | Support routing by booking / payment / credit / servicing category | MVP | Ticket rules | Operational continuity | Med | ☐ |
| Audit | Immutable audit logs for sensitive actions | MVP | Audit store | Security / compliance | High | ☐ |
| Integration | CDC / webhooks / status sync | MVP | Provider + event pipeline | Continuity / reporting | High | ☐ |
| Operations | Provider / service configuration | MVP | Admin controls | Operational control | Med | ☐ |
| Operations | Observability: logs, metrics, traces, alert thresholds | MVP | Platform ops | Reliability / incident response | High | ☐ |
| Data | Data retention policy for search, booking, audit, support, finance artifacts | Formal Decision | Legal + security | Compliance | High | ☐ |
3.6 Growth, Promotions, SEO & Optional Commercial Surfaces
| Domain | Capability | Scope Status | Dependency / Gate | Business Effect | Risk | Approval |
|---|---|---|---|---|---|---|
| Promotions | Promotions and governed boosted placement capability | MVP | Commercial rules + labeling | Revenue / growth | Med | ☐ |
| Content | SEO, route/city content, knowledge-base surfaces | MVP | Content ops | Acquisition / support deflection | Med | ☐ |
| Ads | Ad surfaces as secondary / optional revenue layer | P2-Gated | Trust rules + labeling | Secondary revenue | High | ☐ |
| Notifications | SMS / WhatsApp / push beyond email baseline | MVP-Gated | Vendor + compliance + market approval | Engagement | Med | ☐ |
| Special Inventory | Charter / custom flight inventory module | MVP-Gated | Commercial + supplier + ops approval | Differentiation | High | ☐ |
4. Supply Model Options
| Option | Description | Status | Rationale | Approval |
|---|---|---|---|---|
| Model S1 | Verteil-first direct-booking launch model | Selected for current baseline | Fastest path that matches Product Model v3 and PRD v3; supports search, booking, servicing, and agent workflows through a single initial backbone. | ☐ |
| Model S2 | Verteil + additional providers | Later by default | Valid only after current-baseline stabilization; broader supplier mix is explicitly deferred by default. | ☐ |
| Model S3 | Provider-direct / custom supply expansion | Future / case-by-case | Only justified where margin, coverage, or strategic leverage outweighs integration and ops complexity. | ☐ |
4.1 Provider / Capability Activation Grid
| Provider / Capability | Type | Phase | Default Active | Activation Rule | Approval |
|---|---|---|---|---|---|
| Verteil | Primary provider | MVP | Yes | Core baseline | ☐ |
| Additional providers beyond Verteil | Expansion | Later by default | No | Requires separate approval | ☐ |
| Corporate / private fare access | Commercial mode | MVP-Gated | Conditional | Supplier + commercial approval | ☐ |
| Ancillary depth | Content mode | MVP-Gated | Conditional | Supplier support | ☐ |
| Charter/custom inventory | Special inventory | MVP-Gated | Conditional | Commercial + ops approval | ☐ |
5. Phase Definition & Activation Boundaries
| Phase Bucket | Definition | Interpretation |
|---|---|---|
| MVP baseline | Verteil-first launch, on-platform checkout, payment gateway, booking continuity, Admin/Agent/User portals, credit ledger, markup, support ticketing, reports, audit, parity search UX | Current baseline |
| MVP gated | Corporate/private fares, held/pay-later paths, servicing depth beyond support-routed handling, SSO timing, SMS/WhatsApp/push, charter inventory | In-scope but activation requires approval |
| Phase 2 | Secondary revenue accelerators, deeper merchandising, optional ad surfaces, operational optimization after baseline stabilization | Allowed once trust and operational controls are stable |
| Later by default | Multiple Providers beyond Verteil, AI capabilities | Only default later buckets |
6. Risk Acknowledgment & Dependency Declaration
| Risk | Acknowledgment | Required Mitigation | Ack. |
|---|---|---|---|
| Payment and liability exposure | The platform owns checkout and payment-linked states. | Clear merchant-of-record decision, state maps, finance sign-off, refund/reversal procedures. | ☐ |
| Supplier dependency | Launch is Verteil-first, so supply and servicing depth depend on provider/supplier support. | Activation gates, provider SLAs, routing rules, live route-set validation. | ☐ |
| Servicing complexity | Refund/change/reschedule depth varies by supplier and market. | Explicit launch-depth decision, support playbooks, partial self-service where safe. | ☐ |
| Credit exposure | Agent credit introduces financial control and misuse risk. | Approval thresholds, ledger auditability, finance-visible state transitions, exposure caps. | ☐ |
| Support load | Owning bookings shifts first-line issue responsibility to the platform. | Ticket-led support, routing categories, escalation matrix, staffing-hour decision. | ☐ |
| Promotions / boosted placement trust risk | Commercial placements can damage trust if not governed. | Labeling, policy rules, audit logs, separation from core ranking decisions. | ☐ |
| Compliance / retention | Bookings, audit logs, support artifacts, and finance data need explicit retention rules. | Formal data-retention decision, legal/security approval, export/deletion controls. | ☐ |
7. Open Decisions Requiring Formal Approval
| Decision Item | What must be finalized | Approval |
|---|---|---|
| Merchant-of-record and settlement design | Who is financially liable, how customer payment settles against supplier obligations, and what MoR model governs launch. | ☐ |
| Payment methods by market | Card and other payment methods approved for MVP by country/market. | ☐ |
| Credit policy | Top-up, reservation, release, adjustment, exposure thresholds, and approval authorities. | ☐ |
| Corporate / private fare activation | Which markets, suppliers, and user groups may access them. | ☐ |
| Servicing depth at launch | What is self-service vs routed to support for cancel/refund/change/reschedule. | ☐ |
| Notification channel mix | Email-only baseline or approved inclusion of SMS / WhatsApp / push. | ☐ |
| SSO activation timing | Mandatory at launch for some roles or phased after MVP. | ☐ |
| Charter/custom inventory activation | Dark launch, partial launch, or later launch decision. | ☐ |
| Support operating model | SLA, staffing hours, escalation policy, and supplier coordination playbook. | ☐ |
| Data retention policy | Retention durations for search, booking, audit, support, and financial artifacts. | ☐ |
8. System Integrity & Release Readiness Approvals
| Go-Live Gate | Success condition | Approval |
|---|---|---|
| In-scope features implemented and tested | All approved MVP baseline items are built and QA-complete. | ☐ |
| Payment and booking state linkage verified | Finance and support can trace one booking end-to-end. | ☐ |
| Booking management visible in portal | Consumer/Agent/Admin critical journeys work. | ☐ |
| Support ticketing operational | Ticket categories, routing, and escalation are live. | ☐ |
| Admin controls and audit logs operational | Sensitive actions are reconstructable. | ☐ |
| Provider credentials configured for live route set | Live launch coverage is explicitly approved. | ☐ |
| Rollback approach rehearsed | Operational recovery path tested before go-live. | ☐ |
| Role matrix delivered | Permissions are documented and signed off. | ☐ |
| Support workflow guide delivered | Support can triage real incidents. | ☐ |
| Payment / booking state map delivered | Ambiguous transaction states are not allowed. | ☐ |
| Credit lifecycle guide delivered | Finance and Ops approve the end-to-end lifecycle. | ☐ |
| Incident / health dashboard guide delivered | Observability thresholds and response ownership are defined. | ☐ |
| Data export / report guide delivered | Operational and finance exports are usable. | ☐ |
9. Later-by-Default Record
| Capability Bucket | Status | Interpretation | Approval |
|---|---|---|---|
| Multiple Providers beyond Verteil | Later by default | Not current-baseline MVP scope. Requires separate commercial, architectural, and ops approval to pull forward. | ☐ |
| AI capabilities | Later by default | Not required for baseline operation. Any AI activation must be treated as additive and separately approved. | ☐ |
10. Signature & Approval
| Approving Role | Name / Signature | Date | Approved |
|---|---|---|---|
| Product Owner / Head of Product | ☐ | ||
| Commercial Director / Partnerships Lead | ☐ | ||
| Engineering / Delivery Lead | ☐ | ||
| Finance / Operations Approval | ☐ |
Scope-Freeze Acknowledgment
- ☐ We approve the selected product model, supply model, checkout model, current scope classification, and later-by-default record documented above.
- ☐ We acknowledge the operational, financial, support, and compliance risks listed in Section 6.
- ☐ We agree that gated modules may not be activated without the relevant formal approvals recorded in Section 7.
Governance Footer
- Document ID: FLYMAX-06-PRD-PRODUCT-SCOPE-APPROVAL-REGISTER-V3.0
- Canonical Version: 1.0.0
- Lifecycle: Active
- Scope: Valid
- Source of Truth: docs/
- Related Change Ticket:
- Last Reviewed On: 2026-03-09
- Next Review Due: 2026-03-09
Approval Sign-off
| Role | Name | Date | Status |
|---|---|---|---|
| Product Owner | Pending | ||
| Technical Lead / Solution Architect | George Joseph | Pending | |
| Engineering Lead | Pending | ||
| Commercial / Operations | Pending |
Document Lineage
- Supersedes:
- Superseded By:
Change Log
- 1.0.0 (2026-03-09) - Header/footer standardized to FlyMax documentation playbook.