Customer (Marc): Thanks for joining. We’re building an accounting system for a space travel agency. High level: we need to account for rockets, capsules, engines, and other reusable assets. Depreciation must work not only by time but also by uses — launches, flight hours, engine burns. I want to capture mission costs per launch and have depreciation driven by those launch events. Can you help define requirements?

System Designer: Absolutely. I’ll capture goals and constraints as we go. First, confirm scope: do you want a single system to handle GL posting, asset register, telemetry ingestion, maintenance integration, and mission costing — or will some of those remain in other systems and just feed accounting?

Customer: We’ll keep ops and telemetry in separate systems (flight ops, CMMS), but they must feed the accounting system. Accounting must be the source of truth for financials and audit packs. Ops will send usage events and maintenance orders.

System Designer: Good. I’ll treat telemetry and CMMS as external sources with APIs or batch feeds. Key functional areas I’ll capture: asset master & componentisation, usage event ingestion, launch event grouping, usage‑based amortization, refurbishment capitalisation rules, approval workflows, GL posting & traceability, and reporting/audit pack. Anything to add?

Customer: Add idempotency for telemetry (no double‑posting), and a UI for finance to preview accounting entries before posting. Also need allocation rules to split shared costs across missions and customers.

System Designer: Noted. Let’s define the asset model. Each physical unit will be an AssetInstance with unique ID and attributes: serial number, acquisition cost, acquisition date, depreciation method, useful life in years, useful life in uses, salvage value, current state, and links to parent/child components. Components (engines, heat shields) are tracked as separate records. Does that match your needs?

Customer: Yes. We need component histories — when an engine is swapped, the old engine must be derecognized and the new one capitalized. Also track spare parts inventory.

System Designer: Understood. For usage metrics, we’ll support multiple counters per asset: launch count, flight hours, engine burns, thermal cycles, and time in service. Telemetry events will map to these counters. We’ll store both cumulative counters and event‑level records for traceability. Is there a preferred telemetry source format or vendor?

Customer: Ops uses a telemetry platform that can export JSON batches and also push events. We’ll provide an API spec later. For now, assume batched JSON with unique telemetry IDs.

System Designer: Perfect. Business rules for depreciation: support time‑based methods (straight‑line, declining) and usage‑based (units‑of‑production). Also support hybrid rules such as “amortize by the lesser of time or uses” or “switch to usage method after first launch.” Finance must be able to configure these rules per asset class. Acceptable?

Customer: Yes. Also: when refurbishment occurs, we sometimes capitalise the overhaul and extend useful life. We need configurable thresholds (cost or % life extension) to decide capitalisation vs expense.

System Designer: We’ll add a RefurbishmentCandidate workflow: CMMS posts an overhaul estimate, the system creates a candidate, finance approves or rejects, and if approved we capitalise and recalc remaining useful life or TotalEstimatedUses. We’ll capture before/after snapshots and supporting documents. Who approves capitalisation today?

Customer: Controller approves anything over $250k; below that, the asset manager can approve.

System Designer: We’ll model an approval matrix by cost bands and asset class. Next: LaunchEvent concept. Each launch groups multiple assets (first stage, second stage, capsule, payload, ground support). A LaunchEvent record will store mission metadata, scheduled/actual times, participating AssetInstances with roles, pre/post snapshots, and linked UsageEvents. On event close we compute UsageDelta per asset and post usage‑based amortization journals. Does that align?

Customer: Exactly. We also need to capture direct mission costs (fuel, ground support, third‑party services) and allocate them to the mission and to assets where appropriate.

System Designer: We’ll include LaunchCostLine entries for direct costs and LaunchDepreciationPosting entries for asset consumption. Allocation rules will let you split shared costs by weight, usage share, or fixed percentages. Journals will reference LaunchEventID and AssetIDs for traceability. Auditors must be able to drill from GL to LaunchEvent to UsageEvent to telemetry and approvals. Is that mandatory?

