Tenant Lifecycle

Andi Lamprecht ·2026-05-11· 13 min read· Draft

Clarify the Tenant Lifecycle

Building a multi-tenant platform for DroneUp introduces new requirements for how Operators, agents, and teams interact within a shared environment. Operators must be able to grant controlled access to their certifications and authorizations while maintaining separation between distinct teams or operational units. To ensure we design this correctly, we first need to define the Tenant Lifecycle — the end-to-end process governing how tenants are created, initialized, and managed across the platform.

Creation

Overview

DroneUp, as the Platform Administrator, will hold exclusive authority to create new Tenants within the Uncrew ecosystem. This approach ensures that platform growth and external onboarding remain controlled, auditable, and compliant with DroneUp’s certification and data-governance standards.

Over time, as the platform matures, the responsibility and tooling for tenant creation may expand to include new administrative layers or automated provisioning flows. The intent of this evolution is to balance control, scalability, and customer self-service — without compromising the integrity or security of the overall system.

Lifecycle Milestones

Discussion Points (for CCB / Architecture Review)

• Should sub-tenant creation always require approval or policy enforcement by the parent tenant?
• At what point does recursive tenancy (sub-tenant of a sub-tenant) introduce excessive complexity or risk?
• What audit and approval workflows are required for automated provisioning?
• How will tenant ID namespaces and lifecycle states (Pending → Active → Archived) be managed?

Initialization

Initialization is about what happens immediately after creation — i.e., what gets automatically provisioned, registered, or inherited so that a new Tenant becomes operationally ready.

Purpose

The Initialization phase defines the standard set of configurations, data linkages, permissions, and service bindings that must occur when a new Tenant is created, ensuring it is ready to operate within the Uncrew ecosystem.

Initialization ensures consistency, compliance, and governance alignment across all Tenants — while allowing for future customization and extensibility.

Key Items to Consider for Initialization

Below are the categories and examples of what should be initialized for every new Tenant. This is not a definition, nor do we state how they are done yet; this is a guideline for topics to discuss and include.

1. Identity and Access Setup

• Tenant ID Assignment: Generate a globally unique Tenant ID or namespace.
• Default Roles & Permissions: Automatically create default roles (e.g., Tenant Admin, Operator, Viewer).
• Admin User Initialization: Create or link the first administrative user (the “Tenant Owner”).
• Authentication Context: Establish IAM integration rules — e.g., use of DroneUp identity provider or federated login.

Outcome: The Tenant can be securely accessed and managed by authorized users.

2. Configuration and Policy Baselines

• Configuration Template: Apply a baseline configuration derived from a “Tenant Configuration Template” managed by DroneUp.
• Parameter Inheritance: Inherit global configurations (e.g., safety limits, compliance parameters) with tenant-level overrides allowed where applicable.
• Version Pinning: Assign a supported version of the platform (per Operator or OEM certification lifecycle).
• Policy Registration: Apply default operational policies — e.g., flight approval flow, asset assignment rules.

Outcome: Each Tenant starts from a compliant, auditable configuration baseline.

3. Data and Service Linkage

• Shared Service Bindings: Register connections to shared platform services such as:
  • UTM provider
  • Data lake and observability platforms
  • Central audit logging
• Tenant Data Namespace: Create a new schema or namespace for all tenant-owned data (missions, assets, users, logs).
• Dataset Registration: Link the Tenant to required datasets (e.g., airspace data, base maps, weather feeds).
• Exception Framework: Initialize a registry to track any data overrides or exceptions the tenant may introduce later.

Outcome: The Tenant is functionally connected to platform-level systems while remaining data-isolated.

4. Operational Entities

• Default Operational Area (AOO or Site): Optionally create a default operational zone or placeholder site for mission testing, for onboarding.
• Fleet / Asset Registry Placeholder: Initialize an empty fleet record so that aircraft and equipment can be registered later.
• Delivery / Mission Console Access: Create logical links between Tenant ID and downstream operational tools.

