プロダクションシステム
単純なシミュレーション世界で、部屋の中の猿が他のオブジェクトをつかんだり、その上に登ったりできるとする。以下の例は天井からつるされたオブジェクトをつかむプロダクションルールである。
この例では、ワーキングメモリ内のデータは構造化されており、変数は山括弧で囲まれて示される。"goal" や "physical-object" といったデータ構造名は条件部の最初のリテラルである。データ構造のフィールド名には "^" がプレフィックスとして付いている。"-" は条件の否定を表す。
OPS5 のプロダクションルールは、条件に適合し変数束縛を満たす全てのデータ構造のインスタンスに適用される。この例では天井からつるされたオブジェクトがいくつか存在し、手ぶらの猿の近くにはしごがあった場合、プロダクションルール "Holds::Object-Ceiling" からプロダクションルールのインスタンスが多数生成され、それらが競合集合となる。競合解消ステップでそれらインスタンスから点火すべきプロダクションインスタンスを選択する。
条件部でパターンマッチによって変数束縛された結果がアクション部で更新されたデータを参照するために使用される点に注意されたい。また、ワーキングメモリには「ゴール」データ構造のインスタンスの形で明確な制御構造データを含んでいる。この例では、猿がつるされたオブジェクトをつかんだら、ゴールの状態は満たされ、同じプロダクションルールは最初の条件が偽となるために必ず失敗する。
規則インタプリタは前向き連鎖アルゴリズムを実行して実行するプロダクションを選択していき、とりあえずのゴールを目指す。ゴールとは、システムデータの更新だったり、信念の更新だったりする。規則の条件部をワーキングメモリ内の現在状態に照らして調べる。
理想的(あるいはデータ指向)プロダクションシステムでは、始動されるべき条件は全て実行されるべきであるという仮定がある。対応するアクションがエージェントの知識を更新し、ワーキングメモリにデータを追加したり、削除したりする。システムが処理を停止するのは、前向き連鎖ループにユーザーが割り込んだとき、事前に設定された回数のアクションを実行したとき、アクションとして「停止」が指定されていたとき、条件部が真となるプロダクションが存在しないときである。
一方、リアルタイム指向のプロダクションシステムやエキスパートシステムでは、しばしば相互排他的なプロダクションから選択しなければならない。アクションは時間がかかるので、1つのアクションしか実行できないか、(特にエキスパートシステムでは)単に推奨するだけに留める。そのようなシステムの規則インタプリタ(あるいは推論エンジン)は2つのステップからなるサイクルを実行する。データベースとプロダクションルールの照合をするステップと、マッチングしたルールからアクション部を実行するものを選択して実行するステップである。