Customer: Mandatory. Auditors will want the full chain and attachments.

System Designer: On telemetry ingestion: we’ll require a unique telemetry reference and checksum per UsageEvent. The ingestion API will accept batched UsageEvents with LaunchEventRef, AssetSerial, EventType, Timestamp, Units, TelemetryRef, and Checksum. The system will enforce idempotency and provide reconciliation reports for unmatched telemetry. Does that fit your ops workflow?

Customer: Yes. Also, sometimes telemetry is missing for older missions. We need a manual entry path with required evidence and finance approval.

System Designer: We’ll support manual UsageEvent creation with mandatory justification and attachments; those entries will be flagged and require approval before posting. Now, on GL posting: do you have an ERP in place?

Customer: We use Microsoft Dynamics Business Central for GL and invoicing.

System Designer: Great — we’ll design a bi‑directional sync: asset master and depreciation schedules flow to BC, and vendor invoices/payments flow back. Journal posting will be batched to BC with references to LaunchEventID and UsageEventIDs. We’ll include retry logic and dead‑letter handling for failed posts. Any constraints on posting frequency?

Customer: Daily batch is fine for depreciation and costs; urgent adjustments can be posted ad‑hoc.

System Designer: Noted. Reporting: we’ll provide asset register, per‑asset depreciation schedules (time and usage), launch cost rollups, mission profitability, refurbishment ROI, and an audit pack generator that bundles GL journals, usage events, telemetry refs, approvals, and documents. Do you need Excel exports and scheduled reports?

Customer: Yes — scheduled PDF and Excel exports for month‑end and audit packs.

System Designer: Security and compliance: role‑based access, encryption in transit and at rest, immutable audit logs for approvals and postings, and data residency options. Also retention and purge policies for PII and financial records. Any regulatory frameworks to align with?

Customer: GAAP for accounting; we may need IFRS later for international reporting. Also SOC2 readiness is a goal.

System Designer: We’ll design controls and logging to support SOC2 and produce a security controls matrix. Migration: we’ll import legacy asset masters and summarized cumulative counters where telemetry history is missing. We’ll run a parallel pilot for one rocket family for one reporting cycle before cutover. Is that acceptable?

Customer: Yes. For acceptance, finance must validate depreciation schedules and auditors must be able to trace at least three closed LaunchEvents end‑to‑end.

System Designer: Acceptance criteria captured. A few technical non‑functional items: event ingestion must handle telemetry bursts (specify expected peak events/min), overnight depreciation recalculation must complete within your reporting window, and the system must scale horizontally. Can you provide expected fleet size and peak telemetry volume?

Customer: Start with 20 active vehicles and expect up to 5,000 telemetry events per minute during test campaigns. Fleet may grow to 200 over three years.

System Designer: That gives us targets for throughput and batch windows. Next, UX: we’ll build a Launch Event Builder (select assets, preview pre/post snapshots, attach telemetry), an Accounting Preview screen (preview journals before posting), and an Approval Console for refurbishment and manual adjustments. Ops needs a lightweight view to propose events; finance needs the final sign‑off. Any preferences for UI roles?

Customer: Ops should be able to propose and attach telemetry; finance must approve and post. Auditors get read‑only access to closed events and audit packs.

System Designer: Good. Finally, deliverables I’ll produce next: (1) prioritized requirements document with acceptance tests, (2) LaunchEvent data model DDL, (3) sequence diagrams for telemetry → LaunchEvent → depreciation posting → GL posting, and (4) sample journal templates for usage amortization and refurbishment capitalisation. Which should I deliver first?

Customer: Start with the prioritized requirements and the LaunchEvent data model. Also include sample journal entries for a launch with three assets.

System Designer: I’ll prepare those. One last question for the requirements: do you want depreciation postings to be automatic on event close, or should finance always review the accounting preview and manually trigger posting?

