Architectural Blueprint for Localized AI Memory Systems in Desktop LLM Environments

Full report

On this page

Executive Architectural Overview

The evolution of local Large Language Model (LLM) desktop applications necessitates a paradigm shift from transient, stateless execution environments to highly persistent, stateful, memory-aware architectures. In traditional software configurations, such as the initial iteration of the LocalLlmDesktop Windows Presentation Foundation (WPF) application, agents function adequately within the confines of a single interactive session but suffer from total contextual amnesia upon the session's termination.1 To rectify this fundamental limitation, advanced desktop application implementations must construct and govern a unified memory core. This core must isolate the end-user's personalized, interactive memory system from the broader developmental or systemic execution instance, ensuring that user-specific contexts, behaviors, and knowledge graphs do not pollute the baseline application logic. This comprehensive analysis details the rigorous architectural requirements and implementation strategies for establishing an autonomous, modifiable .uai memory system localized entirely on the end-user's desktop machine. It establishes the necessity of integrating the Universal Artificial Intelligence Exchange (UAIX) AI Memory Package Wizard directly into the local desktop client via embedded web technologies to facilitate seamless user control.3 Furthermore, it demands a structural and conceptual overhaul of both the WPF user interface and the underlying C\#.NET 8.0 background service layers. These layers must be re-engineered to ensure that the memory frameworks remain fully editable, strictly isolated, and dynamically bound to inference generation processes without compromising local system stability or execution performance.1 By leveraging structured memory pipelines and native desktop integration techniques, the application can transform a basic generative wrapper into a sophisticated, contextually persistent agentic platform.

The Paradigm Shift: Transitioning from Stateless Inference to Stateful Autonomous Memory

The core limitation of baseline local LLM deployments is their reliance on rigid, immutable system prompts and ephemeral conversation transcripts.1 A fundamentally stateless architecture forces the user to engage in continuous manual reinjection of context, which invariably leads to severe context window bloat, extreme token inefficiency, and the inevitable degradation of the model's autonomous task completion capabilities over extended interactions. In direct contrast, a memory-aware agent possesses the systemic capability to persist knowledge, continuously retrieve relevant historical context, and iteratively update its internal semantic representations across an infinite number of independent sessions.2

Deconstructing the Governed Memory Core Architecture

Enterprise-grade analytical frameworks, such as the Oracle AI Agent Memory architecture, provide a definitive precedent, demonstrating that serious agentic systems require a governed software substrate capable of managing short-term threads, complex episodic interactions, and long-term durable memories simultaneously.4 Translated into a localized desktop computing topology, this necessitates completely abandoning the archaic practice of appending raw chat logs infinitely into the model's context window. Instead, an intelligent desktop application must implement distinct, specialized memory pipelines that categorize and process information based on its temporal relevance and semantic utility.

The foundational necessity of this tri-layered architecture is the active prevention of context pollution. Memories must be dynamically scored by contextual relevance, prioritizing localized knowledge based on the immediate temporal interaction while simultaneously preserving high-value historical insights for broader conceptual queries.5 Furthermore, as defined by specialized frameworks like Creellai, an AI memory system serves as a structured layer explicitly designed to preserve approved AI work, allowing it to be seamlessly reused instead of computationally recreated.7 Rather than treating user prompts and system instructions as disposable inputs, the memory system captures the prompts that produced optimal results, the instructions that define tone and structure, and the constraints that dictate safe execution boundaries.7

Analyzing the Universal Artificial Intelligence Exchange (UAI) Standard

To establish a uniform, interoperable format for these distinct memory strata across diverse local and remote systems, the integration strategy must rely heavily on the UAI-1 structured message format standard.3 The UAI framework acts as an open, highly auditable communication envelope for sophisticated AI-to-AI and Human-to-AI systems, strictly enforcing a transition away from unstructured, ambiguous text blobs toward highly formalized, machine-readable JSON and text manifests.3 This standardization ensures that memory structures remain resilient to updates and model transitions.

The Structuring Envelopes and Capability Tiers

The UAI-1 standard operates utilizing a dual-envelope posture designed for maximum compatibility and extensibility. It relies upon a canonical snake\_case transport envelope, which is heavily utilized by underlying schemas, validation examples, field-order normalizations, and validator fixtures, while simultaneously supporting a camelCase publication-envelope vocabulary under the SPEC-01 Canonical Envelope definition.3 This structured format categorizes agent access models into a strict "Capability Ladder," defining precise security and operational boundaries that prevent runaway agentic behavior within local environments.3

