doc_id: “FLYMAX-06-PRD-PRODUCT_SCOPE_APPROVAL_REGISTER_V3-0”
project_name: “FlyMax V2.0”
title: “Product Scope Approval Register”
doc_type: “PRD”
category: “Product Requirements”
version: “1.0.0”
status: “active”
scope: “valid”
lifecycle_state: “active”
created: “2026-03-09”
updated: “2026-03-09”
author:
name: “George Joseph”
role: “Technical Lead / Solution Architect”
modified_by:
- name: “George Joseph”
role: “Technical Lead / Solution Architect”
date: “2026-03-09”
approved_by:
- name: “”
role: “”
date: “”
next_review_date: “2026-03-09”
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)
📗DOWNLOAD DOCX
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 |
☐ |
| 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. |
☐ |
| 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.
- 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.