Customer: Default to automatic posting on event close for routine launches, but require manual review for any manual adjustments, missing telemetry, or capitalisation decisions. Also, send a notification to finance when thresholds are crossed.

System Designer: Understood — automatic by default with configurable exceptions and notifications. I’ll include that in the workflow and the approval matrix. I’ll start drafting the prioritized requirements and the data model and share them for review by end of day tomorrow.

Customer: Perfect. Thanks — looking forward to the draft.

Functional Requirements Document Overview

Purpose: Define the functional requirements that will drive the detailed functional design for the accounting system and Launch Event subsystem for a space travel agency. These requirements focus on grouping assets into LaunchEvents, capturing usage, computing usage‑based and time‑based amortization, handling refurbishment capitalisation, and producing auditable GL postings and mission costing.

1. Launch Event Management

1.1 Create LaunchEvent

• Description: Allow Ops to create a LaunchEvent record that groups multiple AssetInstances and captures mission metadata.
• Inputs: MissionName, MissionType, ScheduledStart, LaunchSite, CustomerID, ContractID, participating AssetIDs with roles, initial cost estimates, allocation keys.
• Outputs: LaunchEventID, pre‑launch snapshots for each asset, event status Draft.
• Triggers: Manual create by Ops or import from mission planning system.
• Validations: All AssetIDs must exist and be in a valid pre‑launch state; required fields present.
• Acceptance: LaunchEvent created with unique ID and pre‑launch snapshots stored.

1.2 LaunchEvent Lifecycle and Status Transitions

• Description: Support statuses Draft → Confirmed → In Progress → Recovered → Closed → Audited with role‑based transitions.
• Inputs/Actions: Confirm, Start, Mark Recovered, Close, Audit Sign‑off.
• Outputs: Status change logs, timestamps, user IDs, audit trail.
• Validations: Only authorized roles can transition to certain statuses; cannot close without required evidence.
• Acceptance: Status transitions enforce RBAC and produce immutable audit entries.

1.3 Attach and Manage Participating Assets

• Description: Attach AssetInstances and AssetComponents to a LaunchEvent with role, quantity, and configuration snapshot.
• Inputs: AssetID, Role (primary, payload, ground support), PreLaunchUses, PreLaunchHours, Component list.
• Outputs: LaunchEventAssetLink records with pre‑launch snapshot.
• Validations: Prevent duplicate attachments; ensure component compatibility.
• Acceptance: Each attached asset has a stored pre‑launch snapshot and role.

2. Usage Event Ingestion and Processing

2.1 Telemetry Ingestion API

• Description: Accept batched UsageEvents from telemetry with idempotency and checksum.
• API Contract: Payload fields: LaunchEventRef, AssetSerial, EventType, Timestamp, Units, TelemetryRef, Checksum, IdempotencyToken.
• Processing: Validate checksum, deduplicate by TelemetryRef/IdempotencyToken, persist UsageEvent, update cumulative counters.
• Error Handling: Return per‑record status; route failures to DLQ with reason.
• Acceptance: System ingests batches, rejects duplicates, and updates UsesToDate.

2.2 Manual Usage Event Entry

• Description: Finance/ops can create manual UsageEvents when telemetry is missing. Manual entries require evidence and approval before posting.
• Inputs: LaunchEventID, AssetID, EventType, Units, EvidenceLinks, Justification.
• Outputs: Pending UsageEvent flagged for approval.
• Validations: Evidence required; approver must be in approval matrix.
• Acceptance: Manual events cannot be posted until approved; approval recorded.

2.3 Usage Delta Calculation

• Description: Compute UsageDelta per asset on event close: UsageDelta = PostLaunchUses − PreLaunchUses.
• Inputs: PreLaunchUses, PostLaunchUses (from telemetry or manual).
• Outputs: UsageDelta stored on LaunchEventAssetLink.
• Acceptance: UsageDelta computed and stored for every attached asset.

3. Depreciation and Amortization Engine

