ONAT: System for persistent OUT-OF-BAND (OOB) orchestration and autonomous remediation using deterministic hybrid intelligence in air-insulated environments

Abstract

An autonomous network management system running on a local hardware server operating in an air-isolated environment, configured to perform the following steps: a) Reading in unstructured multimodal telemetry that represents a technical state discrepancy; b) Converting this data into structured JSON using a locally hosted large language model (LLM), wrapping the input with templates of 'strict prompt construction' to enforce deterministic output; c) Establishing a persistent management path via a transparent protocol gateway to bridge virtual management sessions into raw physical serial signal streams, especially when a primary IP network is not accessible; d) Retrieving current operating status data of the network device via the aforementioned OOB connection; e) Parsing this state data using a deterministic regular expression (regex) engine; and; f) Generating correction commands by calculating a difference between an ideal state derived from step (b) and the current state using mathematical set theory; g) Creating an unalterable audit trail by cryptographically signing each corrective action with a SHA-256 hashing algorithm, combined with a high-resolution timestamp and a unique incident identifier.

Description

1. AREA OF INVENTION

[0001] The present disclosure relates to a decoupled control plane architecture for autonomous infrastructure troubleshooting, in particular to the provision of an isolated management environment for heterogeneous hardware by means of translation of physical serial protocols.

[0002] More specifically, the present invention relates to an orchestrator-based, locally hosted, and air-isolated hybrid intelligence system for autonomous network remediation. The system provides a closed-loop control framework that ensures business continuity during catastrophic failures by managing heterogeneous hardware via physical serial console ports (out-of-band). It employs a sovereign architecture to process unstructured data (e.g., PDF reports) through strict prompt engineering and validates critical device states using regular-example-based deterministic logic. 2. BACKGROUND OF THE INVENTION

[0003] Field of the invention The present invention relates generally to the fields of information technology (IT) operations, network engineering and autonomous infrastructure repair, in particular to the provision of an isolated management environment for heterogeneous hardware by means of translation of physical serial protocols. Representative state of the art Conventional

[0004] Network management and automation tools like Ansible or SolarWinds typically rely on in-band accessibility (e.g., SSH or Telnet) over a primary IP network to manage and configure devices. Additionally, modern AIOps solutions often leverage cloud-based large language models (LLMs) to process network telemetry and generate configuration updates. Disadvantages of the state of the art: Traditional

[0005] Management tools encounter a significant paradox where network access is required to resolve a network outage. In catastrophic failures, such as configuration errors or DDoS attacks, the primary IP stack often becomes inaccessible, rendering centralized automation tools inoperable and necessitating manual intervention on-site. Furthermore, traditional generative AI models exhibit probabilistic non-determinism, leading to "hallucinations" where critical technical status flags (e.g., the LACP protocol flag 'P') are misinterpreted, potentially resulting in the execution of destructive commands. Finally, reliance on cloud-based AI processing requires transferring sensitive running-config data to third parties, violating data sovereignty and regulatory requirements (e.g., GDPR) in the defense and financial sectors.

[0006] Solution through the Invention: The present invention, referred to as ONAT (Orchestration of Network Automation Technologies), solves these problems by providing a locally hosted, air-isolated hybrid intelligence system. By establishing a persistent management path via physical serial RS-232 protocol gateways, the system ensures the continuity of the control logic even in the event of a complete IP stack failure. The invention utilizes a unique architecture that combines an idempotent LLM-based parsing module for unstructured data with a deterministic regex-first validation layer and mathematical set theory, thereby eliminating probabilistic errors while maintaining complete data sovereignty within a sovereign local infrastructure. 3. BRIEF SUMMARY OF THE INVENTION

[0007] The present invention provides the ONAT (Orchestration of Network Automation Technologies) platform. ONAT is a locally hosted and air-isolated hybrid intelligence, autonomous network technology system that can operate independently of IP network connectivity.

