Evolution Assistant

[Mookse]

Evolution Assistant

Self-Contextualization via embedded Evolution Assistant

The objective is to establish a mechanism that allows a member to create an object, starting with a Human avatar, through an API. This creation process is independent of the front-end interface or access, which will be addressed separately. The avatar is designed to gain a certain level of contextual intelligence at birth (onBirth()), enabling it to self-evolve during a session. The envisioned architecture is dynamic, primarily relying on emitted events for its operation:

• Evolution Agent: This is a global, dynamic functional agent, akin to the planned implementation of a consent mechanism. It will be embedded within the avatar as a reference, which can be customized as needed. This architecture allows the Evolution Agent to have independent reactions and actions, not solely dependent on internal avatar events.
• Exclusive to Avatars: Initially, only avatars will be equipped with Evolution Agents. This ensures that the underlying data object remains secure and can interact reliably with its consent object. The consent object plays a crucial role in permitting, denying, or shaping interactions and data access.
• Data Security and Consent Management: The avatar's underlying data object is safeguarded and relies on its consent object to manage interactions. This consent mechanism could be pivotal in reviewing and modifying content that passes through the system, thereby maintaining the integrity and security of the data.

The architecture of the Evolution Agent is central to this system, providing a robust framework for the avatars to evolve and interact within the platform securely and intelligently.

Coding

• assess self for data voids
  • current logic status = crude w/o intelligence, any follow-on todo's not yet documented
• set this.#contributions inside Evolution Assistant
  • define() data - category defined, content empty
    • purpose is clear, get meaningful strategic content around category, given being of data (make sure this is correctly represented, and not avatar, no need to consult GPT (unless relying internal POSTGRES?)
  • refine() data - complex purpose, have category, being & content to explore for refinement
    • submit to GPT to seek data expansion or refinement, given content summary
• manage incorporation of posing of questions [optional, could be side-bar for now, managed by session) of member

Notes

• no routes currently published, but core architecture instantiated
• all context-building (or at least triggers) should only be available to the factory so that it can be isolated to the MyLife container id and so won't be charged back to member directly, considered a service of MyLife
  • create self-contextualizing object sandbox
  • route -> /members/{:mid}/objects/{:id[guid]}
    • no exists, add from post data
      • initially as simple as object name in English, and purpose (perhaps 'idle' as generic for now)
      • send to Maht (or cheaper) to contextualize, i.e., build categories
      • display category suggestions to user for edit?
      • manifest Avatar for
    • retrieve with consent
  • test