(Tentative)

Function Reference Model Input/Output Data
SubAIMs JSON Metadata Profiles

1. Function

A‑User Control (AUC)

  1. Governs the lifecycle of the A-User and orchestrates its interaction with the M-Instance, its Processes and Items, and the human User serving as the central coordinator for Action execution, AIM orchestration, and system traceability.
  2. Orchestrates the A‑User AIMs by deciding what to do, which AIM should do it, and how it should be done,
    within the Rights the A‑User holds and the Rules applicable to the M‑Instance.
  3. Includes an Orchestration And Scheduling SubAIM issuing commands and receiving responses from five other SubAIMs.
  4. Uses OAS→SubAIMs and SubAIMs→AIMs messages for dispatch, directives, and lifecycle tracking tasked to interact with the PGM-AUA AIMs.
  5. SubAIMs issue messages to and receive responses from Context Capture, Spatial Reasoning (Audio/Visual), Domain Access, Prompt Creation, Basic Knowledge, User State Refinement, Personality Alignment, and A‑User Rendering.
  6. Issues directives, validates policy/feasibility, schedules/mediates execution according to Priority and Constraints.
  7. Tracks execution using Status messages.

The resulting control flow ensures that the A-User operates predictably, transparently, and in alignment with both system directives and User interaction goals – supporting lifecycle integrity and enabling trust through auditable orchestration.

2. Reference Model

PGM-AUC triggers Context Capture to perceive the current M‑Location; obtain and align scene and state information; request domain enrichment; and route requests to Prompt-issuing AIMs and Basic Knowledge. AUC then integrates state and personality guidance and issues Formation Directives to the A‑User Formation AIM to produce the Persona (Speaking Avatar) for instantiation in the metaverse.

Figure 1 gives the input/output data of A-User Control (PGM-AUC).

Figure 1 – Reference Model of A-User Control (PGM-AUC) AIM

3. Input/Output Data

4.1       Introduction

The A‑User Control (AUC) exchanges named, purpose‑specific data types (e.g., “Audio Action Directive”, “Formation Status”) with the other AIMs of PGM-AUC. These interactions are normalised through two unified message schemas:

  • OAS To SubAIMs: used for orchestration Dispatch and Response between OAS and SubAIMs.
  • SubAIMs To AIMs: used for execution Directive and Status between SubAIMs (source) and AIMs (targets).

Therefore, PGM-AUC treats the descriptive data types as semantic labels conveyed via the unified message envelopes and payload fields.

Table 1 gives Input and Output Data of A-User Control (PGM-AUC) AIM.

Table 1 – Input and Output Data of A-User Control (PGM-AUC) AIM

Input Description Mapping to Unified Schema
Human Command From a human in the real world. External source; triggers OAS→SubAIMs Dispatch.
Process Action Response From the Process receiving a Process Action Request. Status → Result, Summary.
Context Capture Status Scene-level context and User presence metadata. Status from Context Capture AIM.
Audio Action Status Audio spatial feasibility, occlusion, reachability flags. Status from Audio Spatial Reasoning AIM.
Visual Action Status Visual spatial constraints and scene anchoring. Status from Visual Spatial Reasoning AIM.
Prompt Plan Status Prompt readiness, alignment status, semantic goal framing. Status from Prompt Creation AIM.
BK Response Trace Enriched response metadata and traceability. Status from Basic Knowledge AIM.
DA Action Status Execution feasibility and constraint validation. Status from Domain Access AIM.
User State Status Current engagement, affective tone, override flags. Status from User State Refinement AIM.
Personality Alignment Status Expressive alignment, persona framing, modulation constraints. Status from Personality Alignment AIM.
Formation Status Avatar formation success, avatar state, expressive output status. Status from A-User Rendering AIM.
Output Description Mapping to Unified Schema
Action Performed action by A-User on the metaverse. Status → Result.
Process Action Request Request made by A-User to a Process. Directive → Operation, Parameters.
Context Capture Directive Dispatch instructions for perceptual acquisition. Directive to Context Capture AIM.
Audio Action Directive Dispatch audio-related actions and sequences. Directive to Audio Spatial Reasoning AIM.
Visual Action Directive Dispatch visual-related actions and sequences. Directive to Visual Spatial Reasoning AIM.
Prompt Creation Directive Initiate prompt generation or refinement. Directive to Prompt Creation AIM.
BK Query Directive Trigger knowledge retrieval or response shaping. Directive to Basic Knowledge AIM.
DA Action Directive Send structured process action requests for domain execution. Directive to Domain Access AIM.
User State Status Modulate User State based on interaction feedback. Directive to User State Refinement AIM.
Personality Alignment Directive Initiate expressive modulation or Personality reconfiguration. Directive to Personality Alignment AIM.
Formation Directive Command avatar formation, spatial output, expressive delivery. Directive to A-User Rendering AIM.
Human Command Status AUC Response to Human Command. SubAIMs→OAS Response {Accepted, Reason}.

These semantic names are transported via unified Directive/Status messages; the action and identity are encoded by FromSubAIM, TargetAIM (AIMInstance), and Operation; the outcomes are in State, Summary, Result, Errors.