[0008] The invention comprises the following main components: 1. Persistent Out-of-Band (OOB) Management Layer: The system establishes an immutable management path via physical serial RS-232 protocol gateways, ensuring the persistence of the control logic even in the event of a complete failure of the IP stack. 2. Locally hosted and air-insulated hybrid intelligence module (Hybrid Engine): The system combines two different types of intelligence: Cognitive layer: Uses an idempotent semantic extraction engine that utilizes locally hosted LLMs as syntactic parsers to normalize unstructured telemetry into verified structured schemas. Deterministic layer: Uses regex-first zero-error parsing for critical state validation. 3. Strict Prompt Engineering: Wraps user input in restrictive templates to force the AI ​​to output only valid JSON. 4. “Golden Config” Correction: Uses mathematical set theory to calculate configuration differences (Diff) and generate correction commands. 5. Forensic examination: Cryptographically signs each action for immutable logging. 4. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1. Exemplary user interface of the ONAT network automation portal for submitting incidents. Fig. 2. Exemplary user interface of the ONAT network automation portal for the AI ​​analyzer. Fig. Figure 3 is a flowchart illustrating the general architecture and operational logic of the ONAT system, highlighting the incident handling flow 200 for automated resolution and the expert analysis flow 300 for compliance testing. Fig. 4 is a graphical user interface that displays successful (PASS) or failed (FAIL) analysis states. Fig. Item 5 is an "Incident Handler Result" report containing the generated CLI commands. Fig. 6 is an example of a management report in the “NotebookLM” style. Fig. Figure 7 is a schematic block diagram illustrating the hybrid and prioritized two-way connectivity architecture with in-band and out-of-band interfaces. 5. DETAILED DESCRIPTION OF THE INVENTION

[0009] The following description provides a comprehensive technical manual for a professional to reproduce the ONAT system. 5.1. System architecture: Out-of-band (OOB) resilience

[0010] The system uses a multimodal incident normalization engine. This engine unifies different unstructured telemetry types into a standardized incident state object, which is assigned a cryptographically unique identifier.

[0011] Operational process and system logic The system logic, as in Fig. 3 schematically depicted, begins via a central portal (Server.py) 100, where the user selection logic 102 determines the processing path based on the user input.

[0012] 5.1.1. Incident Handling Flow (Steps 200-240) After a user incident is submitted (200), the orchestrator generates a local incident.txt file (202) and triggers the incident handler (204). The system evaluates the file type (206) (e.g., CSV, PDF, or JPEG / PNG) to route the request. CSV path: The system calls incident_handler_csv.py 210 to directly read location and reference VLAN data 211. PDF path: The module incident_handler_pdf.py 212 extracts requirements using AI-native semantic parsing 213. Image / OCR path: The module incident_handler_ocr.py 214 applies OCR and AI to extract usable data 215.

[0013] Step 220: The system initiates direct socket access via a protocol gateway (e.g., Avocent) to extract the current operating state from the physical serial buffer. In an alternative implementation, specifically for direct physical connections, the orchestrator uses the pyserial library to establish a raw data stream over local TTY interfaces. In both connectivity modes, communication is governed by standardized serial parameters, typically configured to 9600 baud rate, 8 data bits, no parity (N), and 1 stop bit (8-N-1) to ensure deterministic data integrity across heterogeneous hardware.

[0014] The system handles authentication through a multi-stage handshake, first authenticating with the console server's management layer and then using stored credentials to gain privileged access to the target device's TTY interface. The AI-native parsing module 222 (e.g., Mistral via Ollama) processes this raw data. The decision engine 224 then applies mathematical set theory to calculate the configuration delta and generate global and interface-specific commands 226. These are compiled into a CLI command file 228, which triggers the creation of an Ansible playbook 230 (e.g., vlan_config.yml 232) for final execution 240 via the serial console. After execution, the system implements a recursive post-correction verification step (step 250).In this step, the system automatically triggers the extraction process (step 220) again to obtain the new "running-config". The decision engine then performs a final set-theoretical comparison between the newly retrieved state and the ideal state. The incident is only marked as "resolved" if the resulting configuration delta is zero. (SetØ) ); otherwise, the system initiates an automated fault analysis or triggers a manual override warning to ensure a truly closed autonomous control loop.

