ldpv2/doc/Analysis.md

LDPv2 - Requirements Analysis Document

1. Executive Summary

LDPv2 (Lifecycle Data Platform version 2) is a comprehensive application lifecycle management tool designed to manage and document all applications within a business unit. It serves as a central repository for application information, tracking deployments, dependencies, SLAs, and stakeholder relationships throughout the complete application lifecycle.

2. Purpose and Scope

2.1 Primary Objectives

• Provide a centralized documentation platform for all managed applications
• Track application lifecycle from ideation to decommissioning
• Manage deployment history across multiple environments
• Document and monitor external dependencies and data usage agreements
• Maintain SLA definitions and compliance tracking
• Facilitate stakeholder communication and responsibility mapping

2.2 Target Users

• Business Unit Directors and Program Managers
• Application Product Owners
• Development Teams
• Infrastructure and Operations Teams
• Compliance and Data Governance Officers

3. Technical Architecture

3.1 Technology Stack

3.1.1 Backend

• Framework: Spring Boot 3.x
• Security: Spring Security with JWT-based authentication
• Authentication Strategy:
  • Initial implementation: Local authentication (username/password)
  • Future evolution: OAuth 2.0 / OpenID Connect integration
• Authorization: Role-based access control (RBAC) with environment-specific permissions
• Persistence: PostgreSQL 16
• ORM: Hibernate 6.x (JPA implementation)
• API Style: RESTful API with JSON payloads

3.1.2 Frontend

• Framework: Angular 18
• Authentication: JWT token-based authentication
• HTTP Client: Angular HttpClient with interceptors for token management
• State Management: To be determined (NgRx, Signals, or service-based)
• UI Components: To be determined (Angular Material, PrimeNG, or custom)

3.1.3 Database

• RDBMS: PostgreSQL 16
• Schema Management: Liquibase or Flyway for database migrations
• Connection Pooling: HikariCP (Spring Boot default)

3.2 Security Architecture

3.2.1 Authentication Flow

1. User submits credentials to /api/auth/login
2. Backend validates credentials against database
3. Upon successful authentication, JWT token is generated and returned
4. Frontend stores JWT token (localStorage or sessionStorage)
5. Subsequent requests include JWT token in Authorization header
6. Backend validates token on each request via Spring Security filters

3.2.2 Authorization Model

• Environment-Based Roles: Users can have different permissions per environment
  • Example: User may have READ access to PROD but WRITE access to DEV
• Role Hierarchy: To be defined (e.g., ADMIN > MANAGER > USER > VIEWER)
• Resource-Level Permissions: Fine-grained access control on applications and business units

3.2.3 Future OAuth Integration

• Support for enterprise SSO (Single Sign-On)
• Integration with identity providers (Azure AD, Okta, Keycloak)
• Backward compatibility with local authentication during migration

3.3 API Design Principles

• RESTful resource-based endpoints (e.g., /api/applications, /api/deployments)
• Consistent HTTP verb usage (GET, POST, PUT, DELETE, PATCH)
• Pagination for list endpoints
• Filtering and sorting capabilities
• HATEOAS support for discoverability (optional)
• Versioned API (e.g., /api/v1/...)

3.4 Data Persistence Strategy

• Entity Mapping: JPA entities with Hibernate annotations
• Relationship Management: Appropriate use of @OneToMany, @ManyToOne, @ManyToMany
• Cascade Operations: Carefully configured cascade types to maintain referential integrity
• Lazy/Eager Loading: Optimized fetch strategies to prevent N+1 queries
• Auditing: Automatic timestamp management using @CreatedDate and @LastModifiedDate

4. Functional Requirements

4.1 Business Unit Management

Description: Organizations are structured around business units that own and manage applications.

Requirements:

• Each business unit must have a unique name
• Business units must maintain a list of associated contacts with specific roles (Director, Program Manager, etc.)
• Support for hierarchical contact management with role-based assignments

Data Model:

• Business Unit entity with name and metadata
• Many-to-many relationship with Contact entities
• Role specification for each business unit contact

API Endpoints:

• GET /api/business-units - List all business units
• GET /api/business-units/{id} - Get business unit details
• POST /api/business-units - Create new business unit
• PUT /api/business-units/{id} - Update business unit
• DELETE /api/business-units/{id} - Delete business unit
• GET /api/business-units/{id}/contacts - Get contacts for business unit