3.2 Normalisation Principles

  1. Single transport & control envelope — All named inputs/outputs are carried inside unified messages that share the Common Interface Envelope for transport/control metadata (e.g., MessageId, CorrelationId, timestamps). AUC propagates Envelope/Trace/Accuracy unchanged unless mediation/normalisation is required.
  2. Semantic labels → message fields — Each legacy Directive name corresponds to a Directive message whose action is encoded in FromSubAIM, TargetAIM (AIMInstance), and Operation. AIM‑specific parameters move to Parameters (optionally specialised via SchemaRef).
  3. Lifecycle & outcomes — Named Status types are conveyed by Status messages with State, Progress, Summary, Result, and Errors. Correlation between each Directive and its Status flow is enforced via Envelope.CorrelationId.
  4. Policy & feasibility gates — For PFS‑originated Directives the Policy object (Rights/Rule) is required; AUC rejects PFS Directives lacking Policy.

3.3 Mapping: Named Data Types → Unified Message Fields

Inputs to AUC (Table 1 names as received by AUC)

  • Human Command → External input initiating OAS orchestration; carried as OAS→SubAIMs Dispatch; ack via Response {Accepted, Reason}.
  • Process Action Response → Status with Summary/Result, correlated via Envelope.CorrelationId.
  • Context Capture Status → Status from Context Capture AIM (scene/presence).
  • Audio Action Status → Status from Audio Spatial Reasoning AIM.
  • Visual Action Status → Status from Visual Spatial Reasoning AIM.
  • Prompt Plan Status → Status from Prompt Creation AIM.
  • BK Response Trace → Status from Basic Knowledge AIM.
  • DA Action Status → Status from Domain Access AIM.
  • User State Status → Status from User State Refinement AIM.
  • Personality Alignment Status → Status from Personality Alignment AIM.
  • Rendering Status → Status from A‑User Rendering AIM.

Outputs from AUC (Table 1 names as emitted by AUC)

  • ActionPerformed on M‑Location → Reflected in Status.Result of the executing AIM.
  • Process Action Request → Directive with Operation + Parameters; target Process encoded in TargetAIM.
  • Context Capture Directive → Directive to Context Capture AIM (TargetAIM = AIMInstance of Context Capture; specifics in Parameters).
  • Audio Action Directive → Directive to Audio Spatial Reasoning AIM.
  • Visual Action Directive → Directive to Visual Spatial Reasoning AIM.
  • Prompt Creation Directive → Directive to Prompt Creation AIM (Parameters and optional SchemaRef).
  • BK Query Directive → Directive to Basic Knowledge AIM.
  • DA Action Directive → Directive to Domain Access AIM; constraints via Constraints.
  • User State Status (AUC→USR modulation request) → Expressed as a Directive to User State Refinement AIM; AIM then emits its own Status.
  • Personality Alignment Directive → Directive to Personality Alignment AIM; governance in Policy where applicable.
  • Rendering Directive → Directive to A‑User Rendering AIM; delivery/expressive/spatial parameters in Parameters; outcome via Rendering Status.
  • Human Command Status → OAS→SubAIMs Response {Accepted, Reason}.

3.4 Identity, Contexts, and Constraints

  • Target identity is always conveyed as TargetAIM using AIMInstance (AIF V3.0).
  • Goal/Plan/Policy contexts move into GoalContext, PlanContext, and Policy respectively; PFS Directives require Policy.
  • Execution constraints (timeouts, cost, risk) are encoded in Constraints; priority in Priority.

3.5 Lifecycle & Correlation

Directive → Status chain: Every Status that reports progress/completion of a Directive carries the same Envelope.CorrelationId. AUC enforces correlation, rejects orphan Status updates, and records state transitions (Received → Queued → InProgress → Completed/Failed etc.).

4. SubAIMs (informative)

A PGM-AUC instance can be implemented using the architecture depicted in Figure 2. The Orchestration and Scheduling SubAIM issues OAS To SubAIMs messages to SubAIMs. These sends the data types listed in Table 1 to appropriate AIMs.

Figure 2 – Informative PGM-AUA architecture

Each SubAIM is bound to permitted Operation values in the unified messages. AUC validates FromSubAIM/Operation pairs and enforces policy requirements.

Table 2 – GoalNormalisation, IntentResolutionSchema‑enforced Operation values.

Sub
AIM		 Role in Orchestration Allowed Operations (Directive) Notes
OAS Central orchestration & scheduling; issues Dispatch to SubAIMs and consumes Response{Accepted, Reason}. — Entry to SubAIMs path; lifecycle anchored via Envelope/Trace/Accuracy.
HGV Human Goal intake & validation. HumanGoalIntake, Validation
GIR
Goal & Intent Resolution
 GoalNormalisation, IntentResolution
PFS Policy screening & feasibility assessment. PolicyScreening, FeasibilityAssessment Policy context required for directives (Rights/Rule).
GPO Plan integration & orchestration handoff. PlanIntegration, OrchestrationHandoff PlanContext.Step may be enum (e.g., HGV, GIR‑N, PFS‑F, GPO‑H, EXE) or structured.
CDE Conflict detection & escalation. ConflictDetection, Escalation

Table 3 gives the connections between SubAIMs and AIMs.

Table 3 – Connection Table: SubAIMs → AIMs
AIM ↓ / SubAIM → OAS HGV GIR PFS GPO CDE
Context Capture (PGM‑CXC) X
Audio Spatial Reasoning (PGM‑ASR) X
Visual Spatial Reasoning (PGM‑VSR) X
Prompt Creation (PGM‑PRC) X X
Basic Knowledge (PGM‑BKN) X X
Domain Access (PGM‑DAC) X X
User State Refinement (PGM‑USR) X X
Personality Alignment (PGM‑PAL) X
A‑User Rendering (PGM‑AUR) X

5. JSON Metadata

https://schemas.mpai.community/PGM1/V1.0/data/AUserControl.json

6. Profiles

No Profiles.