[0015] 5.1.2. Expert Analysis Workflow (Steps 300-340) Alternatively, users can initiate an expert query (300). Based on the topic type (302), the system executes specialized scripts: VLAN analysis: The script expert_script_vlans.py 310 compares the current device state with a Golden Config CSV 311 to perform a compliance validation 312 and generate a report 313. EtherChannel analysis: The script expert_script_etherch.py ​​320 captures the live command output 321. To ensure absolute precision, this path uses deterministic regex-based state parsing 322 instead of probabilistic AI. The final compliance reports 323 are then delivered to the user interface 340 for visual review. 5.2 Hybrid and fully redundant connectivity architecture

[0016] As in Fig. As shown schematically in Figure 7, the ONAT system uses a prioritized two-way connectivity architecture designed to eliminate single points of failure (SPoF) and ensure business continuity even in the event of catastrophic network failures. A. Implementation of the hardware interface (The physical layer)

[0017] The system bridges the gap between the orchestration environment and the managed infrastructure via a dedicated console server hardware stack (e.g., Vertiv™ Avocent® ACS 8000 series).

[0018] Universal serial connectivity: Each target network device is physically connected to the console server via RJ-45 cabling. The system utilizes the console server's software-selectable pinout feature (e.g., switching between Cisco and Cyclades pinouts), enabling vendor-independent physical connectivity without proprietary adapters.

[0019] Redundant uplinks: The console server (Ref. 702) connects to the outside world via two different physical interfaces: a standard in-band (Inbound / eth0) LAN port and a dedicated, isolated out-of-band (Outbound / eth1) interface, such as an integrated LTE modem. B. Direct socket access & protocol gateway logic

[0020] The ONAT orchestrator (Ref. 701) accesses target devices by treating the console server as a transparent "protocol gateway". In this architecture, the console server terminates incoming SSH / Telnet sessions and translates the payload directly into raw RS-232 serial signals (protocol translation).

[0021] Static port mapping (TCP port aliasing): Each physical serial port (TTY) on the console server is assigned a unique TCP port alias (e.g., 7001, 7002, etc.). This port number serves as the unchanging "virtual service identity" of the target network device.

[0022] IP-based direct access (IP port aliasing): As an alternative implementation, the architecture supports assigning a unique IPv4 or IPv6 address (IP port alias) to each physical serial port. This allows the orchestrator (Ref. 701) to initiate standard SSH sessions directly to the port's unique IP address, instead of using the console server's primary management IP.

[0023] Dual interface monitoring & priority: The console server listens for these assigned aliases (TCP port or IP) simultaneously on both interfaces, inbound (eth0) and outbound (eth1). The system operates on the principle of a "single active session" with strict prioritization. Standard operation (security mode): To maintain complete isolation from the production LAN, the orchestrator primarily initiates connections via the out-of-band (outbound) interface. Failover operation: Only in the event of a confirmed failure of the outbound connection does the system switch to the in-band (inbound) interface, while the destination alias remains constant.

[0024] Symmetrical return traffic: The console server uses a multiple routing table architecture to maintain different routing contexts for inbound and outbound traffic. This ensures that response packets (return traffic) are routed back through the same gateway from which the request originated, thus preventing asymmetric routing problems. C. “Security-First” Connection Logic

[0025] In the preferred embodiment, the system strictly prioritizes the out-of-band (outbound) path. The in-band (inbound) path serves only as a conditional fallback mechanism. Isolation: By default, all automation traffic is encapsulated within the isolated outbound interface, which is physically separated from the production data level. Optional air-gapping: In high-security implementations, the inbound interface can be administratively disabled or physically disconnected, making the system accessible exclusively via the out-of-band path ("air-gapped operation"). 5.3. Cognitive Layer: Locally hosted and air-insulated hybrid intelligence, strict prompt construction & deterministic control

[0026] In this preferred embodiment, the system uses a local large language model (LLM), such as Mistral, as a semantic parser rather than a direct decision-maker. The system enforces an idempotent inference constraint by limiting the extraction module to a parameter set with zero temperature and top-p unit. (temperature = 0_top_p = 1.0)binds to ensure zero-variance output across identical technical inputs.