3.1 Time‑based Depreciation

• Description: Support standard time methods: straight‑line, declining balance, and scheduled recalculation.
• Inputs: AcquisitionCost, SalvageValue, UsefulLifeYears, DepreciationMethod.
• Outputs: Periodic depreciation amounts, updated AccumulatedDepreciation.
• Acceptance: Time‑based schedule matches configured method and posts to GL.

3.2 Usage‑based Amortization

• Description: Units‑of‑production amortization where units = launches, flight hours, burns, etc.
• Formula: DepreciationAmount = (AcquisitionCost − SalvageValue) / TotalEstimatedUses × UsageDelta.
• Inputs: TotalEstimatedUses, UsageDelta, AcquisitionCost, SalvageValue.
• Outputs: Usage amortization amount per asset for the LaunchEvent.
• Acceptance: Usage amortization computed per formula and available in Accounting Preview.

3.3 Hybrid Rules and Switches

• Description: Support configurable hybrid rules (e.g., lesser of time or uses; switch to usage after first launch).
• Inputs: Rule definitions per asset class.
• Outputs: Chosen amortization amount and method per posting.
• Acceptance: Hybrid rule engine evaluates both methods and selects per rule; result logged.

3.4 Idempotent Posting and Reconciliation

• Description: Ensure depreciation postings are idempotent and reference LaunchEventID and UsageEventIDs.
• Mechanism: Use unique posting tokens and store posting state; support replay without duplication.
• Acceptance: Reprocessing same LaunchEvent does not duplicate GL entries.

4. Refurbishment and Component Accounting

4.1 Refurbishment Candidate Creation

• Description: Create RefurbishmentRecord when CMMS posts overhaul estimate or when UsageDelta crosses thresholds.
• Inputs: AssetID, LaunchEventID, EstimatedCost, TriggerReason, PartsUsed.
• Outputs: RefurbishmentCandidate with status PendingApproval.
• Acceptance: Candidate created automatically on threshold or via CMMS webhook.

4.2 Capitalisation vs Expense Decision Workflow

• Description: Route refurbishment candidates through approval matrix; apply capitalisation rules.
• Inputs: EstimatedCost, CapitalisationThresholds, ExpectedLifeExtension, Approvals.
• Outputs: If capitalised: asset carrying amount updated and new depreciation schedule; if expensed: maintenance expense posted.
• Validations: Approvals required per cost band; supporting documents attached.
• Acceptance: Capitalisation decisions produce correct GL adjustments and updated schedules.

4.3 Component Replacement and Derecognition

• Description: Support removal of old components and recognition of new components with gain/loss calculation.
• Inputs: ComponentID, RemovalDate, DisposalProceeds, NewComponentCost.
• Outputs: Derecognition journal, new component asset record, updated inventory.
• Acceptance: Component lifecycle changes produce correct derecognition and capitalization entries.

5. Cost Capture, Allocation, and GL Posting

5.1 Launch Cost Capture

• Description: Capture direct mission costs and link to LaunchEvent (fuel, ground support, vendor invoices).
• Inputs: VendorInvoiceRef, CostType, Amount, Currency, GLAccount.
• Outputs: LaunchCostLine records and accruals if needed.
• Acceptance: Direct costs stored and visible in mission cost rollup.

5.2 Cost Allocation Engine

• Description: Allocate shared costs across assets/customers using configurable keys (weight, usage share, fixed split).
• Inputs: AllocationKeys, AllocationRules, CostLines.
• Outputs: Allocated cost lines per asset/mission/customer.
• Acceptance: Allocation produces per‑asset cost breakdown that sums to original cost.

5.3 Accounting Preview and Posting

• Description: Generate Accounting Preview for a LaunchEvent showing all journal lines (direct costs, amortization, provisions) before posting.
• Inputs: LaunchEventID, UsageDeltas, CostLines, Refurbishment decisions.
• Outputs: Preview journal lines, estimated GL accounts, totals, and drill‑downs.
• Controls: Automatic posting for routine events; manual approval required for exceptions.
• Acceptance: Preview matches posted journals; journals reference LaunchEventID and UsageEventIDs.

