Format Negotiation

One of the benefits of using the Normalisation Engine is format negotiation.

Negotiation allows connection between AIs and your data, even when the layout of that data changes over time.

Imagine you've created and trained an AI on a specific set of data, learned from an ARDI asset in Cognition.

But after an upgrade, you've got new properties on your machine. And those properties are now coming in along with your existing inputs. What began as an input with this format…

Temperature, Pressure, Mode, Speed

now has changed to this…

Temperature, Pressure, Level, Mode, Speed

Along with the change in ordering, there's also been adjustments to the range of the temperature sensor and a new mode has been added to the machine.

But we haven't re-trained our AI yet. So we need a mechanism to allow our new data format to work with our existing AI.

With negotiation, these two can still effectively communicate.

In the above scenario, the new data from the hosting application (the application feeding data to the AI) has the format…

Temperature>A=0|75:Pressure>A=0|1200:Level>A=0|100:Mode>D=0|1|2|5:Speed>A=0|1200

The old AI has the previous version of this format, below…

Temperature>A=0|50:Pressure>A=0|1200:Mode>D=0|1|2:Speed>A=0|1200

Using negotiation, we end up with the modified format…

0>A=0|50:1>A=0|1200:2>D=0|1|2:4>A=0|1200

In this case, it's largely the original (ie. AI) format, but with the channel numbers modified to deal with the fact that the speed input has shifted position.

As an example of it being actually run, the hosting app could have the original input…

[20,1200,85,2,65]

According to its new format, the matching output should be [0.26,1.00,0.85,0,0,1,0,0.05] - eight outputs, with a temperature of 0.26.

The negotiated output however is different. [0.40,1.00,0,0,1,0.05] - six outputs with the temperature at 0.4.

Differences with ordering, range and availability are dealt with during the negotiation process, allowing you to continue to use older AIs in changing environments.