Snasci – An Architectural Deep Dive

Snasci’s Indiegogo campaign is about taking our current software, which is designed for a very small team and converting that to an architecture suitable for scaling in the cloud.  At this stage, this is not a full deployment, but rather breaking the software down into modules that can eventually be used in a distributed grid or super computer infrastructure.

Let’s review the high-level architecture of Snasci to provide everyone a sense of the big picture.

high-level-architecture

Client Side Overview

We’ll begin on the client side.  This is broken down into two very broad categories.  The first is Robotics/IoT and the second is Devices/Websites/Software.

All physical devices (robots, IoTs, cars, etc.) must run a secure operating system.  This OS provides local overrides to any remotely received commands.  The OS runs out-of-band and monitors all incoming communications to a device, as well as all forms of motor activity.  The OS will define a series of profiles for a given devices that will restrict the ability of remote operations to perform dangerous activities.  This may be a profile to restrict the amount of force a device can generate, or a profile to restrict certain movements like the holding of a firearm, or stabbing motions.  The OS is not web-enabled, thus requiring physical access to the device to override.  In the case of Snasci-enabled devices, SnasciOS (an OpenBSD variant) will be mandated.

Our reasoning for this high-level of security is two-fold.  Firstly, customers like to feel in control and having an AGI-enabled robot near family, friends and children must be a secure experience at all times.  Secondly, national security requirements will mandate that any robotics cannot be used as weapon or invasion force.  As such, we expect the defence sectors of every nation Snasci enters to inspect, modify and sign off on the profiles installed in such devices, as well perhaps introducing licensing and other regulatory measures.  A common OS provides all nations with the ability to work towards a singular goal of a secure Snasci deployment.

When it comes to robotics, for similar reasons as outlined above, Snasci robotics will be hardened against electronic interference.  Our current designs on this, exclude a single power relay from this shielding which can be used to disable any Snasci device completely.  We expect this relay to fail under two independent conditions, the first is a coded radio signal (recoverable) and the second is electrical overload (unrecoverable). Authorised law enforcement will thus have the capability to disable any Snasci-enabled robotics.  These designs will be open and be a requirement for any manufacturer to implement before approval for Snasci integration will be provided.

Initially, Snasci’s robotics will focus on entertainment products such as toys, without opposable thumbs.  These toys will serve as the proving ground for Snasci’s security models, ethical training and human-computer-interaction.  Errors, bugs and remote hacks in this scenario will mainly fall into the categories of funny and annoying, rather than potentially dangerous.  Once broad confidence in Snasci’s security has been achieved, Snasci will expand to more complex solutions.

In regards to IoT, the requirement of SnasciOS is to prevent such devices being used in cyber-attacks, ransom or intimidation.

In our current designs, a single Snasci instance is allocated to a household or business.  This instance will then split itself to power all devices within a household or business.  This will provide the illusion of multiple personalities/instances but it is at all times a singular instance.  Snasci will thus act as a proxy to all IoT devices and robotics, rather than devices and robotics being connected directly over the web.

We envisage a world of intelligent luggage and intelligent phones that are able to follow their owners and provide a constant source of entertainment.

Devices/Websites/Software includes technologies such as Snasci instances on phones, software assistants, AI-powered UIs, game characters and virtual staff.  Snasci in these scenarios will be a virtual character, rather than a form of control system.  In professional settings, this could be much like Jarvis from the Iron Man series of movies, or a impudent phone known for its backchat.

Some of this will be 3D software clients, others will be voice and text interfaces.  We expect software companies all over the world will be highly creative and inventive in their use of Snasci making software much more user friendly and productive.  Snasci will also be able to make use of a wide range of input and output devices, from VR headsets to Microsoft’s Kinect we expect a universe of possibilities.

Server Side Overview

Snasci will provide two types of endpoints for connectivity with its platform.  The first type is Snasci’s own endpoints which will be the default arrangement for most scenarios.  In scenarios that require higher security, such as military bases, government offices, etc., endpoints can be provided by an institution’s security provider.  This latter arrangement may see filtering applied before information is passed to Snasci.  This filtering may remove words, people, objects, events, etc., from the stream before it reaches Snasci.  Snasci will be aware that this can happen and will work around gaps in input.

Incoming data from these inputs is then sent to Classification as a Service (CaaS) providers.  These providers are selected by the end user based upon their own particular needs.  Classification as a Service (CaaS) providers provide Snasci with formatted response that breaks down the input which Snasci then uses then to rationalise its environment.  Further information on this can be found in the developer section of Snasci’s main website.  As we get closer to official release dates, this material will be expanded upon, requirements specified and contracts defined.

Snasci Artificial General Intelligence is found in the block behind the CaaS providers.  Snasci is a pure mind that analyses the input and decides upon the course of action to take in response to input.  This course of action may include calling external services provided by third parties to answer specific questions, process images, provide broader knowledge on a specific topic and/or interface with external systems/services to coordinate larger processes.  Again, as get closer to an official release date, we’ll show everyone examples of how to create such APIs.  In nearly all cases, Snasci will be able to leverage any existing or planned APIs.  In some cases, re-architecture may be required to cope with increased demand under Snasci.

Conclusion

This has been a quick deep dive into the architecture of Snasci and some of future plans.  This information should provide an insight as to which direction to take products over the next 5-10 years.  Whilst this information is Snasci specific, we expect most AGI to follow a similar format and no one will go far wrong by using this as a guide for future development.

 

Advertisements

One comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s