Unless noted otherwise, everything below can be altered dynamically at runtime and/or generated.

• Contains a set of Attributes and Interactions
• Can be polled to perform an Interaction
• Each poll, evaluates which Interaction to perform with which target(s) via a scoring function
• Reacts to and observes other Interactions by triggering Effects

• The Attributes and Interactions are actually stored in a Repository (see below)
• The abstract scoring method Score(interaction, targets) returns a float--the Interaction and target combo with the highest score is performed in Poll()
• Possible targets are determined via the virtual Targets(interaction) method
• The virtual Reaction(interaction, host) and Observation(interaction, host, targets) methods should evaluate their return values (Effects to perform) based on the relative difference between self, host, and target Attributes (among other metrics); by default, they return null (no effect)
• Example extension

• Attribute prototypes describe how to instantiate and maintain a particular Attribute
• Attribute instances are tied to a specific Entity
• A prototype contains a function describing an instance's initial state, as well as a descriptor of how to access and modify an instance's internal state

• The initial value function can e.g. return a constant, or a random value from a distribution
• The framework contains a concrete prototype, NormalizedAttribute (extends Attribute<float>), which limits instance state to values between 0 and 1
• See modules/float

• Every Interaction has one host Entity (the initiator) and zero or more target Entities
• A self-interaction is host-only, with zero targets
• Triggers reactions on host and target(s)
• Triggers observations on observers

• Observers are determined via the virtual Observers(host, targets) method

• Result of reaction or observation
• Triggers a number of Modifiers

• Tied to a specific Attribute
• Offsets an Attribute state by a specific value
• The abstract Modify(instance) method allows for complex modifications when extending

• Set of Attributes and Interactions
• Every Entity has a local Repository, which can point to a "global" instance if necessary
• (IRepository)

• Repository implementations usually contain additional domain-specific data and act as a reference point for a system
• When an Entity Subscribe's to a Repository, it instantiates the Attribute prototypes from the Repository's reference pool
• Inter-repo operations will not break the system (e.g. if a particular target Entity does not have the Attribute specified in an Effect Modifier, nothing will happen)

• Set of Entities

• Can have multiple Universes

Beforehand, Entities and one or more Repositories (generally Attributes, Interactions, Effects/Modifiers) may be created or generated, after which each Entity subscribes to a Repository and/or joins a Universe if desired. These can also evolve at runtime.

1. An Entity is polled
2. The Entity determines which Entities to target and which Interaction to perform
3. The Interaction chosen triggers reactions on the host and target(s), and observations on the observers
4. Each reaction/observation is evaluated at the Entity level, triggering a number of Effects
5. Each Effect modifies a number of Attributes on the reacting/observing Entity via its Modifiers

This certainly does not describe every possibility within a given implementation, just a general description of the core logic. The framework permits considerable modification, and is built to be extended to specific domains with unique subsystems.