Outcome: The Tenant can be populated with operational content immediately after onboarding.

5. Observability and Compliance

• Telemetry / Log Routing: Register a tenant-specific namespace for observability tools.
• Audit Log Registration: Begin logging all administrative and operational actions tied to the Tenant ID.
• Compliance Flags: Apply compliance tags (e.g., Part 135, Part 107, or OEM-specific certification type).

Outcome: Every Tenant has a defined compliance footprint and traceable activity trail from day one.

6. Communication and Metadata

• Contact Registry: Capture organizational metadata — name, contact info, address, support escalation contacts.
• Notification Channels: Register default alerting and communication preferences (email, webhook, Slack integration).
• Terms & Agreements Acknowledgment: Record acceptance of terms, SLAs, and data policies for the tenant.

Outcome: The Tenant has complete administrative metadata for lifecycle tracking and compliance.

7. Governance Hooks

• Change Control Association: Link the Tenant to the platform’s CCB or governance framework for version management.
• Lifecycle State Initialization: Default state set to Pending Activation → Active upon admin validation.
• RACI Alignment: Assign DroneUp roles responsible for oversight, review, and support of the tenant.

Outcome: Each Tenant is onboarded with clear governance boundaries and visibility.

8. Future Considerations

• Introduce Initialization Templates per Tenant Type (e.g., Operator vs OEM).
• Automate initialization through a Tenant Provisioning API.
• Enable Tenant Cloning (copy configuration from an existing tenant).
• Allow Custom Initialization Scripts governed by DroneUp Admin.

Clarification: “Delivery / Mission Console Access”

When we refer to “Create logical links between Tenant ID and downstream operational tools”, the intent is not to define an implementation or API pattern — it’s to define the conceptual integration between a Tenant and the operational subsystems that perform missions, deliveries, or inspections.

Delivery / Mission Console Access

Each Tenant must be logically connected to the operational systems that support mission execution and workflows. This connection ensures that all mission data, events, and asset activities are properly associated with the Tenant’s unique ID and configuration.

Purpose:

• Enforce data isolation for missions and deliveries.
• Ensure traceability of flight and delivery activities to the correct Tenant and Operator.
• Allow tenant-based control over operations (e.g., mission approval, flight release, delivery tracking).

Example Concept:

When a mission is created in Mission Console, the system references the Tenant ID from the authenticated Operator account, ensuring all associated flight plans, telemetry, and delivery events are scoped to that tenant and excluded from others.

Operation

Purpose

The Operation phase defines how a Tenant functions once initialized — how it manages users, missions, assets, configurations, and compliance across time. This phase represents the active lifecycle of a Tenant: operating, collaborating, evolving, and maintaining regulatory compliance within the Uncrew platform.

Concept Overview

Once a Tenant is active, it transitions from a static configuration to a living operational entity.

During this phase:

• The Tenant interacts with shared services (e.g., UTM, Dataset Registry, Observability).
• The Tenant creates and manages subordinate structures such as Users, Assets, and Missions.
• Configurations evolve, versions are upgraded or pinned, and operational control is exercised according to certification rules.
• Data flows are tenant-scoped and auditable across Uncrew.

Core Operational Dimensions

1. User and Access Management

• Role Administration: Tenant Admins manage their own users and assign roles (Admin, Supervisor, RPIC, Viewer, etc.).
• Access Scopes: All user actions are constrained to the tenant (and sub-tenants, if applicable).
• Cross-Tenant Collaboration (Optional): Limited sharing or delegation may be permitted through explicit agreements or shared workspaces.

Outcome: Tenants maintain internal autonomy while remaining within platform-wide governance boundaries.

2. Mission and Delivery Operations