[0027] Encapsulation through restrictive templates: Unstructured device configurations and incident reports are encapsulated in restrictive templates. These templates inject system instructions such as "STRICT RULES" and "RETURN JSON ONLY," effectively preventing conversation filler or explanatory text.

[0028] Deterministic inference control: To eliminate "hallucinations," the inference module is strictly bound to a temperature parameter of 0. This forces the underlying LLM to select the token with the highest probability and ensures that identical inputs consistently result in identical parsed outputs.

[0029] Recursive self-correcting validation loop: The cognitive layer implements a closed-loop validation mechanism. The system executes a self-correcting recursive feedback loop. AI-generated user data is subject to strict schema enforcement; a validation error triggers a technical error feedback prompt, which is limited to a deterministic iteration limit. This loop is limited to a maximum number of iterations (e.g., max_retries = 3) to prevent infinite loops while ensuring data integrity.

[0030] Exemplarische Ausführungsform 1: Rekursive selbstkorrigierende Validierungsschleife: Die kognitive Schicht implementiert einen geschlossenen Validierungsmechanismus. (Ref. 222) def extract_vlans_with_ai(config_text): max_retries = 3 # Iteration limit for stability [cite: 26] attempt = 0 error_feedback = "" while attempt < max_retries: prompt = f"Analyze configuration and return ONLY valid JSON. {error_feedback}" # Deterministic inference call with temperature = 0 [cite: 194] response = ollama.chat(model="mistral", messages=[{"role": "user", "content": prompt}], options={"temperature": 0}) vlan_data = extract_json_from_response (response ["message"] ["content"]) if vlan_data and "vlans" in vlan_data: return vlan_data # Success: Validation passed attempt += 1 error_feedback = "PREVIOUS ATTEMPT FAILED: Invalid JSON format. Try again." return None

[0031] Exemplary Implementation 2: Parsing Unstructured PDFs The following implementation shows how ONAT extracts usable data (location, switch name, VLAN numbers) from an unstructured PDF report using the local model with strict JSON constraints:

[0032] Extraction: Raw text is extracted from the PDF file using a library such as pdfplumber. Prompting: A strict prompt is sent to the local Mistral model, requiring the return of location, switch name, and VLAN numbers in a specific JSON format. Parsing: The response is processed by deterministic parsing of the AI ​​output, with a regular expression isolating the JSON block for final data extraction. (Ref. 213) def extract_location_and_vlans_from_pdf(pdf_path): # Extract raw text from PDF text = pdfplumber.open(pdf_path) .extract_text() # Send Strict Prompt to local Mistral model prompt = " " " Extract from this PDF content: 1. Location (eg: Berlin) 2. Switch name (eg: Berlin-switch2) 3. VLAN numbers (eg: 10, 20, 30) Return JSON: {"location": "Berlin", "switch": "Berlin-switch2", "vlans": ["10", "20"]} " " " # Local Inference Call response = ollama.chat(model="mistral", messages=[{"role": "user", "content": prompt}]) # Deterministic Parsing of AI Output json_match = re.search(r'\{.*\}', response["message"] ["content"]) data = json.loads(json_match.group(0)) return data["location"], data["switch"], data["vlans"] .