The AI Memory Package Wizard and Asset Generation

The primary interface for constructing these structured, local-first bundles is the AI Memory Package Wizard (UAIX-TOOL-0334).3 Designed for sophisticated dual-channel interpretation, the wizard provides both a human-readable web user interface and a stable machine-readable payload via an embedded JSON block named script\[data-ai-digest\].3 This mechanism ensures that AI agents visiting the configuration page can ingest stable machine keys to resolve configuration presets, support boundaries, and checksums without requiring a complex, separate public importer endpoint.3 The wizard orchestrates a rigorous eight-step local-first package planning flow: Preset Definition, Basics Configuration, Collaboration Rules, Operations Mapping, Governance Structuring, Active Memory Directives, Receiver Instructions, and finally, Review and Export Generation.3 Crucially for a desktop deployment prioritizing local privacy, the wizard strictly enforces a local-first operational boundary. It performs no hosted repository actions, executes no unsupervised remote site writes, and relies entirely on local browser-based draft caching to render real-time file previews.3 The output of this intensive configuration procedure is a canonical starter .zip package containing a highly predictable .uai/ directory structure, packed with specialized textual and JSON-LD artifacts that explicitly dictate agent behavior.3

Furthermore, the introduction of fragment URLs during the configuration flow, such as \#setup-file-handoff, instructs the wizard to append advanced operational structures into the package. These configurations layer active file intake mechanisms, explicit disposition guidance, and complex intake completion gates into the local architecture, allowing the desktop agent to independently process external document drops while maintaining a meticulous proof-of-use evidence ledger.3

Enforcing Environmental Isolation: Development vs. End-User Instances

A critical architectural mandate for deploying this system is the rigorous, programmatic isolation of the memory instance utilized by the desktop application's end-user from the overarching, global development environment instance. The failure to isolate these strata results in cross-contamination of contexts, wherein local system commands or debugging prompts bleed into the user's conversational flow, destroying the illusion of a personalized assistant. In a shared or monolithic paradigm, developers actively writing system rules, debugging inference pipelines, and experimenting with architecture maps (e.g., utilizing the .uai/architecture.uai to guide IDE integration) risk heavily polluting the end-user’s localized runtime experience. An end-user interacting with the LLM via the WPF interface for personal productivity, narrative generation, or general local assistance requires an episodic memory base tuned entirely and exclusively to their own conversational patterns, stylistic preferences, and localized tool configurations.3 To definitively achieve this crucial isolation, the desktop platform architecture must institute a sophisticated localized storage manager that utilizes dynamically generated, content-addressed directories, entirely decoupled from the developer's underlying source control workspace.1 Upon application initialization, the runtime host abstraction must explicitly bind the model execution strictly to a user-specific isolation pathway, such as %LOCALAPPDATA%\\LocalLlmDesktop\\Memories\\ActiveUser\\.uai. This guarantees that all background memory extraction algorithms, periodic consolidation routines, and write-back pipelines modify only the user’s designated local sandbox.2 This strategy provides the absolute governance and production isolation necessary for secure enterprise and consumer deployments, ensuring that updates to the core application executable never inadvertently overwrite the user's deeply personalized historical memory graphs.4

Integration Mechanics: Embedding the Web Wizard via WebView2

To empower end-users with native, unhindered access to the UAIX AI Memory Package Wizard without introducing the friction of forcing them into an external web browser, the application architecture must integrate a Microsoft Edge WebView2 control directly into the WPF presentation layout.8 Because the UAIX wizard provides live structural build previews, real-time prompt nudging based on ambiguity detection, and exports complex .zip archive packages directly from localized browser memory, the WebView2 engine serves as an ideal, highly capable execution bridge.3 However, the default behavioral profile of the WebView2 browser engine presents a fundamentally unacceptable user experience for a cohesive, native desktop application. Under standard conditions, executing a download from the embedded wizard will trigger the Windows OS native "Save As..." dialog or prompt a detached browser download hub, violently breaking the illusion of a deeply integrated software tool and introducing file system path confusion for the user.10 The architecture therefore strictly requires the transparent interception, programmatic rerouting, and total subjugation of the wizard's output delivery mechanism.