• Mission Creation & Control: All mission planning, execution, and flight releases occur within the tenant context. Operators retain approval authority over their Agents and missions.
• Delivery Workflows: All delivery or ISR activities initiated are scoped by Tenant ID.
• Data Association: Telemetry, mission outcomes, and audit logs are recorded under the tenant’s namespace.

Outcome: Flight and delivery operations are isolated, traceable, and compliant.

3. Configuration and Version Management

• Configuration Control: Tenants can modify approved parameters within their configuration scope, subject to version control and validation.
• Version Pinning: Each tenant may run a fixed product version aligned with their certification lifecycle (e.g., Part 135 vs Part 107).
• Upgrade Path Management: DroneUp Admins define supported versions and schedule tenant migrations or deprecations.

Outcome: Operational stability with controlled evolution over time.

4. Data Management and Authoritative Sources

• Dataset Synchronization: Tenants consume shared authoritative datasets (e.g., UTM airspace data, obstacle maps) but can add or override data when required.
• Data Contribution: Tenants may contribute validated data back to DroneUp’s central services (e.g., new geospatial layers, updated obstacle data).
• Exception Tracking: All temporary or tenant-supplied data overrides are logged for review and resolution.

Outcome: A federated yet consistent data ecosystem, with built-in integrity checks.

5. Compliance and Operational Control

• Regulatory Oversight: Operators maintain command authority over all Agent missions executed under their certification.
• Flight Release Mechanisms: The platform enforces Operator approval for mission releases, ensuring compliance with operational control requirements.
• Audit Logging: Every operational action (e.g., configuration changes, mission creation, flight completion) is recorded with tenant context.

Outcome: Continuous compliance assurance and transparent traceability.

6. Shared Service Utilization

• UTM and ADS-B Integration: Tenants interact with global DroneUp services for traffic management and airspace conformance.
• Observability and Analytics: Each tenant’s telemetry and metrics are isolated within its own namespace but visible in aggregate for DroneUp monitoring.
• Support and Maintenance: DroneUp Admin Org oversees global service health and assists tenants through defined support channels.

Outcome: Tenants gain the benefits of shared infrastructure without losing isolation or control.

7. Sub-Tenant and Delegated Management

• Parent-Child Hierarchies: Parent tenants (Operators, OEMs) can administer sub-tenants such as regional teams, partners, or contractors.
• Delegated Authority: Permissions and responsibilities can cascade down according to defined governance models.
• Boundary Enforcement: Data segregation and operational approval rules prevent unauthorized visibility or action between sub-tenants.

Outcome: Supports complex organizational structures while preserving security and traceability.

8. Observability and Health Monitoring

• Operational Dashboards: Tenants have visibility into their own performance metrics — mission success rates, exception frequency, data freshness.
• Global Oversight: DroneUp Admin Org monitors tenant activity for anomalies, ensuring compliance and uptime across the ecosystem.
• Alerts and Notifications: Tenants receive real-time alerts for operational events, system issues, or version updates.

Outcome: Continuous visibility and proactive issue management.

Future Considerations

• Automation of tenant health checks and SLA compliance.
• Cross-tenant analytics for system-wide trend identification.
• Expansion of sub-tenant collaboration frameworks (shared missions or datasets).
• Introduction of a Tenant Operations API for programmatic control and integration.
• We need a strategy for handling UAV version compatibility. How will we ensure all UAVs in a fleet run versions that work together, and what is the policy for vehicles that cannot upgrade to supported versions?

Deprecation / Sunset

Purpose

The Deprecation / Sunset phase defines how a Tenant is formally retired from the Uncrew ecosystem. This process ensures that tenant data, configurations, and access are securely archived, traceable, and compliant with regulatory and contractual requirements, while minimizing operational disruption to other tenants and shared services.

The objective is to maintain system integrity and data governance even as Tenants (Operators, OEMs, or sub-tenants) conclude their use of the platform.

Concept Overview

Tenants may be deprecated for several reasons: voluntary offboarding, contractual expiration, consolidation under another tenant, or compliance breaches. Regardless of cause, the process must be controlled, auditable, and reversible (within a defined retention window).

