title: “FlyMax V2.0 Living Documentation Framework” category: Strategic Planning status: “active” version: “2.0.0” created: 2026-02-25 updated: 2026-03-09 project_name: “FlyMax V2.0” owner: name: “George Joseph” role: “Technical Lead / Solution Architect” review_cycle: “Bi-weekly” related:

“Enhancement Roadmap”
“Delivery Flow Master Checklist”
“Master Index”
“Product Model v3.0”
“PRD v3.0” doc_id: “FLYMAX-05-Strategy-DOCUMENTATION-FRAMEWORK” doc_type: “Strategy” scope: “valid” lifecycle_state: “active” 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”

FlyMax V2.0 Living Documentation Framework

[!IMPORTANT] This is a living framework. It defines how every document in docs/ is created, versioned, reviewed, superseded, and approved.

Document Control

Project: FlyMax V2.0
Framework Version: 2.0.0
Owner: George Joseph (Technical Lead / Solution Architect)
Last Updated: 2026-03-09
Review Cadence: Bi-weekly or before major release decisions
Scope: Valid

1. Purpose and Applicability

This framework is mandatory for all strategic, product, architecture, engineering, compliance, and delivery documents under docs/.

Objectives:

Keep documentation aligned to the current operating model (direct-booking baseline).
Make legacy context visible without allowing legacy assumptions to leak into current scope.
Standardize metadata for searchability, traceability, and approval governance.
Keep framework content updated and alive through scheduled reviews.

2. Repository Structure and Versioning Model

2.1 Folder Convention

Use the existing sectioned structure:

docs/01-supply-strategy/
docs/02-competitive-intelligence/
docs/03-feature-roi-analysis/
docs/04-competitive-parity/
docs/05-strategic-planning/
docs/06-product-requirements/

Each section should contain:

README.md as section index
versioned folders such as v1.0, v2.0, v3.0

2.2 Versioning Rules

Use semantic versioning for document content:

MAJOR for scope/model shifts (example: redirect-led -> direct-booking)
MINOR for meaningful additions that are backward compatible
PATCH for corrections, clarity, and non-behavioral edits

Examples:

1.0.0 -> first baseline
2.0.0 -> model-level shift
2.1.0 -> added approved capability domain
2.1.1 -> typo/clarity/link fix

2.3 Scope and Lifecycle Labels

Controlled values:

Scope: valid or legacy
Lifecycle: active, superseded, deprecated, archived
Status: draft, review, approved, active, legacy

Rules:

If scope: legacy, superseded_by must be present.
Legacy docs remain linkable for history but must include warning callout and replacement link.

3. Standard Header Approach (Required)

Every markdown document must start with YAML frontmatter.

3.1 Canonical YAML Header Template

---
doc_id: "FLYMAX-<SECTION>-<TYPE>-<SLUG>"
project_name: "FlyMax V2.0"
title: "<Document Title>"
doc_type: "PRD" # PRD | Model | Register | Blueprint | Strategy | ADR | Checklist
category: "<Section Category>"
version: "<MAJOR.MINOR.PATCH>"
status: "draft" # draft | review | approved | active | legacy
scope: "valid" # valid | legacy
lifecycle_state: "active" # active | superseded | deprecated | archived
created: "YYYY-MM-DD"
updated: "YYYY-MM-DD"
author:
  name: "George Joseph"
  role: "Technical Lead / Solution Architect"
modified_by:
  - name: "<Name>"
    role: "<Role>"
    date: "YYYY-MM-DD"
approved_by:
  - name: "<Name>"
    role: "<Role>"
    date: "YYYY-MM-DD"
reviewers:
  - "<Role or Name>"
confidentiality: "internal" # public | internal | confidential
audience: ["Product", "Engineering", "Architecture"]
tags: ["flymax", "flight-booking"]
supersedes: ""
superseded_by: ""
related:
  - "../README.md"
  - "../../INDEX.md"
next_review_date: "YYYY-MM-DD"
change_ticket: ""
---

3.2 Human-Readable Header Block (Immediately Below Title)

## Document Control
- Project: FlyMax V2.0
- Version: 2.0.0
- Scope: Valid
- Status: Active
- Author: George Joseph (2026-03-09)
- Modified By: <Name> (YYYY-MM-DD)
- Approved By: <Name> (YYYY-MM-DD)
- Owner: George Joseph, Technical Lead / Solution Architect
- Next Review Date: YYYY-MM-DD

Every document should end with governance and sign-off details.

---

## Governance Footer
- Document ID: FLYMAX-<SECTION>-<TYPE>-<SLUG>
- Canonical Version: 2.0.0
- Lifecycle: Active
- Scope: Valid
- Source of Truth: docs/
- Related Change Ticket: <JIRA/ADO/Issue>
- Last Reviewed On: YYYY-MM-DD
- Next Review Due: YYYY-MM-DD

## Approval Sign-off
| Role | Name | Date | Status |
|---|---|---|---|
| Product Owner |  |  | Pending |
| Technical Lead / Solution Architect | George Joseph | YYYY-MM-DD | Approved |
| Engineering Lead |  |  | Pending |
| Commercial / Operations |  |  | Pending |

## Document Lineage
- Supersedes: <doc/version or N/A>
- Superseded By: <doc/version or N/A>

## Change Log
- <version> (YYYY-MM-DD) - <what changed>

New major/minor versions must include a change log entry.
Approval status cannot be marked Approved without approver name and date.
If scope is legacy, footer must clearly identify active replacement document.

5. Mandatory Documentation Set

These document families must exist before production delivery:

PRD
HLD
LLD
API specification
Data model and retention
Security and threat model
DevOps and deployment strategy
Testing strategy
Project plan and risk register
Compliance and legal artifacts

Each document must follow the standard header/footer templates in this framework.

6. Living Maintenance Workflow

To keep this framework updated and alive:

Trigger events for framework review:

Major product model changes
Delivery model changes
New compliance obligations
Repeated document quality issues

Scheduled review:

Bi-weekly review by owner
Monthly governance checkpoint with Product + Engineering

Update protocol:

Increase framework version
Add change log line
Update updated and next_review_date
Announce updates in section READMEs where relevant

Quality checks to run after updates:

Broken markdown link check
superseded_by target check
Metadata completeness check for required frontmatter fields

7. Quality Gate Checklist for Any New Doc

Before a document is considered active:

YAML frontmatter present and complete
Scope/status/lifecycle values valid
related links resolve
superseded_by present for legacy docs
Document control block present
Governance footer present
Approval table updated for current state

8. Quick-Start Skeleton for New Documents

---
# Use canonical YAML header template from Section 3.1
---

<- [Section Index](../README.md) | [Master Index](../../INDEX.md)

# <Document Title>

## Document Control
- Project: FlyMax V2.0
- Version: 0.1.0
- Scope: Valid
- Status: Draft
- Author: George Joseph (YYYY-MM-DD)
- Modified By: <Name> (YYYY-MM-DD)
- Approved By: <Name> (YYYY-MM-DD)

## Purpose
<Why this document exists>

## Content
<Main content>

---

# Use canonical footer template from Section 4.1

9. Framework Change Log

2.0.0 (2026-03-09) - Rebuilt as living framework aligned to current v1.0/v2.0/v3.0 structure, semantic versioning, and mandatory header/footer governance.
1.0.0 (2026-02-25) - Initial mandatory documentation framework.

Final Governance Note

[!WARNING] Documents that do not follow this framework are not considered governance-complete and cannot be treated as authoritative for delivery or approval decisions.