Context & Orchestration Standard Documentation

3. Internal Addressation System

Motivation

As the volume and diversity of context data grows — with time-expired info, dynamic workflows, AI-driven decisions, and Robo Assistant tasks — a structured addressing scheme inside the Context Engine is crucial for:

• Efficient data routing and lookup
• Clear separation of concerns and data ownership
• Support for mesh-like internal networks across modules
• Facilitating distributed AI and robotic agents working in concert

Addressing Scheme Principles

• Hierarchical and namespaced keys to avoid collisions
• Time-to-live (TTL) metadata for ephemeral context data
• Ability to traverse or route between contexts (e.g., from user to project to organization)
• Support for multiple channels (context, data queues, events) with clear semantics

4. Data Queues & Messaging Channels

Overview

In addition to static context data, the system supports dynamic, message-oriented data flows organized as named queues with typed channels and messages. These serve as the communication backbone for task distribution, event propagation, and state synchronization among services.

Example queue key namespaces:

Data:Queue:<queue_id>:In:<data_type>:<field>
Data:Queue:<queue_id>:Out:<message_type>:<field>
Data:Queue:<queue_id>:Chat:History:<history_id>:<type>
Data:Queue:<queue_id>:Object:<object_id>
Data:Queue:<queue_id>:Providers:<provider_id>
Data:Queue:<queue_id>:Result:<status_field>

Roles

• Task Providers: Services or agents consuming input queues and producing results.
• Event Publishers: Modules generating context or task-related events into queues.
• Data Consumers: Other services or AI modules subscribing to queue data for decision making.

5. Integration with Context Engine, AI Module, Robo Assistant

• The addressing system and data queues form the internal mesh network for inter-service communication.
• Context Engine remains the source of truth for static and semi-static context data.
• AI Module and Robo Assistant act as active agents, consuming data queues, updating context, and emitting events.
• Orchestration logic may route messages across queues dynamically based on context and rules.

6. Subscription Channel — events_channel

Purpose

The events_channel is a pub/sub mechanism designed for modules and services to subscribe to real-time events and their payloads emitted by the Context Engine, AI Module, Robo Assistant, or any other system component.

Features

• Event-driven architecture: Decouples event producers from consumers for scalability and flexibility
• Payload delivery: Events carry structured payloads with contextual metadata
• Filtered subscriptions: Consumers can subscribe to specific event types or scopes (e.g., user-specific, project-specific)
• Guaranteed delivery options: Supports QoS levels like at-most-once, at-least-once, or exactly-once semantics (depending on implementation)
• Integration: Enables orchestration rules, AI agents, and external services to react promptly to state changes

Example Event Key Pattern

events_channel:<scope_type>:<scope_id>:<event_type>

Example:

events_channel:user:1234:task_completed
events_channel:organization:5678:inventory_update

Typical Payload Structure

{
  "timestamp": "2025-05-27T10:00:00Z",
  "source": "robo_assistant",
  "event_type": "task_completed",
  "context": {
    "user_id": "1234",
    "project_id": "9876"
  },
  "data": {
    "task_id": "abcd-1234",
    "result": "success",
    "details": "Welding operation finished"
  }
}

Usage

• Subscribing services listen to relevant event keys.
• On event reception, subscribers update local state, trigger workflows, or forward data downstream.
• Supports multi-tenant and multi-scope event segregation.

7. Template System

Overview

The Template System is a core feature used across multiple modules for generating dynamic content such as emails, communications, payment notices, documents, and website content. It allows templates to be populated automatically with context-aware data fields.

Placeholder Syntax

• %%field_name%% — Simple placeholder replaced by the value of field_name from the Data:Query of the current task.
• If the field does not exist in the current task, the system searches through hierarchical context layers to find the closest available value.

Default Values

Templates support setting default values to fallback on when no data is found. Currently, defaults are stored in the database, but there is a plan to move this logic into the Context Engine with persistent storage (no expiration).

Arrays Handling

For array-type fields, you can loop or access elements with the syntax:

@@array_field@@%%element_of_array%%@@array_field@@

This allows iteration over elements or direct access to specific items inside array fields.

Complex Objects

Complex nested objects like user, project, or product can be accessed using a delimiter notation to extract nested fields:

• -P-<object_name>-P- — Opens the context for the object.
• -Pr-<field_name>-Pr- — Accesses a field inside the previously opened object context.

Example:

  Template field: -P-project-P--Pr-name-Pr-
  Resolves to: the name field inside the project object in context.
  

If the field is missing, the system uses a default fallback value such as the Product cost for product objects.