Roadmap — Ghasi Melmastoon

Companion: README · Product Overview · Risks & Tradeoffs

This folder is the canonical, release-by-release roadmap for Ghasi Melmastoon. Roadmaps tell us when the platform earns each capability; the strategic specs tell us what the end state looks like. The two are different documents on purpose.

Roadmap waves are gated by readiness criteria, not calendar dates. A wave ships when its definition-of-done is green; it slips when it is not. We avoid promising calendar months that we cannot keep across markets with very different operational realities.

Roadmap files

Wave	File	Horizon	Theme
R1	01-release-1-foundations.md	First ~6 months	Foundations: 5 pilot tenants in Afghanistan + Tajikistan; offline-capable Electron desktop; tenant-branded booking site; cash-on-arrival + Stripe + 1 MFS; basic housekeeping + key issuance via TTLock + Generic Wiegand
R2	02-release-2-scale-and-ai.md	Next ~6 months	Scale to 50 tenants; full AI gateway with HITL across 8 capabilities; chain multi-tenant switcher; multi-region (asia-south1 + asia-southeast1); Iran exploratory deployment; PayPal + 4 MFS; Salto + Assa Abloy adapters
R3 + Beyond	03-release-3-and-beyond.md	Year 1.5 → 3+	500+ tenants; white-label reseller program; React Native staff sub-app; kiosk mode; voice-driven housekeeping; local-LLM upgrades; AI content for theme; full marketing automation; GCC + Europe expansion

Audience guide

Audience	Where to start
Founder / commercial	This README → [Vision and Outcomes section in each wave file]
Product	Each wave's Scope IN/OUT, Epics included, and Definition of done sections
Engineering	Each wave's Service rollout order, Frontend rollout, and Infrastructure milestones
SRE	Each wave's Quality gates, Risks specific to release, and Cost envelope
Compliance	Each wave's Risks and the cross-references to docs/07-security-compliance-tenancy.md
Pilot tenants	R1 Pilot tenant program section

Wave-to-wave continuity

Waves are not independent products. Each builds on the prior wave's primitives:

• R1 → R2 — R1's pilot tenants become R2's first chain-switcher and AI-pilot customers; R1's anomaly-only edge AI becomes the first capability of R2's full ai-orchestrator-service; R1's single-region GCP deployment becomes R2's primary region with asia-southeast1 added as the active replica.
• R2 → R3 — R2's partner-channel pilot becomes R3's white-label reseller program; R2's voice-transcription pilot becomes R3's production capability; R2's chain switcher in the Electron desktop becomes R3's foundation for the multi-property owner portal split decision.

Wave entry and exit rules

A wave cannot exit unless every quality gate (functional, non-functional, AI, offline, security, multi-tenant, observability, documentation) is binary-green. A wave cannot start unless the prior wave has exited. Slipping a wave is preferred over reducing scope below the documented "definition of done"; deliberate scope reduction requires an ADR.

Each wave doc follows the same 12-section shape so that a reader who has worked through one can skim subsequent waves quickly: Vision & Outcomes, Scope IN/OUT, Epics included, Service rollout order, Frontend rollout, Infrastructure milestones, Tenant program, Quality gates, Risks specific to the release, Cost envelope, Dependencies & decision points, Definition of done.

Versioning of this roadmap

This roadmap is itself versioned with the rest of the documentation set. Material scope changes within a wave (an epic added or dropped, an external dependency that changes a gate definition, a watchpoint trigger that fires and forces a re-plan) are captured as PRs against the relevant wave doc with a changelog entry at the top of the file. The cross-wave continuity table above is updated on every such change.

Cross-references

• Strategic end-state: Product Overview, Enterprise Architecture, Service Index.
• Risk and tradeoff posture per release: Risks & Tradeoffs.
• Per-service readiness gating: each service's SERVICE_READINESS.md under services/<service>/.
• ADR index: docs/architecture/.
• Stack commitments (frozen): README §Stack Commitments — desktop is Electron (never Tauri); cloud is GCP.

A capability that is not in any of the three wave files is out of scope until it is added with a wave assignment, an owner, and a readiness gate. The roadmap is not a wishlist; it is a contract between product, engineering, SRE, compliance, and the commercial team.

How to read each wave file

Every wave file follows the same 12-section template so that comparing R1 to R2 to R3 is a like-for-like exercise:

1. Vision & Outcomes — measurable goals for the wave.
2. Scope (in / out) — IN list and explicit OUT list.
3. Epics included — mapping to EP-MEL-XX ids.
4. Service rollout order — month-by-month or quarter-by-quarter sequencing.
5. Frontend rollout — per-surface cadence.
6. Infrastructure milestones — IaC, observability, security, FinOps milestones.
7. Tenant program — pilot or growth program operating model.
8. Quality gates — functional, non-functional, AI, offline, security, multi-tenant, observability, documentation gates.
9. Risks specific to the release — slice of the platform register.
10. Cost envelope — target monthly GCP cost and per-tenant unit cost.
11. Dependencies & decision points — external dependencies and the latest decision dates.
12. Definition of done — binary checklist.

A wave that ships without sign-off on every section of its definition-of-done is not done. The Release Captain enforces this against the wave's risk slice.

Roadmap governance

Forum	Cadence	Output
Wave kickoff	Wave start	Confirmed scope, owners, dependencies
Monthly wave checkpoint	Monthly during the wave	Status against outcomes; risks raised; scope changes via ADR
Wave pre-flight	2 weeks before wave close	Definition-of-done review; gate sign-off; release-readiness call
Wave retrospective	2 weeks after wave close	Written learnings folded into next wave's plan and into Risks & Tradeoffs
Quarterly roadmap review	Quarterly across all waves	Beyond-R3 conjectures revisited; new ADRs proposed; tradeoffs re-justified

The roadmap is reviewed against Risks & Tradeoffs at every checkpoint. A risk that crosses an escalation threshold can pull scope; a wave that pulls scope must update its definition-of-done in the same PR.

Versioning of this folder

This folder is versioned with the rest of the documentation. Significant scope changes to a wave file require an ADR; minor refinements (clarifications, link fixes, tightening of acceptance criteria) are allowed without an ADR but must be reviewed in the next monthly checkpoint. Wave files for closed waves are kept as-is for reference; they are not retroactively edited to reflect what actually shipped — that history lives in the wave retrospective documents.