Breakdown of the iACEui demo

[GWSzeto]

Looked over the code in the iACEui project and wanted to do a writeup of my understanding of the key pieces, how the project is setup and how it runs

Key Pieces

There are 3 main services that drive the ACE Framework and the Frontend to help setup the system.

The 3 main services are Postgres DB, RabbitMQ and the API, all of which are orchestrated through docker compose

The Postgres DB is responsible for storing the identity, reasoning ad ancestral prompts, which serve as the system messages along with the control bus and data bus prompts, which serve as rules for the LLM to follow

RabbitMQ serves as the pipeline for the control and data busses, where the messages are passed between each layer. To allow for the messages to be passed through the layers properly, each layer is responsible for handling 4 messaging queues. 2 queues subscribed for messages from the data bus and control busses and 2 queues for publishing messages to the data and control busses. The subscribed data queue receives messages from the lower layer while the subscribed control queue receives messages from the upper layer. For the publisher counter part, it is vice versa

The API has multiple types of endpoints, ranging from starting, testing and setting/getting the prompts for the system.

How it's setup

On initial setup, the Svelte frontend is served to allow the user to set the identity, reasoning, ancestral, control bus and data bus prompts through the API, thus populating the postgres DB.

Once the DB has been populated, the system is then ready to be started through the /mission endpoint

How it runs

The system starts through the /mission endpoint in the API, where the mission statement is published to the aspirational layer

The aspirational layer receives the message through the subscribed control bus queue. Then using the message along with using the identity, reasoning and ancestral prompts as the system messages, it generates a reasoning about the message sent in.

Then using both the message and the reasoning generated along with only just the identity and ancestral prompts as the system message, it generates data and control messages separately for the publisher control and data bus queues.

Once the control and data messages get published, they are then picked up by the subsequent lower and upper layers (if they exist), thus continuing the cycle

Would love to get critique about my current understanding so far

@samgriek

[samgriek]

@GWSzeto - Thanks a bunch for having a look. I've updated the README.md for the demo so as to clarify some of this.

[Community Feedback and Insights](https://github.com/daveshap/ACE_Framework/blob/main/demos/iACEui/README.md#community-feedback-and-insights)
We've had some community members delve into the iACEui project, providing valuable insights on how it's set up, its key components, and its operation:

[Key Components](https://github.com/daveshap/ACE_Framework/blob/main/demos/iACEui/README.md#key-components)
There are three main services driving the ACE Framework and the Frontend:

Svelte GUI: Interactive prompt engineering and testing user interface

Postgres DB: Stores identity, reasoning, and ancestral prompts, as well as system messages, control bus, and data bus prompts.

RabbitMQ: Serves as the pipeline for control and data busses, handling four messaging queues per layer for proper message passage.

API: Offers a variety of endpoints for starting, testing, and managing prompts in the system. The /mission endpoint is used to provide the "user mission" to ACE.

[Additional Usage Tips](https://github.com/daveshap/ACE_Framework/blob/main/demos/iACEui/README.md#additional-usage-tips)
[On initial setup](https://github.com/daveshap/ACE_Framework/blob/main/demos/iACEui/README.md#on-initial-setup)
The Svelte frontend is served, allowing users to set prompts through the API and populate the Postgres DB.
Once the DB is populated, the system is ready for launch.
[Operational Flow](https://github.com/daveshap/ACE_Framework/blob/main/demos/iACEui/README.md#operational-flow)
The system starts with a mission statement published to the aspirational layer via the /mission endpoint.
The aspirational layer generates reasoning and separate control and data messages, which are then published and picked up by subsequent layers, continuing the cycle. The subsequent layers in turn do the same. Each layer subscribes and published to it's adjactent layers. Control is passed down and Data is passed up the hierarchy.

Let me know if this somehow doesn't cover your questions.