Multinodal Core - Revision history

Cyclops at 04:25, 7 June 2023

2023-06-07T04:25:15Z

Cyclops at 18:37, 18 May 2022

2022-05-18T18:37:37Z

← Older revision		Revision as of 18:37, 18 May 2022
Line 3:		Line 3:
	[[File:multinodal-core-small.jpg\|thumb\|Version 3]]		[[File:multinodal-core-small.jpg\|thumb\|Version 3]]
	[[File:multinodal-core-micro.jpg\|thumb\|Version 4]]		[[File:multinodal-core-micro.jpg\|thumb\|Version 4]]
	The multinodal core is designed to allow an AI to operate synchronously between multiple devices which are not physically connected with a near-zero lag time between different nodes receiving updated information.		The multinodal core is designed to allow an AI to operate synchronously between multiple devices which are not physically connected with a near-zero lag time between different nodes receiving updated information. To facilitate this a new communications protocol called the [[Ansible Transit Protocol]] or ATP.

	== Full Core ==		== 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. In addition the full core has fully a fully integrated holographic projection system, it allows an installed AI matrix to directly project itself or any data it wishes in the local area directly from the core itself.		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. In addition the full core has fully a fully integrated holographic projection system, it allows an installed AI matrix to directly project itself or any data it wishes in the local area directly from the core itself.

	=== ~~ATP~~ Initialization ===		=== Ansible 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~~.		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 protocol.

	=== Redundancy ===		=== Redundancy ===