5.4 ERP Connector and Posting Reliability

• Description: Batch post journals to Business Central with retry and DLQ. Include LaunchEventID and UsageEventIDs in journal metadata.
• Inputs: Batch of journal lines, posting token.
• Outputs: JournalRef(s) from ERP, posting status.
• Acceptance: Successful posts reconcile to GL and failures are retried or flagged.

6. Auditability, Reporting, and Evidence Management

6.1 Traceability Requirements

• Description: Every GL entry must reference LaunchEventID, AssetID(s), UsageEventIDs, and ApprovalIDs.
• Acceptance: Auditors can trace any depreciation journal to source telemetry and approvals.

6.2 Audit Pack Generation

• Description: Produce per‑period audit packs containing GL journals, LaunchEvent snapshots, UsageEvents, telemetry refs, approvals, and document links.
• Inputs: Period selection, LaunchEventIDs.
• Outputs: Audit pack manifest and downloadable export (PDF/Excel metadata + links).
• Acceptance: Audit pack contains complete chain and evidence links for selected events.

6.3 Standard Reports

• Description: Provide Asset Register, Depreciation Schedules, Launch Cost Rollup, Mission Profitability, Refurbishment ROI.
• Inputs: Filters (period, asset class, mission).
• Outputs: Exportable reports with drill‑down capability.
• Acceptance: Reports reconcile to GL and support export to Excel/PDF.

7. Security, Controls, and Operational Requirements

7.1 Role Based Access Control

• Description: Define roles (Ops, Finance, Controller, Auditor, Admin) with permissions for creating events, approving, posting, and viewing audit packs.
• Acceptance: RBAC enforced across UI and APIs.

7.2 Immutable Audit Logging

• Description: Log all approvals, manual adjustments, postings, and status changes with user, timestamp, and before/after values. Logs must be tamper‑evident.
• Acceptance: Audit logs available for export and cannot be altered.

7.3 Idempotency and DLQ

• Description: All ingestion and posting endpoints must support idempotency tokens and route failed records to a dead‑letter queue for manual reconciliation.
• Acceptance: Duplicate telemetry is deduplicated; DLQ items are visible in reconciliation UI.

7.4 Performance Targets

• Description: Telemetry ingestion must handle bursts up to 5,000 events/min initially; overnight depreciation run completes within reporting window.
• Acceptance: Performance tests validate throughput and batch windows.

8. Data and Migration Requirements

8.1 Legacy Data Import

• Description: Import asset master, cumulative counters, historical LaunchEvents (if available), and opening GL balances with reconciliation notes for manual adjustments.
• Acceptance: Imported opening balances reconcile to legacy GL within agreed tolerance and produce reconciliation reports.

8.2 Data Retention and Evidence Storage

• Description: Store evidence links (telemetry snapshots, inspection reports) with retention policies and support GDPR/SOX retention rules.
• Acceptance: Retention policies enforce purge/archival rules and evidence remains accessible for audit windows.

9. Acceptance Criteria Summary

• LaunchEvent groups multiple assets and stores pre/post snapshots.
• Telemetry ingestion updates UsageDeltas and is idempotent.
• Depreciation engine posts usage‑based amortization referencing LaunchEventID and UsageEventIDs.
• Refurbishment workflow supports capitalisation decisions and updates carrying amounts.
• GL postings to Business Central reconcile and are traceable end‑to‑end.
• Audit packs provide complete evidence chain for auditors.
• Performance and security targets met in acceptance testing.

Overview