Deprecation transitions a Tenant through clearly defined lifecycle states (e.g., Active → Suspended → Deprecated → Archived). Throughout this process, DroneUp as the Platform Administrator maintains oversight and authority to ensure:

• Data retention policies are respected.
• Shared services remain unaffected.
• Regulatory obligations (e.g., flight record retention) are fulfilled.

Lifecycle States

Outcome: Consistent, auditable control over the full lifecycle of tenant existence within the Uncrew ecosystem.

Core Deprecation Activities

1. Administrative Initiation

• Deprecation is initiated only by DroneUp Platform Administrators or through approved governance workflows (e.g., PCCB authorization).
• All deprecation requests are logged, including rationale, initiator, and effective date.
• Optional: Notify affected sub-tenants and associated users before deactivation.

Outcome: Clear governance chain and accountability.

2. Data and Configuration Freeze

• Tenant’s operational capabilities are halted — no new missions, assets, or configurations can be created.
• All datasets, mission records, logs, and configuration versions are frozen in place.
• Shared services disconnect any live streams, telemetry, or delivery endpoints for the tenant.
• The Tenant ID remains reserved to prevent conflicts during retention.

Outcome: Guarantees immutability of records during deprecation.

3. Data Retention and Export

• Define retention periods based on tenant type or regulatory requirement (e.g., FAA, DoD, or OEM compliance).
• Allow controlled export of tenant data (missions, logs, configurations) in approved formats, if contractually permitted.
• Enforce encryption at rest for all archived data; associate with a retention policy metadata record (owner, duration, destruction date).
• Shared datasets contributed by the tenant remain available to DroneUp but marked as inactive source.

Outcome: Retained compliance and recoverability without risk of data contamination.

4. Access and Credential Revocation

• All user accounts associated with the tenant are deactivated.
• API tokens, keys, and service credentials are revoked or expire automatically.
• SSO or federated access links (if applicable) are disabled.
• Optionally, Tenant Admins receive final access to download audit logs.

Outcome: Eliminates risk of unauthorized post-deprecation access.

5. Observability and Compliance Archival

• Final audit report generated — includes user actions, version history, and operational metrics.
• Observability data (telemetry, alerts, performance metrics) is archived in a read-only state for future compliance inquiries.
• All deprecation events are logged within DroneUp’s platform-level audit trail.

Outcome: Preservation of a complete compliance snapshot.

6. Final Archive and Data Destruction

• Once retention expires, data is securely destroyed per DroneUp’s data governance and compliance policies.
• A cryptographic checksum or “proof-of-deletion” record is retained to verify destruction.
• Tenant ID may be released or reserved for reuse, depending on platform policy.

Outcome: Clean data hygiene and defensible lifecycle closure.

Governance and Oversight

• The DroneUp Administration Organization oversees all tenant deprecation and archival workflows.
• All actions require at least dual authorization (initiator and approver).
• CCB and Audit teams receive automated reports summarizing deprecation events and their compliance outcomes.
• Platform metrics track deprecation trends for capacity planning and ecosystem insights.

Future Considerations

• Automate the Deprecation Workflow via the Tenant Management Service (e.g., lifecycle API with policy enforcement).
• Introduce “Grace Period” Reinstatement (e.g., reinstating a tenant within 30 days if closure was premature).
• Enable multi-tenant archiving dashboards for DroneUp Admin Org to visualize lifecycle health.
• Support tenant-level retention rules configurable by Operator or OEM type.

Summary

The Deprecation / Sunset phase is as critical as creation — it safeguards DroneUp’s regulatory posture, prevents data sprawl, and preserves the integrity of the Uncrew ecosystem.

By treating tenant deprecation as a governed lifecycle event, the platform ensures that operational independence and compliance obligations are upheld even after a tenant’s active participation ends.