Line 31:		Line 31:
	== Consciousness Focus ==		== Consciousness Focus ==
	Some AI matrices may find it difficult to operate multiple node locations simultaneously. The system is not designed to allow an AI to operate in an omnipresent way, though it can be used for that purpose. Instead the system is designed to allow an AI to seamlessly switch between different node locations near-instantaneously from any distance. Different AI capabilities and complexities will have different abilities to operate multiple instances of themselves within the same matrix.		Some AI matrices may find it difficult to operate multiple node locations simultaneously. The system is not designed to allow an AI to operate in an omnipresent way, though it can be used for that purpose. Instead the system is designed to allow an AI to seamlessly switch between different node locations near-instantaneously from any distance. Different AI capabilities and complexities will have different abilities to operate multiple instances of themselves within the same matrix.

	~~== Ansible Transit Protocol (ATP) ==~~
	This communications protocol governs the establishment and use of forced-entangled subspace transmission beams over multiple adjacent [[Subspace Domains\|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. Thus 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. Any core attached directly, via physical connection, to another computer system should not suffer desynchronization unless the connection quality or stability is low.

	~~==== 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 or 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. Entanglement persists even when parts of the array are out of range, though the node network is unable to operate synchronously until the formerly split parts are brought back in range.

	~~==== Temporal Synchronicity ====~~
	A split array has a danger that when two parts of the array come within entangled range but are outside of their origin time zone they can resync, so long as the node array components are functioning. This happens when a node array is split due to extra-temporal travel and one part of the array is at a different point along the same timeline as another part which both exist at the same time and within the same region of space-time. While normally the array will not resynchronize with an array from a previous point along its own timestream to avoid causality problems, this is a safety protocol in place of the ATP and is not an given. If this safety protocol is disabled in some way or fails to successfully maintain a split array, both arrays will rejoin into a complete array.

	The protocol is designed to handle extra-temporal information exchange but problems can develop. Both sides of the split array do restore their singular array state, leaving the network segmented in software. Should this protection fail or be disabled a causality problem could develop. The previous stage of the same AI could become aware of future events which then could change the outcome of those same future events.

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

Cyclops: /* Split Array */

2020-12-19T20:24:59Z

Split Array

← Older revision		Revision as of 20:24, 19 December 2020
Line 51:		Line 51:

	==== Split Array ====		==== 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~~.		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 or 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. Entanglement persists even when parts of the array are out of range, though the node network is unable to operate synchronously until the formerly split parts are brought back in range.

			==== Temporal Synchronicity ====
			A split array has a danger that when two parts of the array come within entangled range but are outside of their origin time zone they can resync, so long as the node array components are functioning. This happens when a node array is split due to extra-temporal travel and one part of the array is at a different point along the same timeline as another part which both exist at the same time and within the same region of space-time. While normally the array will not resynchronize with an array from a previous point along its own timestream to avoid causality problems, this is a safety protocol in place of the ATP and is not an given. If this safety protocol is disabled in some way or fails to successfully maintain a split array, both arrays will rejoin into a complete array.

			The protocol is designed to handle extra-temporal information exchange but problems can develop. Both sides of the split array do restore their singular array state, leaving the network segmented in software. Should this protection fail or be disabled a causality problem could develop. The previous stage of the same AI could become aware of future events which then could change the outcome of those same future events.

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

Cyclops: /* Intra-Array Transit */

2020-12-19T20:16:21Z

Intra-Array Transit

← Older revision		Revision as of 20:16, 19 December 2020
Line 39:		Line 39:

	=== Intra-Array Transit ===		=== 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.		An AI matrix need not physically transit between component nodes within the node array as all nodes are synchronous. Thus the node array operates at all locations simultaneously.

	=== Inter-Array Transit ===		=== Inter-Array Transit ===

Cyclops: /* Component Core */

2020-12-19T20:11:18Z

Component Core

← Older revision		Revision as of 20:11, 19 December 2020
Line 18:		Line 18:

	== Component Core ==		== Component Core ==
	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 second and third versions of the core are 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.		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.

Cyclops at 04:47, 24 August 2020

2020-08-24T04:47:58Z

← Older revision		Revision as of 04:47, 24 August 2020
Line 6:		Line 6:

	== Full Core ==		== 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.		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. In addition the full core has fully a fully integrated holographic projection system, it allows an installed AI matrix to directly project itself or any data it wishes in the local area directly from the core itself.

	=== ATP Initialization ===		=== ATP Initialization ===
Line 48:		Line 48:

	=== Desynchronization ===		=== 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.		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. Any core attached directly, via physical connection, to another computer system should not suffer desynchronization unless the connection quality or stability is low.

	==== Split Array ====		==== Split Array ====

Cyclops at 05:22, 23 August 2020

2020-08-23T05:22:48Z

← Older revision		Revision as of 05:22, 23 August 2020
Line 3:		Line 3:
	[[File:multinodal-core-small.jpg\|thumb\|Version 3]]		[[File:multinodal-core-small.jpg\|thumb\|Version 3]]
	[[File:multinodal-core-micro.jpg\|thumb\|Version 4]]		[[File:multinodal-core-micro.jpg\|thumb\|Version 4]]
	The multinodal core is ~~a device that allows sentient~~ AI ~~programs~~ to ~~be transferred~~ between ~~cores at will using the Ansible Transit Protocol (ATP)~~.		The multinodal core is designed to allow an AI to operate synchronously between multiple devices which are not physically connected with a near-zero lag time between different nodes receiving updated information.

	== Full Core ==		== Full Core ==
Line 28:		Line 28:

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

			== Consciousness Focus ==
			Some AI matrices may find it difficult to operate multiple node locations simultaneously. The system is not designed to allow an AI to operate in an omnipresent way, though it can be used for that purpose. Instead the system is designed to allow an AI to seamlessly switch between different node locations near-instantaneously from any distance. Different AI capabilities and complexities will have different abilities to operate multiple instances of themselves within the same matrix.

	== Ansible Transit Protocol (ATP) ==		== Ansible Transit Protocol (ATP) ==

Cyclops at 05:17, 23 August 2020

2020-08-23T05:17:56Z

← Older revision		Revision as of 05:17, 23 August 2020
Line 1:		Line 1:
	[[File:{{#setmainimage:multinodal-core-full.jpg}}\|thumb\|Full]]		[[File:{{#setmainimage:multinodal-core-full.jpg}}\|thumb\|Full (Version 1)]]
			[[File:multinodal-core-slim.jpg\|thumb\|Version 2]]
			[[File:multinodal-core-small.jpg\|thumb\|Version 3]]
			[[File:multinodal-core-micro.jpg\|thumb\|Version 4]]
	The multinodal core is a device that allows sentient AI programs to be transferred between cores at will using the Ansible Transit Protocol (ATP).		The multinodal core is a device that allows sentient AI programs to be transferred between cores at will using the Ansible Transit Protocol (ATP).

Line 15:		Line 18:

	== Component Core ==		== 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 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 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.

Line 21:		Line 23:

	== Implant Core ==		== 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 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 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.

Line 30:		Line 30:

	== 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 a unique connection between nodes through the subspace connection.		This communications protocol governs the establishment and use of forced-entangled subspace transmission beams over multiple adjacent [[Subspace Domains\|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 ===		=== Initialization ===

Cyclops at 05:15, 23 August 2020

2020-08-23T05:15:19Z

← Older revision		Revision as of 05:15, 23 August 2020
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 century~~. ~~The Ansible Transit Protocol uses~~ a ~~forced quantum entanglement between subspace nodes over~~ a ~~domain similar~~ to that of a [[~~transporter~~]] ~~beam~~. ~~The 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 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 ==
			[[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 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 ==
			[[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 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) ==		== 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 transceiver~~. ~~The 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 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''.

	== ~~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 subspace~~. ~~Each node is responsible for~~ one, and only one, ~~of the tiered layers~~. ~~Since 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 channels. A multinodal core must be initialized to one, and only one, AI matrix. Two 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 cohesion~~. ~~While 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 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.

	== ~~Practical Use~~ ==		=== Desynchronization ===
	~~This kind~~ of core ~~is primarily used to transfer an active~~ AI matrix ~~safely across vast distances~~. ~~While 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 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.

	== ~~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 transceiver~~. ~~The 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 AI~~. ~~Error 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 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.

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

Cyclops: Removed redirect to Mark I Humanoid Android Body#Multinodal Core

2020-03-18T04:11:17Z

Removed redirect to Mark I Humanoid Android Body#Multinodal Core

← Older revision		Revision as of 04:11, 18 March 2020
Line 1:		Line 1:
	~~#REDIRECT~~ [[~~Mark I Humanoid Android Body#Multinodal~~ Core]]		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 century. The Ansible Transit Protocol uses a forced quantum entanglement between subspace nodes over a domain similar to that of a [[transporter]] beam. The idea first came from a study of how Borg technology is able to maintain the collective consciousness over such vast distances.

			== 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.

			== Nodes ==
			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 transceiver. The 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.

			== Consciousness Transfer ==
			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.

			The core establishes multiple transit nodes with the same peer over subspace. Each node is responsible for one, and only one, of the tiered layers. Since 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.

			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 cohesion. While all the data and information is still present it cannot maintain and integrity and ceases to function.

			== Practical Use ==
			This kind of core is primarily used to transfer an active AI matrix safely across vast distances. While 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.

			== Dangers ==
			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 transceiver. The 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 AI. Error correction routines are in place to attempt to mitigate this problem, it is still a real possibility.

			[[Category:Advanced Technology]]

← Older revision		Revision as of 04:25, 7 June 2023
Line 3:		Line 3:
	[[File:multinodal-core-small.jpg\|thumb\|Version 3]]		[[File:multinodal-core-small.jpg\|thumb\|Version 3]]
	[[File:multinodal-core-micro.jpg\|thumb\|Version 4]]		[[File:multinodal-core-micro.jpg\|thumb\|Version 4]]
	The multinodal core is designed to allow an AI to operate synchronously between multiple devices ~~which~~ are not physically connected with a near-zero lag time between different nodes receiving updated information. To facilitate this a new communications protocol called the [[Ansible Transit Protocol]] or ATP.		The multinodal core is designed to allow an AI to operate synchronously between multiple devices that are not physically connected, with a near-zero lag time between different nodes receiving updated information. To facilitate this, a new communications protocol called the [[Ansible Transit Protocol]] or ATP has been developed.

	== Full Core ==		== 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. ~~In addition~~ the full core ~~has fully~~ a fully integrated holographic projection system, ~~it allows~~ an installed AI matrix to directly project itself or any data ~~it wishes~~ in the local area ~~directly from the core itself~~.		A full multinodal core, directly attached to primary power and communications systems, serves as a centralized server node for 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. Additionally, the full core is equipped with a fully integrated holographic projection system, allowing an installed AI matrix to directly project itself or any desired data in the local area.

	=== Ansible Initialization ===		=== Ansible 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 protocol~~.		The full core is capable of initializing other cores through a direct connection to an uninitialized core. Initialization via subspace is theoretically possible but falls outside the protocol's specifications.

	=== Redundancy ===		=== 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.		The full core has dedicated power redundancy, as well as its own transceiver array. This array serves as a backup to the connected array, ensuring system functionality even if the primary array is offline. Similarly, the redundant power supply within the core itself serves the same purpose.

	=== Diagnostics / Maintenance ===		=== 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.		A full core can perform advanced diagnostics, automated repair adjustments to smaller cores, and manage damaged or power-depleted cores. Smaller cores are only capable of running basic internal diagnostics on their own hardware and software. The full core can run remote diagnostics on any part of the node array.

	== Component Core ==		== Component Core ==
	The second and third versions of the core are 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 second and third versions of the core are designed to be system components for the [[Mark I Humanoid Android Body]] or any other system with size constraints. Primarily intended to be integrated into a single device, they are small enough to fit within the standard android body head. They have their own limited reserve power supply and a simple diagnostic interface if the device is opened. However, they lack an independent transceiver array and rely on external components for that purpose. Although the core can be directly connected to almost any computer terminal, it is not recommended. The core should be installed and not removed unless necessary, as the full system it is installed in 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~~.		The core interface operates as a simple low-resolution holographic display. Engineers can run diagnostics on the core and communicate directly with the AI matrix when necessary.

	== Implant Core ==		== Implant Core ==
	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 fourth version of the core is designed for direct implantation into very small or cybernetic systems. Initially developed for use in the XIA body to enable synchronous function of the third version's [[MSAI]], the fourth version allows the core to be implanted directly into a cybernetic system. Unlike the third version, the fourth version has an interface to the outside world. It features a nano-holographic emitter that enables simple diagnostics to be projected even outside the host device or body in which it is installed. Engineers can use this capability when an AI may be implanted into cybernetics to run diagnostics that 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.		Both Version 3 and 4 cores rely entirely on the host device or 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.		The Version 4 core is a prototype being researched for medical purposes rather than permanent installation into a living host body.

	== Consciousness Focus ==		== Consciousness Focus ==
	Some AI matrices may find it ~~difficult~~ to operate multiple node locations simultaneously. The system is not designed to allow an AI to operate in an omnipresent way, ~~though~~ it can be used for that purpose. Instead the system is designed to ~~allow~~ an AI to seamlessly switch between different node locations near-instantaneously from any distance. ~~Different~~ AI capabilities and complexities ~~will have different abilities~~ to operate multiple instances of themselves within the same matrix.		Some AI matrices may find it challenging to operate in multiple node locations simultaneously. The system is not designed to allow an AI to operate in an omnipresent way, although it can be used for that purpose. Instead, the system is designed to enable an AI to seamlessly switch between different node locations near-instantaneously from any distance. The ability of different AI capabilities and complexities to operate multiple instances of themselves within the same matrix may vary.

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