[0033] Exemplary Implementation 3: Parsing Complex Switch Configurations (CLI) ONAT parses raw Cisco switch configuration files to extract VLANs by using a prompt that includes explicit “STRICT RULES” regarding comma-separated values ​​and counts to ensure accuracy. This process uses an inference call configured with temperature = 0 and top_p = 1.0 to achieve deterministic results. `def find_and_parse_switch_config(location): # 1. Read Config File with open(f"{location}.txt") as f: config_text = f.read() # 2. Assign Parsing Task to Mistral with Strict Rules prompt = f" " " Parse this Cisco switch configuration. Extract ALL VLAN numbers. STRICT RULES: 1. "switchport trunk allowed vlan 10,20,30,50,99" -> ["10", "20", "30", "50", "99"] 2. "switchport access vlan 50" -> ["50"] 3.Count carefully! Return JSON: { { "vlans": ["10", "20", "30"], "interfaces": {{ "Ethernetl / 12": {{"mode": "trunk", "vlans": ["10", "20"]}}}}}} Configuration: {config_text} " " " # 3. Ollama Call (Deterministic with temperature=0) response = ollama.chat( model="mistral", messages=[{"role": "user", "content": prompt}], options={"temperature": 0, "top_p": 1.0} ) # ... JSON parsing logic follows .

[0034] Technical significance: By setting temperature=0 and defining strict input / output examples in the prompt, ONAT eliminates AI hallucinations and transforms the LLM into a reliable extraction engine for both document and configuration data.

[0035] 5.4. Deterministic Layer: Regex-Based Expert Analysis When verifying live operational states, ONAT disables artificial intelligence to ensure 100% accuracy through a deterministic layer. This layer uses expert scripts to collect state data that requires absolute certainty, such as port bundling or interface status.

[0036] Exemplary embodiment 4: EtherChannel state analysis. Physical port flags, such as the '(P)' flag, which indicates a 'bundled' state in LACP protocols, are checked with absolute certainty using regex patterns instead of probabilistic AI.

[0037] Exemplary embodiment 5: Deterministic instruction generation logic (Ref. 224) 5.5. Decision Engine: Mathematical Set Theory

[0038] The system uses mathematical set theory to calculate correction actions ( (R - C) ), thereby enforcing a strict separation between the cognitive layer (parsing) and the decision engine (action generation).

[0039] The correction equation: The system uses an idempotent delta-state engine that computes absolute correction requirements through formal set complement logic: A add = R\C (state elements of the target state that are missing in the current state) A RM = C\R (Unauthorized state elements present in the current state)

[0040] Refinement: All generated commands are sorted into an execution necessity hierarchy to ensure state stability.

[0041] Implementation: This logic identifies discrepancies between the ideal state derived from parsed incident reports (set R) and the current state derived from parsing the device's running configuration (set C). By calculating the correction as a mathematical difference, the system ensures that every generated command is a technical necessity and not a probabilistic guess.

[0042] Command generation: The identified quantity differences are translated into concrete CLI commands (e.g., vlan 40 for an addition or no vlan 99 for a removal) and sorted to ensure the correct execution order. Exemplary embodiment 6: Deterministic instruction generation logic

[0043] Exemplarischer Code (incident_handler_csv.py): def compare_global_vlans(vlan_data, reference_vlans): global_vlans = set(vlan_data.get("vlans", [])) # Mathematical Set Difference missing_vlans = reference_vlans - global_vlans # To be Added excess_vlans = global_vlans - reference_vlans # To be Removed commands = [ ] for vlan in sorted(missing_vlans, key=int): commands.append(f"vlan {vlan}") for vlan in sorted(excess_vlans, key=int): commands.append(f"no vlan {vlan}") return commands 5.6. Herstellerunabhängige Befehlszuordnungslogik

[0044] Building upon the prioritized hardware architecture and the protocol gateway logic defined in Section 5.1.1, ONAT implements an abstract task layer to manage heterogeneous network hardware (e.g., Cisco, Huawei, HPE) without vendor lock-in. This architecture allows the central 701 orchestrator to work with standardized function definitions instead of vendor-specific syntax. Interoperability is achieved through a multi-stage mapping process. 5.6.1. Connectivity Mapping & Profile Identification

[0045] The Orchestrator 701 identifies the target device's operating system by referencing a local configuration database that maps each unique virtual service identity to a specific vendor profile. The system supports two primary methods for establishing this identity: Method A: Static Port Mapping (TCP Port Aliasing): Each physical serial port (TTY) on console server 702 is assigned a unique TCP port alias (e.g., port 7001 for Cisco, port 7002 for HPE). This port number serves as the unchanging identity of the target device. Method B: IP-based direct access (IP port aliasing): In this alternative implementation, each physical serial port is assigned a unique IPv4 or IPv6 address. This allows the Orchestrator 701 to initiate standard SSH sessions directly to the IP address of a specific port, bypassing the need for non-standard TCP port configurations in the connection string. 5.6.2. Dynamic command translation (Abstract task)

[0046] Operational goals are defined as "abstract tasks" within the system logic, such as get_vlan_list or apply_port_config. The mapping engine translates these abstract goals into concrete, vendor-specific CLI syntax using a localized lookup table.

[0047] Example command translation table: | Virtual Service Identity | Detected Profiles | Abstract task | Vendor-Specific Syntax | | :--- | :--- | :--- | :--- | | Port 7001 / 10.10.10.1 | Cisco IOS | get_vlan_list | show vlan | | Port 7002 / 10.10.10.2 | Huawei VRP | get_vlan_list | display vlan | | Port 7003 / 10.10.10.3 | HPE Comware | get_vlan_list | display vlan | 5.6.3. Technical Significance

[0048] This modular framework ensures that the core remediation logic remains unchanged regardless of the underlying hardware. New manufacturers or hardware models can be easily integrated into the ONAT system by adding a new profile entry to the lookup table, thus guaranteeing true vendor independence and future-proof scalability in large, air-insulated data center environments. 5.7. Forensic audit and traceability layer

[0049] To ensure technical and legal accountability, ONAT implements a cryptographic forensic audit layer that maintains a non-repudiable cryptographic ledger. Every autonomous intervention is sealed with a high-resolution timestamp (ISO-8601) and a SHA-256 digital signature, creating an immutable chain of accountability.

[0050] Immutable forensic ledger: The signature serves as a digital seal for every correction action. This data is recorded in a protected log file (forensic_audit.log) to ensure an irrefutable audit trail that verifies what was done, by whom, and at what precise time.

[0051] Exemplarische Ausführungsform 7: Forensische Aktionssignierung (SHA-256) ) def sign_forensic_audit(incident_number, commands): """Signs every autonomous action for immutable logging [cite: 129] " " " timestamp = datetime.now() .isoformat() # ISO-8601 High- resolution [cite: 125] command_str = ",".join(commands) # Concatenation of ID, Timestamp and payload for integrity [cite: 51] data_to_sign = f"{timestamp}-{incident_number}-{command_str}" # Cryptographic SHA-256 Hashing [cite: 52, 149] signature = hashlib.sha256(data_to_sign.encode()) .hexdigest() with open("forensic_audit.log", "a") as f: f.write(f"[{timestamp}] Incident: {incident_number} | Hash: {signature}\n") return signature

Claims

An autonomous network management system running on a local hardware server operating in an air-isolated environment, configured to perform the following steps: a) reading unstructured multimodal telemetry representing a technical state discrepancy; b) converting this data into structured JSON using a locally hosted large language model (LLM), wrapping the input with 'strict prompt construction' templates to enforce deterministic output; c) establishing a persistent management path through a transparent protocol gateway to bridge virtual management sessions into raw physical serial signal streams, particularly when a primary IP network is inaccessible; d) retrieving current operational state data of the network device over the aforementioned out-of-band (OOB) connection.e) Parsing this state data using a deterministic regular expression (regex) engine; and; f) Generating correction instructions by calculating a difference between an ideal state derived from step (b) and the current state using mathematical set theory; g) Creating an immutable audit trail by cryptographically signing each correction action with a SHA-256 hashing algorithm, combined with a high-resolution timestamp and a unique incident identifier.; An automatic network incident response system comprising: a local hardware server operating in an air-isolated environment; a serial interface configured for physical out-of-band communication with a network device; and a processor coupled to a memory, the memory storing instructions which, when executed by the processor, cause the system to: i. parse unstructured incident reports using a locally hosted generative module; ii. validate parsed outputs through a deterministic, regular-example-based validation engine; iii. compute corrective instructions using mathematical set theory; iv. execute the corrective action via an infrastructure-as-code engine; v. seal all executed instructions in an immutable log using cryptographic signatures. The system according to claim 1, wherein the locally hosted LLM is a Mistral model.

Images