Purpose: Define a Business Central functional design for an accounting solution that treats launches as first‑class events, groups multiple physical assets per launch, and supports time‑based and usage‑based asset consumption, refurbishment capitalisation, mission costing, and full audit traceability. Scope: Asset register and componentisation, LaunchEvent engine, telemetry and CMMS ingestion, depreciation/amortization engine, refurbishment workflow, cost allocation, GL posting to Business Central, reporting, and audit pack generation. Primary stakeholders: Finance, Flight Operations, Maintenance, Auditors, IT.

Functional Requirements

Area	Requirement	Acceptance
LaunchEvent Management	Create LaunchEvent with metadata and attach multiple AssetInstances with roles and pre‑launch snapshots.	LaunchEventID created; pre‑launch snapshots stored.
LaunchEvent Lifecycle	Support Draft → Confirmed → In Progress → Recovered → Closed → Audited with RBAC enforced transitions.	Status transitions logged and auditable.
Usage Ingestion	Telemetry ingestion API accepts batched UsageEvents with idempotency and checksum; manual entry with evidence and approval.	Batches ingested; duplicates deduplicated; manual entries require approval.
Usage Delta Calculation	Compute UsageDelta = PostLaunchUses − PreLaunchUses per asset on event close.	UsageDelta stored on LaunchEventAssetLink.
Depreciation Engine	Support time methods and usage units‑of‑production; support hybrid rules and per‑asset configuration.	Depreciation amounts match configured rules and preview.
Event Driven Posting	On event close compute and post usage amortization and direct cost journals referencing LaunchEventID and AssetIDs.	Journals posted to BC with LaunchEvent references.
Refurbishment Workflow	Create RefurbishmentCandidate from CMMS or threshold triggers; approval matrix for capitalise vs expense.	Capitalisation updates carrying amount and recalculates schedule.
Component Accounting	Support component derecognition, replacement, and gain/loss posting.	Component lifecycle changes produce correct GL entries.
Cost Capture and Allocation	Capture direct costs and allocate shared costs by configurable keys.	Allocations sum to original cost and appear in mission rollup.
Auditability	Every GL entry links to LaunchEventID, UsageEventIDs, approvals, and evidence links.	Auditors can trace GL → LaunchEvent → UsageEvent → evidence.
Reporting	Asset register, depreciation schedules, launch cost rollup, mission profitability, refurbishment ROI, audit pack export.	Reports reconcile to GL and export to Excel/PDF.

Business Central Integration and APIs

Integration Patterns

• ERP Connector: Batch journal posting to Business Central; asset master sync; vendor invoice and payment sync back to accounting system.
• Posting Frequency: Daily batch for routine postings; ad‑hoc posting for urgent adjustments.
• Reliability: Retry logic, dead‑letter queue, and reconciliation reports for failed posts.

API Contracts

• Telemetry Ingestion API
  • Payload: LaunchEventRef; AssetSerial; EventType; Timestamp; Units; TelemetryRef; Checksum; IdempotencyToken.
  • Behavior: Validate checksum; deduplicate by TelemetryRef/IdempotencyToken; return per‑record status.
• CMMS Webhook
  • Payload: MaintenanceOrderID; AssetID; EstimatedCost; PartsUsed; CompletionStatus.
  • Behavior: Create RefurbishmentCandidate; update status on completion.
• ERP Posting API
  • Payload: Batch of journal lines with LaunchEventID and UsageEventIDs in metadata.
  • Behavior: Return JournalRef(s); support idempotent posting tokens.
• Admin APIs
  • Functions: Configure depreciation rules, capitalisation thresholds, approval matrix, allocation keys.

Business Central Specifics

• Tables to Sync: Asset master, depreciation schedules, posted journals, dimensions/tags.
• Mapping Rules: Map LaunchEvent metadata to BC dimensions; include LaunchEventID in journal memo and custom fields.
• AL Packaging: Deliver extension as AL app with versioned NuGet dependencies and automated publish pipeline.

Data Model