4.2 Application Management

Description: Applications are the core entities tracked within the system, representing software systems deployed across various environments.

Requirements:

4.2.1 Application Lifecycle Status

Applications must track their current status through the following states:

• IDEA: Initial concept phase, not yet in development
• IN_DEVELOPMENT: Active development in progress
• IN_SERVICE: Deployed and operational in production
• MAINTENANCE: Undergoing maintenance or limited support
• DECOMMISSIONED: Retired and no longer in use

Status transitions should be tracked with timestamps for audit purposes.

4.2.2 Multi-Environment Deployment

• Applications must support deployment across multiple environments
• Each deployment must be linked to a specific version of the application
• Complete deployment history must be maintained with timestamps
• Deployment tracking must record who deployed and when

4.2.3 Stakeholder Management

• Applications must maintain a list of contacts
• Each contact must be associated with a specific role (Product Owner, Functional Authority, Developer, Maintainer, etc.)
• Support for multiple stakeholders per role
• Contact information must include name, email, and phone number

4.2.4 Service Level Agreements

• Each application must be associated with an SLA definition
• SLA compliance must be trackable

4.2.5 Technical Documentation

• Applications must support multiple technical documentation references
• Each documentation entry must include:
  • Title
  • URL reference
  • Creation and update timestamps

4.2.6 Lifecycle Management

• End-of-life date tracking
• End-of-support date tracking
• Version-specific lifecycle information

4.2.7 External Dependencies

• Applications must be able to reference multiple external dependencies
• Dependencies can be of various types (detailed in section 4.4)

Data Model:

• Application entity with status tracking (enum: IDEA, IN_DEVELOPMENT, IN_SERVICE, MAINTENANCE, DECOMMISSIONED)
• Relationship to Business Unit (many-to-one)
• Relationship to SLA (optional, one-to-one)
• Relationship to Versions (one-to-many)
• Relationship to Contacts (many-to-many)
• Relationship to Technical Documentation (one-to-many)
• Relationship to External Dependencies (one-to-many)

API Endpoints:

• GET /api/applications - List applications (with filtering by status, business unit)
• GET /api/applications/{id} - Get application details
• POST /api/applications - Create new application
• PUT /api/applications/{id} - Update application
• PATCH /api/applications/{id}/status - Update application status
• DELETE /api/applications/{id} - Delete application
• GET /api/applications/{id}/versions - Get versions for application
• GET /api/applications/{id}/deployments - Get deployment history
• GET /api/applications/{id}/contacts - Get stakeholders
• GET /api/applications/{id}/dependencies - Get external dependencies

4.3 Version Management

Description: Each application release is tracked as a distinct version with specific attributes.

Requirements:

• Every deployed application must be linked to a specific version
• Version tracking must include:
  • Version Identifier: Semantic version or custom identifier (e.g., "1.2.3", "2024.Q1")
  • External Reference: Link to source control, ticketing system, or release notes
  • Release Date: When the version was officially released
  • End-of-Life Date: When support for this version ends
  • Creation Timestamp: When the version record was created

Data Model:

• Version entity linked to Application (many-to-one)
• Unique identifier and version metadata
• Lifecycle dates specific to the version
• Constraint: Version identifier must be unique within an application

API Endpoints:

• GET /api/applications/{appId}/versions - List versions for an application
• GET /api/versions/{id} - Get version details
• POST /api/applications/{appId}/versions - Create new version
• PUT /api/versions/{id} - Update version
• DELETE /api/versions/{id} - Delete version

4.4 External Dependencies Management

Description: Applications often rely on external data sources and services. These dependencies must be documented and tracked.

Requirements:

4.4.1 Dependency Types

External dependencies can be classified into the following types:

• WEB_SERVICE: REST APIs, SOAP services, microservices
• DATABASE: External database connections
• CERTIFICATE: SSL/TLS certificates, authentication certificates
• NETWORK_FLOW: Network connections, firewall rules, VPN tunnels

4.4.2 Dependency Documentation

Each external dependency must include:

• Name and type classification
• Descriptive documentation (free text)
• Technical documentation specific to the dependency
• Creation and update timestamps

4.4.3 Data Usage Agreements

• External dependencies must be linkable to one or more Data Usage Agreements
• This enables tracking of data governance and compliance requirements

