While the Generic Frame Protocol necessarily imposes some common requirements on the organization of knowledge (KBs, frames, slots, facets) and semantics of some assertions (instance and subclass relationships, inherited slot values, slot constraints), it allows for some variety in the behavior of underlying FRSs. The protocol achieves this heterogeneity by parameterizing FRSs themselves, providing an explicit model of the properties of FRSs that may vary. We call these properties FRS behaviors. An application can ask for the behavior profile of an FRS, and adapt itself accordingly. An application can also declare what behaviors it requires, and abort processing if some behaviors are not available.
An FRS behavior describes how a particular FRS behaves on some dimension. For example, to find out how a FRS does slot value constraint checking, one can ask for the FRS behavior called :constraint-checking and be told a value such as :immediate, :never, or :deferred-reporting. The set of behaviors defined for FRSs is specified in Chapter 4. FRS behaviors are assumed to be constant over all KBs loaded onto that FRS.