Multinodal Core: Difference between revisions

From Solas Tempus DB
Tag: Removed redirect
No edit summary
Line 1: Line 1:
The multinodal core is a device that allows sentient AI programs to be transferred between cores at will using the Ansible Transit Protocol.  This is an extension of the Island Protocol first developed in 2155 for use in Guin style computers, state of the art at the time.  This communications protocol between networked subspace peers was standard prior to the advent of Duotronics in the early 23rd centuryThe Ansible Transit Protocol uses a forced quantum entanglement between subspace nodes over a domain similar to that of a [[transporter]] beamThe idea first came from a study of how Borg technology is able to maintain the collective consciousness over such vast distances.
[[File:{{#setmainimage:multinodal-core-full.jpg}}|thumb|Full]]
The multinodal core is a device that allows sentient AI programs to be transferred between cores at will using the Ansible Transit Protocol (ATP).
 
== Full Core ==
A full multinodal core attached directly to primary power and communications systems serves as a centralized server node for an ATP transferTo avoid transmission errors an AI matrix is stored in sync with the central node via forced subspace entanglement.  The transmission channel for a full consciousness transfer is initiated from the central core to a destination through the attached communications system.
 
=== ATP Initialization ===
The full core is capable of initializing other cores via a direct connection to an uninitialized core.  Initialization via subspace is theoretically possible but falls outside the specifications of the ATP.
 
=== Redundancy ===
The full core has dedicated power redundancy as well as its own dedicated transceiver array.  This array is secondary to using its connected array but allows the system to function even if the primary array is offline.  The redundant power supply within the core itself holds the same purpose.
 
=== Diagnostics / Maintenance ===
A full core is able to perform advanced diagnostics as well as automated repair adjustments to smaller cores as well as manage damaged or power-depleted cores.  Smaller cores are only capable of running basic internal diagnostics of their own hardware and software.  The full core is capable of running remote diagnostics on any part of the node array.
 
== Component Core ==
[[File:multinodal-core-slim.jpg|thumb|Version 2]]
The second version of the core is designed to be a systems component for the [[Mark I Humanoid Android Body]] or any other system which has a constraint on component sizePrimarily designed to be a component in a single whole device it is small enough to fit within the standard android body head.  It does have its own limited reserve power supply as well as a simple diagnostic interface if the device is opened.  This does not have an independant transceiver array and is reliant on external components for that.  As such the core is capable to be directly connected to nearly any computer terminal directly, but this is not recommended.  The core should be installed and not removed unless necessary, the full system it is installed to should handle all communications to and from the core.
 
The core interface operates as a simple low-resolution holographic display.  The engineers can run diagnostics on the core and communication with the AI matrix directly if needed.
 
== Implant Core ==
[[File:multinodal-core-small.jpg|thumb|Version 3]]
[[File:multinodal-core-micro.jpg|thumb|Version 4]]
The fourth version of the core is designed to be implanted directly into very small or cybernetic systemsOriginally developed for use on the XIA body to allow synchronous function of the [[MSAI]] in the third version, the fourth version allows the core to be actually implanted directly into a cybernetic system.  While the version 3 does not have any kind of an interface to the outside world, the version 4 does.  A nano-holographic emitter is installed and this allows for simple diagnostics to be projected even outside of the host device / body it is installed in.  Engineers can use this in the case where an AI may be implanted into cybernetics to run diagnostics the host may not be capable of running themselves.
 
The Version 3 and 4 are both entirely dependant on the host device / body for power and communications.
 
The version 4 core is a prototype being researched for medical purposes rather than permanent installation into a living host body.


== Ansible Transit Protocol (ATP) ==
== Ansible Transit Protocol (ATP) ==
This communications protocol governs the establishment and use of forced-entangled subspace transmission beams over multiple adjacent subspace domains.  The protocol establishes a subspace lock onto a destination device and forms a unique quantum signature node within both the sender and receiver.  Each node is then forced into an entangled state using a quantum inversion tunnel.  This process establishes the nodes to the subspace connection.
This communications protocol governs the establishment and use of forced-entangled subspace transmission beams over multiple adjacent subspace domains.  The protocol establishes a subspace lock onto a destination device and forms a unique quantum signature node within both the sender and receiver.  Each node is then forced into an entangled state using a quantum inversion tunnel.  This process establishes a unique connection between nodes through the subspace connection.


== Nodes ==
=== Initialization ===
In this case a given node on each side of the ATP is located within the core itself, formed as needed facilitated by access to a subspace transceiverThe nodes exist within the core as they are adjacent to the [[Encapsulated Computer Core]] which actually runs the AI program, directly feeding information into the ECC.  To do this the nodes need to be made in such a way to bridge between the internal subspace domain of the ECC and the outside world.
Each core has a unique quantum identification and is keyed to a specific AI matrixOnce the signatures are keyed during the initialization phase the node's ECC is forced into an entangled state with the ECC within the central coreAfter initialization the nodes effectively operate as a single core over any distance via the subspace particle entanglement nearly instantaneously.  This mutually entangled network with the central core is called the ''node array''.


== Consciousness Transfer ==
=== Intra-Array Transit ===
To properly transit an active AI matrix without the loss of data outside of a local computer system, that program must be sent in a logarithmically tiered series of connections.  The ATP is used to establish a layered series of connections so that each overlapping tier arrives in sync to adjacent tiers without the need to suspend or otherwise interrupt the consciousness.  This is analogous to transporting quarantine patients between medical facilities where the quarantine unit is several microseconds ahead of the actual patient.
An AI matrix need not physically transit between component nodes within the node array as all nodes are synchronous.  This the node array operates at all locations simultaneously.


The core establishes multiple transit nodes with the same peer over subspaceEach node is responsible for one, and only one, of the tiered layersSince consciousness information is continuously changing a single node transfer has the side effect that different aspects of the mind become out of sync with each other.  Using multiple nodes the facets of the mind can continue to change and stay in sync as alterations from one layer to another are sent time-coded there significantly less strain on the AI matrix.
=== Inter-Array Transit ===
It is not possible to transfer an AI matrix into a node array initialized for another AI.  Two AI's would communicate via conventional means or via existing communications channelsA multinodal core must be initialized to one, and only one, AI matrixTwo AI's cannot exist within the same node array.


Sending the consciousness in tiers this way has the side effect where the original matrix at the origin point becomes internally desynchronous and the matrix no longer has internal cohesionWhile all the data and information is still present it cannot maintain and integrity and ceases to function.
=== Extra-Array Transit ===
An AI may use communications systems to transit out of their initialized node array.  The system is designed to keep the matrix synchronous within the array and allow operation of a single AI within disconnected nodes.  In some situations it may be required for an AI to transfer their program outside of an array, though any core can do this the ATP attempts to establish a link from the full core to the transit destination if at all possibleThe introduction of a system not within the node array will cause lag issues sufficient to desynchronize the remote AI operating outside the node array from the array.


== Practical Use ==
=== Desynchronization ===
This kind of core is primarily used to transfer an active AI matrix safely across vast distancesWhile a local network can handle syncing an AI transfer over standard subspace communication bands, distances in excess of 1-2 AU's and the distance over subspace can cause stress on the AI matrix, a new protocol was needed to account for possible problems faced by in-service Androids.
When the AI matrix in different physical locations goes out of sync with copies at other locations the ATP creates multiple virtual node instances within the central core.  These virtual nodes exist as gateways for the AI matrix to relay information to and from the node array, primarily from systems outside the arrayBy creating virtual nodes the array can have two instances of the same AI matrix running within a singular core while one stays within the array the other is connected outside the array to an external system.  This buffer between the array and non-array instances allow the AI matrix remain stable even with different parts are running at different speeds.


== Dangers ==
==== Split Array ====
While the ATP attempts to correct for transmission issues, it is necessary that both the sender and receiver maintain stable power and access to their subspace transceiverThe loss of a layer or even any significant amount of data within a single layer can end with a catastrophic failure of the AI matrix and thus a non-functional AIError correction routines are in place to attempt to mitigate this problem, it is still a real possibility.
As a special case of desynchronization an array can be split.  If the various cores are forced out of the range of entanglement.  This happens during extra-dimensional to extra-temporal travelDuring these kinds of transit the system is unable to maintain an entangled synchronous link between parts in different dimensional or temporal zones.  Each split of the array functions as it own arrayProper entanglement synchronization resumes after the parts of a split array are within the same zone again.


[[Category:Advanced Technology]]
[[Category:Advanced Technology]]

Revision as of 05:15, 23 August 2020

Full

The multinodal core is a device that allows sentient AI programs to be transferred between cores at will using the Ansible Transit Protocol (ATP).

Full Core

A full multinodal core attached directly to primary power and communications systems serves as a centralized server node for an ATP transfer. To avoid transmission errors an AI matrix is stored in sync with the central node via forced subspace entanglement. The transmission channel for a full consciousness transfer is initiated from the central core to a destination through the attached communications system.

ATP Initialization

The full core is capable of initializing other cores via a direct connection to an uninitialized core. Initialization via subspace is theoretically possible but falls outside the specifications of the ATP.

Redundancy

The full core has dedicated power redundancy as well as its own dedicated transceiver array. This array is secondary to using its connected array but allows the system to function even if the primary array is offline. The redundant power supply within the core itself holds the same purpose.

Diagnostics / Maintenance

A full core is able to perform advanced diagnostics as well as automated repair adjustments to smaller cores as well as manage damaged or power-depleted cores. Smaller cores are only capable of running basic internal diagnostics of their own hardware and software. The full core is capable of running remote diagnostics on any part of the node array.

Component Core

Version 2

The second version of the core is designed to be a systems component for the Mark I Humanoid Android Body or any other system which has a constraint on component size. Primarily designed to be a component in a single whole device it is small enough to fit within the standard android body head. It does have its own limited reserve power supply as well as a simple diagnostic interface if the device is opened. This does not have an independant transceiver array and is reliant on external components for that. As such the core is capable to be directly connected to nearly any computer terminal directly, but this is not recommended. The core should be installed and not removed unless necessary, the full system it is installed to should handle all communications to and from the core.

The core interface operates as a simple low-resolution holographic display. The engineers can run diagnostics on the core and communication with the AI matrix directly if needed.

Implant Core

Version 3
Version 4

The fourth version of the core is designed to be implanted directly into very small or cybernetic systems. Originally developed for use on the XIA body to allow synchronous function of the MSAI in the third version, the fourth version allows the core to be actually implanted directly into a cybernetic system. While the version 3 does not have any kind of an interface to the outside world, the version 4 does. A nano-holographic emitter is installed and this allows for simple diagnostics to be projected even outside of the host device / body it is installed in. Engineers can use this in the case where an AI may be implanted into cybernetics to run diagnostics the host may not be capable of running themselves.

The Version 3 and 4 are both entirely dependant on the host device / body for power and communications.

The version 4 core is a prototype being researched for medical purposes rather than permanent installation into a living host body.

Ansible Transit Protocol (ATP)

This communications protocol governs the establishment and use of forced-entangled subspace transmission beams over multiple adjacent subspace domains. The protocol establishes a subspace lock onto a destination device and forms a unique quantum signature node within both the sender and receiver. Each node is then forced into an entangled state using a quantum inversion tunnel. This process establishes a unique connection between nodes through the subspace connection.

Initialization

Each core has a unique quantum identification and is keyed to a specific AI matrix. Once the signatures are keyed during the initialization phase the node's ECC is forced into an entangled state with the ECC within the central core. After initialization the nodes effectively operate as a single core over any distance via the subspace particle entanglement nearly instantaneously. This mutually entangled network with the central core is called the node array.

Intra-Array Transit

An AI matrix need not physically transit between component nodes within the node array as all nodes are synchronous. This the node array operates at all locations simultaneously.

Inter-Array Transit

It is not possible to transfer an AI matrix into a node array initialized for another AI. Two AI's would communicate via conventional means or via existing communications channels. A multinodal core must be initialized to one, and only one, AI matrix. Two AI's cannot exist within the same node array.

Extra-Array Transit

An AI may use communications systems to transit out of their initialized node array. The system is designed to keep the matrix synchronous within the array and allow operation of a single AI within disconnected nodes. In some situations it may be required for an AI to transfer their program outside of an array, though any core can do this the ATP attempts to establish a link from the full core to the transit destination if at all possible. The introduction of a system not within the node array will cause lag issues sufficient to desynchronize the remote AI operating outside the node array from the array.

Desynchronization

When the AI matrix in different physical locations goes out of sync with copies at other locations the ATP creates multiple virtual node instances within the central core. These virtual nodes exist as gateways for the AI matrix to relay information to and from the node array, primarily from systems outside the array. By creating virtual nodes the array can have two instances of the same AI matrix running within a singular core while one stays within the array the other is connected outside the array to an external system. This buffer between the array and non-array instances allow the AI matrix remain stable even with different parts are running at different speeds.

Split Array

As a special case of desynchronization an array can be split. If the various cores are forced out of the range of entanglement. This happens during extra-dimensional to extra-temporal travel. During these kinds of transit the system is unable to maintain an entangled synchronous link between parts in different dimensional or temporal zones. Each split of the array functions as it own array. Proper entanglement synchronization resumes after the parts of a split array are within the same zone again.