Entity	Key Fields
AssetInstance	AssetID; SerialNumber; AcquisitionCost; AcquisitionDate; DepreciationMethod; UsefulLifeYears; UsefulLifeUses
AssetComponent	ComponentID; AssetID; ComponentType; InstallDate; AcquisitionCost; UsefulLifeUses
LaunchEvent	LaunchEventID; MissionName; ScheduledStart; ActualStart; ActualEnd; LaunchSite; Status
LaunchEventAssetLink	LinkID; LaunchEventID; AssetID; Role; PreLaunchUses; PostLaunchUses; UsageDelta
AssetUsageEvent	UsageEventID; LaunchEventID; AssetID; EventType; Timestamp; Units; TelemetryRef
LaunchCostLine	CostLineID; LaunchEventID; CostType; Amount; Currency; GLAccount
RefurbishmentRecord	RefurbID; AssetID; LaunchEventID; EstimatedCost; CapitalisedFlag; ApprovalIDs
DepreciationSchedule	ScheduleID; AssetID; Period; DepreciationAmount; CumulativeDepreciation

Schema Notes

• References: All financial postings must include LaunchEventID and AssetID where applicable.
• Attachments: Store document references with integrity checks; do not store large blobs in BC tables.
• Indexes: Index on AssetID, LaunchEventID, TelemetryRef for high throughput queries.

UI Workflows and Approvals

Launch Event Builder

• Capabilities: Create/modify LaunchEvent; attach assets; preview pre/post snapshots; attach telemetry batch or link stream; estimate mission cost and projected depreciation.
• Controls: Ops can propose; finance must confirm for posting exceptions.

Accounting Preview Screen

• Capabilities: Show journal lines for direct costs, amortization, provisions; drill down to calculation basis and telemetry refs; approve or reject.
• Behavior: Automatic posting for routine events; manual approval required for exceptions and manual adjustments.

Approval Console

• Matrix: Approvals by cost band and asset class (e.g., Controller approves > $250k).
• Audit Trail: Immutable log of approver, timestamp, before/after values, and attached evidence.

Reconciliation UI

• Functions: Show unmatched telemetry, duplicate events, DLQ items; allow authorized users to create manual adjustments with required justification and attachments.

Non‑Functional Requirements Testing Migration and Acceptance

Performance and Scalability

• Targets: Ingest bursts up to 5,000 events/min initially; scale horizontally to support fleet growth to 200 vehicles.
• Batch Windows: Overnight depreciation recalculation completes within reporting window.

Security and Compliance

• Controls: RBAC, TLS 1.2+, AES‑256 at rest for sensitive fields, immutable audit logs, SOC2 readiness.
• Data Residency: Configurable storage region and retention policies for PII and financial records.

Testing Requirements

• Functional Tests: Create LaunchEvent with multiple assets; ingest telemetry; close event; verify depreciation journals reference LaunchEventID and match formula.
• Integration Tests: Telemetry API idempotency; CMMS webhook flow; ERP posting reconciliation.
• Performance Tests: Telemetry ingestion under peak load; overnight batch completion.
• Security Tests: Penetration test and audit log immutability verification.

Migration and Rollout

• Pilot: Run with one rocket family in parallel to legacy accounting for one reporting cycle.
• Data Import: Import asset master, cumulative counters, and summarized historical LaunchEvents with reconciliation notes.
• Cutover: Phased enablement by asset class after pilot validation.

Acceptance Criteria

• LaunchEvent groups assets and stores pre/post snapshots.
• Telemetry ingestion updates UsageDeltas and is idempotent.
• Depreciation engine posts usage amortization referencing LaunchEventID and UsageEventIDs.
• Refurbishment workflow supports capitalisation decisions and updates carrying amounts.
• GL postings to Business Central reconcile and are traceable end‑to‑end.
• Audit packs provide complete evidence chain for auditors.

If you want, I will now:

• Produce the AL table definitions and sample extension structure for Business Central based on this design, or
• Generate sequence diagrams for telemetry ingestion through to BC journal posting.