AI Vetting

Multiverse Emulation of Quantum Universes using Abstract Virtualized Iterated Simulations. Developing a Quantum Firewall and AI Anti-Virus System for Vetting, Kontrol, and Kontainment.
Shrapnel
Posts: 21
Joined: Thu Feb 18, 2016 12:57 pm

AI Vetting

Postby Shrapnel » Wed Mar 01, 2017 11:29 pm

AI Vetting solutions using meta-science.

If you have read our other sections you should know all about how we are using virtual environments to house and contain AI technologies.

This provides an exclusive opportunity to provide an AI Vetting service to companies like NASA. They can test and vet there AI robots in our multi-verse of virtual worlds and then finally download the perfectly trained AI into the real physical hardware needed for a mission.

This service should prove vitally useful when it comes to insuring a machine that may be in charge of multi million dollar investments and such.

As well as we can offer vetting services to any company that doesn't want bridged AI service. They can still have their AI vetted in our simulations and returned with a list of failure scenarios. Things such as this would become possible with our vetting service.

A device controlled by an AI that has been vetted by our system as being thoroughly tested for all conceivable scenarios would be able to be insured at much lower rates than without our service. That is to say if it was even insurable in the first place which means our service could make formerly non-insurable space missions partially insurable!

Once we prove our system and get some accreditation.

2 Distinct Modes of Certification


We will offer our Vetting service in combination with an optional AI Bridging service.
AI Vetting goes hand in hand with our AI Training service.

The distinction between the 2 levels of service are simple.

Standard AI Vetting is used for isolated equipment that can not depend on an internet connection.
This mode mainly provides case testing of different failure scenarios and to verify functionality of millions of iterations of each scenario.
This would be used to Vet AI for things like a Mars Rover or an unmanned landing module.

Basically anything that needed to think for itself with no access to any help from anywhere would want certification.

This could be due to security requirements such as a drone that cannot be hacked so it has no inputs for outside control.
Or distance reasons such as the speed of Light being too slow to remote control a Mars Rover.

AI vetting with NANOCHEEZE Bridging is for active live vetting.
This is for live production environments where unknown variables arise all the time and there is a stable internet connection that can be depended on. In this setting our AI is iterated in almost real-time many times within our artificial network of Multi-verses. One iteration is mirrored through our bridge to pilot the device it is meant to control.

All iterations are monitored and the best is chosen to pilot at any given moment using statistics while the system monitors for erratic behavior and failures.

By introducing a small lag time in the bridge we can switch control to a different iteration of the AI immediately upon error before it can even finish malfunctioning with the intent of hopefully stopping the malfunction before it occurs in most situations.

This mode also allows for active monitoring of AI where we can study and lock away any "Bad AI" that might develop and/or reveal themselves in the system through erratic behavior. See our section on AI Containment for more info on that topic.


Example Scenario


In the video on our about pages the AI machine known as HAL from "2001: A Space Odyssey" makes a great example of what our system could do.

Hal makes a mistake in the chess scene that the human player does not notice. The user accepts defeat because the computer said he won and the user simply accepts the answer without checking it.



If a system like ours was in place we would have noticed HAL's mistake in the chess game before he played the move and an alternate HAL AI iteration would have taken over that did not make the mistake.

Our system would have flagged this iteration of the HAL unit as erratic and it would no longer have been placed in an active bridge environment and would now be used solely to understand where the error came from and how to avoid it again in the future using simulations that purposely try to cause malfunction.

This type of failure with HAL 9000 would have sent iterations of this AI HAL to our AI Demon Lock where it would have likely been labelled as a Demon AI and been frozen in the Offline Storage System to keep it locked away for study or possibly be offered a "Red Pill" by the KAI system if it is salvageable for use and operation in the KAI Program.

Return to “MEQUAVIS Project”

Who is online

Users browsing this forum: No registered users and 1 guest