Data Model:

• External Dependency entity with type enumeration
• Relationship to Application (many-to-one)
• Relationship to Data Usage Agreements (many-to-many)

API Endpoints:

• GET /api/applications/{appId}/dependencies - List dependencies for application
• GET /api/dependencies/{id} - Get dependency details
• POST /api/applications/{appId}/dependencies - Create new dependency
• PUT /api/dependencies/{id} - Update dependency
• DELETE /api/dependencies/{id} - Delete dependency
• GET /api/dependencies/{id}/agreements - Get data usage agreements for dependency

4.5 Data Usage Agreements

Description: Data Usage Agreements formalize the authorization to use external data sources and must be tracked for compliance purposes.

Requirements: Each Data Usage Agreement must contain:

• Data Nature: Description of the type of data covered by the agreement
• Documentation Link: Reference to the legal or formal agreement document
• Validity Start Date: When the agreement becomes effective
• Validity End Date: When the agreement expires (optional for indefinite agreements)
• Creation Timestamp: When the agreement record was created

Data Model:

• Data Usage Agreement entity with validity period
• Many-to-many relationship with External Dependencies

API Endpoints:

• GET /api/data-usage-agreements - List all agreements (with expiration filtering)
• GET /api/data-usage-agreements/{id} - Get agreement details
• POST /api/data-usage-agreements - Create new agreement
• PUT /api/data-usage-agreements/{id} - Update agreement
• DELETE /api/data-usage-agreements/{id} - Delete agreement

4.6 Environment Management

Description: Environments represent distinct deployment targets where applications can be installed. Unlike traditional fixed environment types, LDPv2 treats environments as flexible entities that can be created and configured as needed.

Requirements:

4.6.1 Environment as First-Class Entity

Each environment is a distinct entity with its own attributes and lifecycle. This allows for:

• Multiple production environments (e.g., PROD-EU, PROD-US, PROD-ASIA)
• Team-specific development environments (e.g., DEV-TeamAlpha, DEV-TeamBeta)
• Customer-specific environments
• Temporary or experimental environments

4.6.2 Environment Attributes

Each environment must be tracked with the following attributes:

• Name: Unique identifier for the environment (e.g., "PROD-EU", "INT-QA", "DEV-Mobile")
• Description: Optional free-text description of the environment's purpose
• Production Flag: Boolean indicator to identify production environments
• Criticality Level: Numeric rating (e.g., 1-5) to prioritize monitoring, incident response, and deployment approvals
  • Level 5: Critical production environments
  • Level 4: Important pre-production environments
  • Level 3: Integration and testing environments
  • Level 2: Development environments
  • Level 1: Experimental or temporary environments
• Timestamps: Creation and update tracking for audit purposes

4.6.3 Environment Flexibility

• Environments can be created, updated, and deactivated as needed
• No hard-coded list of environments in the application code
• Support for environment-specific security roles and permissions
• Environments can be organized or tagged for better management (future enhancement)

4.6.4 Environment-Based Access Control

• Users can have different permissions per environment
• Critical environments (high criticality level or production flag) may require additional approval workflows
• Deployment permissions should be configurable per environment

Data Model:

• Environment entity with flexible attributes
• No enumeration constraints on environment names
• Referenced by Deployment entity for tracking application versions
• Potential for environment grouping or categorization (future)

API Endpoints:

• GET /api/environments - List all environments (with filtering by production flag, criticality)
• GET /api/environments/{id} - Get environment details
• POST /api/environments - Create new environment
• PUT /api/environments/{id} - Update environment
• DELETE /api/environments/{id} - Deactivate/delete environment
• GET /api/environments/{id}/deployments - Get all deployments in this environment

Security Considerations:

• Creating or modifying production environments should require elevated privileges
• Environment deletion should be soft delete to preserve deployment history
• Audit logging for all environment changes

4.7 Deployment Tracking

Description: Deployments represent the installation of a specific application version to a specific environment.

Requirements:

4.7.1 Deployment Definition

A deployment is uniquely defined by the combination of:

• Application (which application)
• Version (which release)
• Environment (where it's deployed)

4.7.2 Deployment History

• Complete deployment history must be maintained (immutable records)
• Each deployment record must include:
  • Deployment timestamp
  • User or system that performed the deployment
  • Optional notes or comments
  • Creation timestamp for audit purposes

4.7.3 Current State Tracking

• The system must be able to identify the currently active version in each environment
• This is determined by the most recent deployment for a given application-environment combination
• A dedicated API endpoint should provide current deployment state

Data Model:

• Deployment entity with foreign keys to Application, Version, and Environment
• Timestamp-based ordering for historical tracking
• Business logic to determine "current" deployment (most recent by deployment date)

API Endpoints:

• GET /api/deployments - List all deployments (with filtering)
• GET /api/deployments/{id} - Get deployment details
• POST /api/deployments - Record new deployment
• GET /api/applications/{appId}/deployments/current - Get current deployments per environment
• GET /api/environments/{envId}/deployments/current - Get all current deployments in environment
• GET /api/deployments/history?applicationId={appId}&environmentId={envId} - Deployment history for app in env

Business Rules:

• Deployments are immutable once created (no updates, only new deployments)
• Deployment dates cannot be in the future
• Version must belong to the specified application

4.8 Contact and Stakeholder Management

Description: Contacts represent roles and responsibilities associated with applications, business units, and SLAs.

Requirements:

4.8.1 Contact Roles

The system must support various contact roles including but not limited to:

• Product Owner
• Functional Authority
• Developer
• Maintainer
• Technical Lead
• Business Analyst
• Director
• Program Manager

Roles should be configurable and extensible.

4.8.2 Contact Structure

A contact represents a functional role that can be associated with:

• One or more named individuals (persons)
• Multiple applications
• Business units
• SLAs

4.8.3 Person Information

Each person assigned to a contact must have:

• First name and last name
• Email address (required, unique)
• Phone number (optional)
• Primary contact designation (one person per contact should be marked as primary)

4.8.4 Contact Relationships

Contacts must be linkable to:

• Applications (with application-specific roles)
• Business Units (with organizational roles)
• SLAs (as responsible parties for service delivery)

Data Model:

• ContactRole entity defining available roles
• Contact entity representing the functional position
• Person entity with individual contact details
• Junction tables for Contact-Person, Application-Contact, BusinessUnit-Contact, and SLA-Contact relationships

API Endpoints:

• GET /api/contact-roles - List available contact roles
• GET /api/contacts - List all contacts
• GET /api/contacts/{id} - Get contact details with persons
• POST /api/contacts - Create new contact
• PUT /api/contacts/{id} - Update contact
• DELETE /api/contacts/{id} - Delete contact
• GET /api/persons - List all persons
• GET /api/persons/{id} - Get person details
• POST /api/persons - Create new person
• PUT /api/persons/{id} - Update person

4.9 Service Level Agreement (SLA) Management

Description: SLAs define the expected service levels, maintenance windows, and responsibilities for applications.

Requirements:

4.9.1 Core SLA Metrics

Each SLA must define:

• Availability Percentage: Expected uptime (e.g., 99.9%)
• Minimum Average Response Time: Expected response time in seconds
• Reaction Time: Time to respond to incidents (as text description)

4.9.2 Maintenance Windows

• SLAs must support multiple maintenance windows
• Each maintenance window must specify:
  • Day of the week (MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY)
  • Start time (HH:MM format)
  • End time (HH:MM format)
• Multiple maintenance windows can be defined for the same SLA

4.9.3 Critical Periods

• SLAs must track critical periods when higher service levels are required
• Each critical period must include:
  • Start datetime
  • End datetime
  • Duration in minutes
  • Optional description

4.9.4 SLA Documentation

• Diagram: Support for storing draw.io diagrams in JSON format showing system architecture and dependencies
• Dependencies Description: Free-text description of system dependencies
• Responsibility Scope: Clear definition of what is and isn't covered by the SLA

4.9.5 SLA Contacts

• Multiple contacts must be assignable to each SLA
• These represent the responsible parties for maintaining service levels

Data Model:

• SLA entity with metrics and documentation
• MaintenanceWindow entity (one-to-many from SLA)
• CriticalPeriod entity (one-to-many from SLA)
• SLA-Contact junction table (many-to-many)

API Endpoints:

• GET /api/slas - List all SLAs
• GET /api/slas/{id} - Get SLA details
• POST /api/slas - Create new SLA
• PUT /api/slas/{id} - Update SLA
• DELETE /api/slas/{id} - Delete SLA
• GET /api/slas/{id}/maintenance-windows - Get maintenance windows
• POST /api/slas/{id}/maintenance-windows - Add maintenance window
• GET /api/slas/{id}/critical-periods - Get critical periods
• POST /api/slas/{id}/critical-periods - Add critical period

5. Data Model Summary

5.1 Core Entities

1. BusinessUnit: Organizational container for applications
2. Application: Central entity representing software systems
3. Version: Releases of applications
4. Environment: Flexible deployment targets with custom names and attributes
5. Deployment: Records of version deployments to environments
6. Person: Individual stakeholders
7. ContactRole: Predefined roles for stakeholders
8. Contact: Functional positions held by persons
9. TechnicalDocumentation: Links to technical resources
10. ExternalDependency: External services and data sources
11. DataUsageAgreement: Legal agreements for data usage
12. SLA: Service level agreement definitions
13. MaintenanceWindow: Scheduled maintenance periods
14. CriticalPeriod: High-priority time windows

5.2 Relationship Summary

• BusinessUnit → Application (1:N)
• Application → Version (1:N)
• Application + Version + Environment → Deployment (unique combination)
• Application ↔ Contact (N:N)
• Application → ExternalDependency (1:N)
• Application → TechnicalDocumentation (1:N)
• Application → SLA (1:1, optional)
• ExternalDependency ↔ DataUsageAgreement (N:N)
• Contact ↔ Person (N:N)
• SLA → MaintenanceWindow (1:N)
• SLA → CriticalPeriod (1:N)
• SLA ↔ Contact (N:N)

5.3 Database Schema Considerations

• All primary keys: UUID type
• Foreign keys with appropriate CASCADE/RESTRICT rules
• Indexes on frequently queried fields (application status, environment production flag, deployment dates)
• Unique constraints where applicable (email in Person, environment name)
• Audit columns (createdAt, updatedAt) on all entities using JPA auditing

6. Non-Functional Requirements

6.1 Performance

• API response time < 500ms for 95% of requests
• Support for pagination on all list endpoints (default page size: 20)
• Efficient query optimization to prevent N+1 problems
• Database connection pooling (HikariCP)
• Caching strategy for reference data (contact roles, environments)

6.2 Security

• JWT token expiration: 1 hour (configurable)
• Refresh token mechanism for session extension
• Password hashing: BCrypt with appropriate work factor
• HTTPS only in production
• CORS configuration for frontend origin
• SQL injection prevention via parameterized queries (JPA)
• XSS protection via Angular sanitization
• CSRF protection via Spring Security

6.3 Audit and Compliance

• All entities must track creation and update timestamps
• Deployment history must be immutable for audit purposes
• Data Usage Agreement expiration must be trackable
• User actions should be logged (who did what, when)
• Database audit trail for sensitive operations

6.4 Data Integrity

• Foreign key constraints enforced at database level
• Validation annotations on JPA entities (@NotNull, @Size, @Email, etc.)
• Business rule validation in service layer
• Transaction management for complex operations
• Soft delete for critical entities to preserve referential integrity

6.5 Scalability

• The system must support hundreds of applications
• Deployment history may grow to thousands of records per application
• Efficient querying of current deployment states is critical
• Database indexing strategy for performance
• Potential for read replicas if query load increases

6.6 Maintainability

• Clean separation of concerns (Controller → Service → Repository)
• DTOs for API layer to decouple from entity model
• MapStruct or ModelMapper for DTO conversion
• Comprehensive API documentation (Swagger/OpenAPI)
• Unit tests (JUnit 5, Mockito) with >80% code coverage
• Integration tests for critical workflows
• Docker containerization for consistent deployments

6.7 Usability

• Intuitive Angular UI with responsive design
• Clear error messages and validation feedback
• Loading indicators for async operations
• Confirmation dialogs for destructive actions
• Keyboard navigation support
• Accessibility compliance (WCAG 2.1 Level AA)

7. Implementation Phases

7.1 Phase 1: Core Foundation (MVP)

• Database schema creation with Liquibase/Flyway
• JPA entity model implementation
• Spring Security with local authentication
• JWT token generation and validation
• Basic CRUD APIs for:
  • BusinessUnit
  • Application (with status tracking)
  • Environment
  • Contact and Person
• Angular authentication module
• Basic application listing and detail views

7.2 Phase 2: Deployment Tracking

• Version entity and APIs
• Deployment entity and APIs
• Deployment history tracking
• Current deployment state queries
• Angular deployment management interface
• Deployment timeline visualization

7.3 Phase 3: Dependencies and Compliance

• External Dependency entity and APIs
• Data Usage Agreement entity and APIs
• Dependency-Agreement linkage
• Technical Documentation management
• Angular forms for dependency tracking
• Expiration alerts for agreements

7.4 Phase 4: SLA Management

• SLA entity and APIs
• Maintenance Window management
• Critical Period tracking
• SLA-Contact relationships
• Draw.io diagram storage and display
• Angular SLA management interface

7.5 Phase 5: Advanced Features

• Environment-based role permissions
• OAuth 2.0 integration
• Advanced search and filtering
• Dashboard and analytics
• Reporting capabilities
• Notification system
• API rate limiting

8. Testing Strategy

8.1 Backend Testing

• Unit Tests: Service layer business logic (JUnit 5, Mockito)
• Integration Tests: Repository layer with test database (Testcontainers)
• API Tests: Controller endpoints (MockMvc, REST Assured)
• Security Tests: Authentication and authorization flows
• Performance Tests: Load testing for critical endpoints (JMeter, Gatling)

8.2 Frontend Testing

• Unit Tests: Angular components and services (Jasmine, Karma)
• Integration Tests: Component interaction and routing
• E2E Tests: Critical user workflows (Cypress, Playwright)
• Accessibility Tests: WCAG compliance checking

8.3 Test Coverage Goals

• Backend code coverage: >80%
• Frontend code coverage: >70%
• Critical path E2E coverage: 100%

9. Deployment Architecture

9.1 Development Environment

• Local PostgreSQL instance via Docker
• Spring Boot running on port 8080
• Angular dev server on port 4200
• Hot reload enabled for both frontend and backend

9.2 Production Environment

• Containerized deployment (Docker/Kubernetes)
• PostgreSQL cluster with replication
• Load balancer for backend instances
• CDN for frontend static assets
• Separate database for each environment (dev, test, prod)
• Automated backup strategy

9.3 CI/CD Pipeline

• Source control: Git (GitHub, GitLab, or Bitbucket)
• Build automation: Maven for backend, npm for frontend
• Continuous Integration: Jenkins, GitLab CI, or GitHub Actions
• Automated testing in pipeline
• Docker image building and publishing
• Automated deployment to test environments
• Manual approval for production deployment

10. Documentation Requirements

10.1 Technical Documentation

• API documentation (Swagger/OpenAPI specification)
• Database schema documentation (ER diagrams)
• Architecture decision records (ADRs)
• Deployment and configuration guides
• Security best practices guide

10.2 User Documentation

• User manual for each user role
• Quick start guide
• Video tutorials for common workflows
• FAQ section
• Troubleshooting guide

11. Future Considerations

11.1 Potential Enhancements

• Integration with CI/CD pipelines for automatic deployment recording
• Automated SLA compliance monitoring and alerting
• Dashboard views for application portfolio management
• Notification system for expiring Data Usage Agreements
• Advanced reporting and analytics
• Mobile application for on-the-go access
• Webhook support for external integrations
• GraphQL API as alternative to REST
• Elasticsearch integration for advanced search
• Audit log viewer with filtering

11.2 Reporting Requirements

• Application inventory reports by status
• Deployment frequency analytics
• Environment utilization reports
• SLA compliance reporting
• Dependency mapping and impact analysis
• End-of-life planning reports
• Data usage agreement expiration forecasts
• Stakeholder contact directory

12. Success Criteria

The LDPv2 system will be considered successful when:

1. All applications within the business unit are accurately documented
2. Deployment history is complete and traceable across all environments
3. Stakeholders can easily identify current application states and ownership
4. Compliance officers can track data usage agreements effectively
5. SLA definitions are clearly documented and accessible
6. The system serves as the single source of truth for application lifecycle data
7. Users can perform all core functions without training (intuitive UI)
8. System uptime > 99.5%
9. User satisfaction score > 4.0/5.0

---

Document Version: 2.0
Last Updated: February 2026
Status: Technical Specification - Ready for Development
Prepared By: Laurent
Review Date: To be scheduled