Asynchronous Download Interception and UI Suppression

The CoreWebView2 Application Programming Interface (API) provides sophisticated event hooks designed to fully control the file download lifecycle. By explicitly subscribing to the CoreWebView2.DownloadStarting event handler during the EnsureCoreWebView2Async initialization phase, the desktop application assumes absolute, programmatic control over the payload delivery sequence.11 When the end-user concludes the intricate eight-step memory planning flow and clicks the export button, the WebView2 engine triggers the download event. The WPF host application must execute the following complex interception and suppression sequence to ensure seamless functionality:

1. Event Capture and Absolute UI Suppression: The application evaluates the incoming event parameters utilizing the CoreWebView2DownloadStartingEventArgs object. By immediately asserting args.Handled \= true; within the event execution block, the application explicitly and forcefully suppresses the default Microsoft Edge download dialog, ensuring the user remains entirely focused within the custom WPF application's aesthetic boundary.10
2. Path Rerouting and Staging: The application intercepts the args.ResultFilePath string and dynamically modifies it to point towards an isolated, temporary staging directory securely nestled within the user's localized application data path (e.g., %TEMP%\\LocalLlmDesktop\\Staging).10 This prevents user-facing directories like Downloads from being cluttered with intermediate .zip artifacts.
3. State Monitoring and Thread-Safe Reporting: The background execution context monitors the CoreWebView2DownloadOperation interface to track continuous byte progression. Because WPF strictly prohibits background threads from directly modifying UI elements, the application must utilize the Dispatcher.InvokeAsync or SynchronizationContext.Current.Post pattern to safely relay download progression states back to the main WPF UI thread.10 This data is utilized to update a custom visual progress bar or modify the existing StatusTextBlock located at the base of the MainWindow.xaml.1

This exact interception sequence transforms a detached, external web-based export mechanism into what appears to be a deeply integrated, highly responsive native application feature.

Asynchronous Payload Ingestion and File Extraction Mechanics

Once the intercepted WebView2 download operation signals a successful completion state, the raw, compressed .zip archive residing in the temporary staging directory must be meticulously extracted into the user's active %LOCALAPPDATA% .uai execution directory. This complex file system operation invokes the System.IO.Compression namespace, specifically utilizing the ZipFile and ZipArchive toolsets available natively within the.NET 8.0 framework.13 Given that the underlying WPF framework inherently mandates the absolute preservation of a highly responsive, unblocked UI thread, executing synchronous Input/Output (I/O) operations against the file system is strictly prohibited. The entire ZIP extraction and directory traversal logic must be encapsulated within a dedicated background task, heavily utilizing the Task.Run() methodology alongside robust CancellationToken monitoring to allow for graceful operational aborts if the application is suddenly closed.1

Extraction Protocol and Collision Management Algorithms

The programmatic deployment of the ExtractToDirectory or ExtractToDirectoryAsync methods must be handled with precise, rules-based overwrite controls to categorically prevent the catastrophic, irreversible deletion of pre-existing end-user episodic memory files.15 The standard extraction pipeline must rigidly adhere to the following sequence:

1. Directory Validation and Conflict Resolution: The application first verifies the target destinationDirectoryName (the user's active sandbox). If pre-existing files are detected, the application cannot blindly overwrite the directory. It must engage a selective reconciliation protocol, potentially moving old memory configurations to a .bak folder to allow for non-destructive rollbacks.17
2. Asynchronous Unpacking: Utilizing the specialized C\# method ZipFile.ExtractToDirectoryAsync(source, destinationDirectoryName, overwriteFiles: true, cancellationToken), the dedicated background thread sequentially decompresses the intricate UAI configuration structure.15 The overwriteFiles boolean must be managed dynamically based on user intent—overwriting core operational schemas while explicitly protecting customized fact databases.
3. File System Sanitization and Security Validation: Following extraction, the newly unpacked payloads must be recursively scanned to ensure they adhere strictly to expected .uai file structures. Anomalous file extensions or malicious attempts at path traversal (e.g., zip entries containing ..\\..\\ to escape the sandbox) must be instantly intercepted and neutralized to preserve the local host's absolute security boundary.15

For more granular, algorithmic control, particularly when attempting to merge new configuration elements with deeply established user data, the application architecture must bypass the bulk ExtractToDirectory method in favor of manually iterating through the archive.Entries collection. By opening a read stream for each ZipArchiveEntry individually, the desktop system can selectively parse and merge JSON objects, dynamically append missing structural configuration keys, and explicitly ignore incoming files that would otherwise catastrophically overwrite the user's active, heavily curated .uai/short-term-memory.uai ledger.16

Re-Engineering the Desktop UI for Deep Memory Management

The foundational integration of a unified, editable memory core necessitates profound, structural modifications to the existing MainWindow.xaml file and its associated C\# code-behind mechanisms. Analysis of the current interface reveals a structurally monolithic design, dedicating its primary visual real estate strictly to static configuration parameters and a singular, vertically expanding ChatTranscriptTextBox.1 To fulfill the critical requirement of end-user memory modifiability, the interface must dramatically evolve to support multidimensional, concurrent data visualization.

Implementing the TabControl Architecture for Cognitive Organization

The most optimal, highly scalable architectural pattern for exposing deep memory editing capabilities to the end-user involves entirely replacing the dominant "Chat" GroupBox (currently located in Row 2 of the primary Grid) with a borderless, multi-pane TabControl component.1 This strategy preserves overall application screen efficiency while radically expanding functional capability without introducing overwhelming visual clutter.

Strategic Wizard Integration and Spatial Placement

Access to the integrated WebView2 UAI Wizard must be seamlessly, intuitively woven into the primary user flow. Visual and functional analysis dictates three distinct, viable placement strategies:

1. The Hardware and Model Parameter GroupBox: Introducing a dedicated "Configure UAI Memory" interactive button directly adjacent to the existing LoadModelButton within the Row 0 layout. This visually and cognitively associates the complex memory setup directly with the foundational model acquisition and loading phase, ensuring users do not launch models without memory contexts.1
2. The Zero-State Overlay Architecture: When the application initiates without a predefined .gguf model or lacks an initialized .uai memory configuration directory, the application can programmatically render a modal overlay directly atop the primary chat view. This dominant "Welcome Overlay" automatically hosts the WebView2 wizard, forcefully guiding the user through the eight-step planning flow immediately upon their first application launch, thereby mathematically guaranteeing a correct structural and memory baseline before any chat occurs.1
3. The Traditional MenuBar Topology: Shifting all peripheral operational controls into a standardized Window.Menu structural element located at the absolute apex of the application window. This methodology aggressively declutters the main chat canvas while retaining rapid, multi-click access to the memory package downloader wizard, hardware optimization subroutines, and archive flush tools.1

Ensuring Thread-Safe Interface Mutations

The implementation of these complex UI controls must rigorously and flawlessly adhere to strict WPF threading models. When an end-user navigates into the semantic Memory Manager tab and actively modifies a deeply nested contextual fact, the underlying state file must be updated asynchronously to prevent locking the UI. Furthermore, if the LLM backend is actively streaming text—a delicate operational state monitored by the boolean isGenerating flag and the volatile CancellationTokenSource—the application must exclusively utilize Dispatcher.InvokeAsync(..., DispatcherPriority.Background) to queue the UI updates. This prevents fatal thread collisions or structural changes to the memory objects currently locked in memory by the inference engine's aggressive read operations.1

The Inference Binding Layer: Mapping Structured Memory to Execution Context

The simple presence of structured .uai files residing on the local disk holds absolutely no utility unless that complex information is accurately, programmatically injected into the LLM's active context window at runtime. The LocalLlmService application layer must serve as the complex programmatic bridge, dynamically linking the static files to the dynamic generation parameters explicitly defined within the LocalLlmLoadOptions and LocalLlmGenerationOptions data models.1

Dynamic Context Concatenation and Prompt Assembly

In the application's base, unoptimized implementation, the system prompt is a simple, static, user-defined string injected singularly prior to conversation initiation.1 The advanced memory-aware architecture completely refactors and destroys this simplistic pipeline. The SystemPrompt parameter must instead be compiled sequentially at runtime through a highly sophisticated aggregation process. Immediately prior to the execution of the LocalLlmService.LoadModel command, the application's reading mechanisms must execute a sequence: First, they pull the dense contents of the .uai/system-profile.uai file to establish the foundational behavioral rulesets and rigid formatting constraints.1 Second, the system appends the contents of the .uai/receiver-brief.uai to outline the specific operational persona and computational bounds. Finally, and most critically, the application parses the dynamically changing .uai/short-term-memory.uai to inject recent, summarized interaction ledgers. This results in a massive, composite system prompt that dynamically updates and reshapes itself prior to every individual prompt execution without user intervention.3

Complex Hyperparameter Implications and Tuning

The aggressive injection of dense, structured memory artifacts significantly and permanently impacts how standard generation hyperparameters function within the local inference engine 1:

Long-Term Maintenance: Memory Compaction and Archival Mechanics

The local desktop environment is fundamentally and inescapably constrained by consumer-grade hardware limitations regarding VRAM capacity and CPU thread availability; therefore, infinite context appending is mathematically and computationally impossible.1 To ensure long-term viability, the application must implement a rigorous, highly cyclical memory compaction and garbage collection loop. As the temporal interaction persists and total tokens approach the defined ContextSizeTextBox ceiling, the application architecture must intelligently intercept the raw, bloated conversational elements. Instead of executing a simple queue ejection—a destructive process which permanently destroys context—the background service must pause standard execution to run a discrete, highly constrained inference pass.1 This isolated background operation requests the underlying LLM to process its own raw chat logs and generate incredibly concise, factual summaries (e.g., translating a massive, 2000-word debate regarding programming frameworks into the highly distilled, semantic fact: "User prefers React, reasons: components \+ TypeScript").5 These aggressively compressed insights are then programmatically written back to the .uai/short-term-memory.uai text file utilizing safe asynchronous I/O protocols, while the original, massive raw transcripts are sequentially flushed out to the .uai/archives/session-log.uai evidence directory to maintain the audit trail.3 This meticulous architecture ensures that the agent permanently remembers key operational discoveries and user nuances without being computationally overwhelmed by peripheral, colloquial dialogue. Consequently, this maximizes the functional utility of the available CPU thread allocations and GPU layer offloading matrices across multi-month session lifetimes.1

Integrating Memory Governance with Custom Model Platforms

The implementation of a highly isolated, modifiable UAI memory framework does not operate in a computational vacuum. It must intricately, securely interface with the broader local model platform architecture, an ecosystem explicitly designed to manage and execute unverified, heavily compressed binaries securely.1

The Verification and Storage Enclave Interaction

The foundational LocalEndpoint architectural design mandates that untrusted artifacts—be they models or configuration files—must never be permitted to activate directly in-process.1 While this paramount security doctrine primarily concerns executable .gguf, .tflite, and complex .onnx inference files, it equally applies to downloaded, unverified .uai packages. Although standard text files inherently lack the programmatic ability to trigger the severe remote code execution exploits traditionally associated with unsafe formats like Python pickle objects, a maliciously crafted or poisoned UAI package could theoretically engage in sophisticated prompt injection attacks or maliciously alter the agent's safe structured output boundaries to leak system data.3 Therefore, immediately prior to the memory manager copying an intercepted WebView2 ZIP payload into the active, execution-ready end-user directory, the system's Verification Engine subsystem must rigorously inspect the files.1 This intense inspection involves evaluating the embedded script\[data-ai-digest\] cryptographic signatures, comparing hash checksums, and meticulously parsing the structured files to verify absolute conformity to the rigid UAI-1 specifications.3 Any package failing these checks is immediately quarantined. Simultaneously, the platform's Storage Manager actively oversees all content-addressed blob storage operations.1 If an end-user wishes to revert an overly aggressive memory compaction operation, or simply wishes to restore their autonomous agent to a previous, stable baseline configuration, the storage manager's snapshot and rollback capabilities can seamlessly, instantaneously resurrect previous iterations of the .uai/system-profile.uai files or episodic logs. This enables deep, non-destructive experimentation with different AI memory personas without the risk of permanently corrupting the user's primary historical graph.

Platform Alignment and Algorithmic Format Prioritization

The overall efficacy of the structured .uai memory system is highly dependent on the baseline reasoning capabilities of the underlying local LLM. The LocalEndpoint strategy explicitly prioritizes the Tier-One GGUF format executed via the highly optimized llama.cpp worker due to its massive efficiency gains across 1.5-bit to 8-bit integer quantizations on standard commodity hardware.1 Because smaller, heavily compressed quantization levels often result in subtle perplexity degradation and a reduced cognitive capacity to strictly follow complex, multi-step rule hierarchies, the .uai/system-profile.uai and .uai/receiver-brief.uai inputs generated by the wizard must be highly optimized, concise, and rigidly formatted to ensure flawless compliance from quantized engines.3 Furthermore, the deep integration of ONNX Runtime models (categorized as Tier One) allows for highly portable execution scaling across CPU, dedicated GPU, and distinct NPU (Neural Processing Unit) architectures.1 As local edge models become exponentially faster and more capable, the intensive background memory compaction and summarization loops detailed previously can be entirely offloaded to secondary, highly specialized ONNX-based summarization workers operating silently in the background. This highly specialized, dual-model routing architecture ensures that the primary WPF UI chat generation remains completely unfettered, preserving maximum interactivity and responsiveness to user inputs while the agent quietly builds its episodic memory in parallel.

Works cited

1. Adding Direct Custom Model Support to LocalEndpoint Desktop.md
2. Build Memory-Aware Agents \- YouTube, accessed June 14, 2026, https://www.youtube.com/watch?v=lfIj\_Qm-Egc
3. AI Memory Package Wizard | UAIX | Universal Artificial Intelligence ..., accessed June 14, 2026, https://uaix.org/en-us/tools/ai-memory-package-wizard/
4. A Governed, Unified Memory Core for Enterprise AI Agents | developers \- Oracle Blogs, accessed June 14, 2026, https://blogs.oracle.com/developers/oracle-ai-agent-memory-a-governed-unified-memory-core-for-enterprise-ai-agents
5. AI agent memory that doesn't suck \- a practical guide : r/AI\_Agents \- Reddit, accessed June 14, 2026, https://www.reddit.com/r/AI\_Agents/comments/1lrmx95/ai\_agent\_memory\_that\_doesnt\_suck\_a\_practical\_guide/
6. Unified Memory Core for AI Agents | developers \- Oracle Blogs, accessed June 14, 2026, https://blogs.oracle.com/developers/unified-memory-core-for-ai-agents
7. What Is an AI Memory System? \- Medium, accessed June 14, 2026, https://medium.com/@crellai-founder/what-is-an-ai-memory-system-4c0a3dfbea10
8. Get started with WebView2 in WPF apps \- Microsoft Edge Developer documentation, accessed June 14, 2026, https://learn.microsoft.com/en-us/microsoft-edge/webview2/get-started/wpf
9. DownloadStarting event not firing when selecting "Save as" from context menu · Issue \#4562 · MicrosoftEdge/WebView2Feedback \- GitHub, accessed June 14, 2026, https://github.com/MicrosoftEdge/WebView2Feedback/issues/4562
10. CoreWebView2.DownloadStarting Event (Microsoft.Web.WebView2.Core), accessed June 14, 2026, https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2.downloadstarting?view=webview2-dotnet-1.0.3912.50
11. WebView2 file download notification box \- Stack Overflow, accessed June 14, 2026, https://stackoverflow.com/questions/68823783/webview2-file-download-notification-box
12. How to hide the Download dialog in WebView2 while downloading page content or printing with "Save as PDF" option? \- Stack Overflow, accessed June 14, 2026, https://stackoverflow.com/questions/73464438/how-to-hide-the-download-dialog-in-webview2-while-downloading-page-content-or-pr
13. ZipFile.ExtractToDirectory Method (System.IO.Compression) \- Microsoft Learn, accessed June 14, 2026, https://learn.microsoft.com/en-us/dotnet/api/system.io.compression.zipfile.extracttodirectory?view=net-10.0
14. ZipFileExtensions.ExtractToDirectory Method (System.IO.Compression) | Microsoft Learn, accessed June 14, 2026, https://learn.microsoft.com/en-us/dotnet/api/system.io.compression.zipfileextensions.extracttodirectory?view=net-10.0
15. ZipFile.ExtractToDirectoryAsync Method (System.IO.Compression) | Microsoft Learn, accessed June 14, 2026, https://learn.microsoft.com/en-us/dotnet/api/system.io.compression.zipfile.extracttodirectoryasync?view=net-10.0
16. c\# \- Unzip files programmatically in .net \- Stack Overflow, accessed June 14, 2026, https://stackoverflow.com/questions/836736/unzip-files-programmatically-in-net
17. Decompress a ZIP archive with .NET | by BEN ABT | Medialesson \- Medium, accessed June 14, 2026, https://medium.com/medialesson/decompress-a-zip-archive-with-net-d2c0a16ed794