Function
Ref. Model
I/O Data
SubAIMs
JSON MData
Profiles
Ref. Software
Conformance
Performance
1 Functions
The A‑User Control (PGM‑AUC) AIM serves as the central coordinator for Action execution, AIM orchestration, and system traceability. It governs the lifecycle of the A‑User and orchestrates its interactions with the responsible human, the M‑Instance, and the Processes and Items with which the A‑User interacts.
A‑User Control holds goal authority but not necessarily epistemic capability: it carries the objectives given to it by the responsible human or by specification, and it asserts those objectives authoritatively. It it does not itself understand the environment or the User because that understanding resides in the reasoning AIMs. Consequently, a Request is binding as to the goal it sets and the constraints it imposes, but it is advisory as to the conclusion: an AIM that reasons decides its own conclusion, and an AIM that executes attempts the goal subject to the conditions of the world. In neither case may an AIM decline the goal, but any AIM may report that the goal was not achieved, or was achieved differently, and why.
Accordingly, a Response is not merely a record of completion but a decision-and-outcome report. Every Response states the goal the AIM understood, the outcome reached, and a reason. Executor AIMs (such as Context Description and Context Enhancement) report the outcome and, where a goal could not be met, the world condition that prevented it (for example, occlusion or unreachability). Reasoning AIMs (such as User State Refinement, Basic Knowledge, and Personality Alignment) report the conclusion they reached and, where A‑User Control proposed a correction, whether they adopted, partially adopted, or declined it, and why.
Therefore, A‑User Control does not impose a fixed schedule on the AIMs it cannot direct in detail; it sets goals and constraints, lets each AIM work, inspects the reported outcome, and may call again with a revised goal or a proposed correction. Every call is answered, and the initiative to call always rests with A‑User Control. In this way, A‑User Control bounds and steers the A‑User’s behaviour by exception rather than by micromanagement, judging each AIM’s report against the objective it was given rather than against a correctness it is not equipped to assess.
A‑User Control also governs all access to Private Storage. Because routing every read and write through A‑User Control would make it a bottleneck, A‑User Control is never in the storage data path; the orchestrated AIMs perform their own storage operations. A‑User Control governs that access in two complementary ways: it instructs each producing AIM, through that AIM’s Request, what to store and what it may read; and it configures Private Storage, through the AUC-AUS Request, with the session’s storage scopes, retention and life cycle policy, and the access rights Private Storage enforces. Writes are performed only as instructed; session‑scope reads are performed by an AIM as it needs them, while historical‑scope reads are permitted only under an authorisation A‑User Control establishes and Private Storage enforces.
A‑User Control sends Request messages to AIMs to implement Instructions within the Rights the A‑User holds and the Rules applicable to the M‑Location, and tracks execution of Requests using Responses received from A‑User AIMs.
The resulting control flow ensures that the A‑User operates predictably, transparently, and in alignment with human Commands, supporting lifecycle integrity and enabling trust through auditable orchestration.
2 Reference Model
Figure 1 depicts the Reference Model of the A‑User Control (PGM‑AUC) AIM.
Figure 1 – Reference Model of the A‑User Control (PGM‑AUC) AIM
A-User Control sends to the M-Instance, as Process Action Requests, the Process Actions that A-User Formation has given it and that it lets through, and interprets the Process Action Responses. The limits of the Process Actions are conveyed to Basic Knowledge in the AUC-BKN Request, so that A-User Control does not validate them again before sending them. A-User Control may decide not to send a Process Action, in which case it stops the corresponding motion of the Portable Avatar with the AUC-AUF Request, or may send it when the AUC-AUF Response reports that the motion has reached the point at which the effect occurs.
Authorisation. Nothing leaves the A-User without the agreement of A-User Control: not a Process Action, not the Portable Avatar. A-User Formation gives A-User Control the Portable Avatar and the Process Actions that do not concern the A-User as an entity. If A-User Control agrees, it sends the Process Actions to the M-Instance and gives the Portable Avatar to Portable Avatar Demultiplexing, which separates it: the speech goes through the Controller to the User Agent and its Speech Object Delivery Unit, and the avatar model and the face and body descriptors go to its 3D Model Object Delivery Unit. If it does not agree, it stops them and may ask A-User Formation to stop the motions with the AUC-AUF Request. A-User Formation may have worked in vain.
Human Command. A-User Control answers every Human Command with a Human Command Response as soon as it has decided what to do with it: accepted, rejected, escalated or ignored. It does not wait for the Goal to be reached. The Response goes to the Controller, which passes it to the User Agent.
The A‑User Control AIM exercises its activity by implementing one of eight Instructions:
- Perception and Environment Capture (PEC): Configure perceptual subsystems to sense the responsible human in the Universe, the User in the M‑Instance, or the contents of the relevant M‑Location.
- Goal and Language Acquisition (GLA): Capture and segment multimodal expressions of the responsible human and/or the User. This corresponds to giving identity and spatial relationship to the objects in the scene and to understanding the User.
- Prompting and Knowledge Query (PKQ): Enable structured contextual representation and semantic grounding of perceptual and state information. The A‑User is now in a position to make sense of what it perceives and interprets.
- Goal and Intent Interpretation (GII): Based upon the results of the previous Instruction, trigger deliberative processing to determine the appropriate communicative behaviour of the A‑User. The A‑User Control is now able to decide the stance it should take.
- Policy, Rights, and Feasibility (PRF): Establish the constraints that the intended behaviour must satisfy with respect to governance Rules, User Entity State constraints, human commands, and domain feasibility conditions, and convey them in the Requests, in particular in the Actions property of the AUC-BKN Request. This includes establishing the Private Storage access rights enforced for the session. The A‑User Control knows that the A‑User actions must comply with a variety of constraints.
- Plan Construction and Execution (PCE): Orchestrate execution of the behaviour based on Responses reported by the AIMs, including speech and actions. The A‑User Control is now able to execute the actions after taking constraints into account.
- Conflict Management and Escalation (CME): Detect unresolved inconsistencies or conflicts and escalate to the responsible human when required. Various impediments may be encountered and modifications to the action decided.
- Avatar Formation and Rendering (AFR): Enable synthesis and rendering of the Portable Avatar. The A-User’s Portable Avatar is formed and can be rendered.
3 I/O Data
The A‑User Control (PGM‑AUC) AIM exchanges typed Requests and Responses with each of the A‑User AIMs it orchestrates. Each AIM receives a typed Request and returns a typed Response to A‑User Control.
Table 1 gives the Input and Output Data of the A‑User Control (PGM‑AUC) AIM.
| Input | Description |
|---|---|
| Human Command | Command from the responsible human, who lives in the universe. The User Agent of the A-User Module acquires it and the Controller passes it to A-User Control. |
| Process Action Response | From a Process that has received a Process Action Request. |
| Process Actions | The Process Actions of Basic Knowledge that do not concern the A-User as an entity, given by A-User Formation, to be sent to the M-Instance if A-User Control lets them through. |
| Portable Avatar | The avatar of the A-User, with its speech and its animation, formed by A-User Formation. A-User Control authorises it or stops it. |
| AUC-CXT Response | Scene‑level context, User presence and enhancement outcomes reported by Context Description. |
| AUC-PRC Response | Prompt readiness, alignment status, semantic goal framing reported by Prompt Creation. |
| AUC-BKN Response | Enriched response metadata and traceability reported by Basic Knowledge. |
| AUC-DAC Response | Execution feasibility and constraint validation reported by Domain Access. |
| AUC-USR Response | Current engagement, affective tone, override flags reported by User State Refinement. |
| AUC-PAL Response | Expressive alignment, persona framing, modulation constraints reported by Personality Alignment. |
| AUC-AUF Response | Avatar formation outcome, how the Process Actions have been divided, progress of the motions, reported by A‑User Formation. |
| AUC-AUS Response | Storage state, per‑operation outcomes, scope and retention enforcement, integrity and capacity, and lifecycle outcomes reported by Private Storage. |
| Output | Description |
| Action | Action performed by A‑User on the M‑Instance. |
| Portable Avatar | The Portable Avatar that A-User Control has authorised. It goes to Portable Avatar Demultiplexing (PAF-PDX), an AIM of the Module, which separates the speech, the avatar model and the face and body descriptors for the Units of the User Agent. |
| Process Action Request | Request made by A-User to an M-Instance Process, carrying a Process Action that A-User Control lets through. |
| AUC-CXT Request | Instructions for the acquisition and enhancement of the scene and of the User State sent to Context Description. |
| AUC-PRC Request | Prompt generation or refinement instructions sent to Prompt Creation. |
| AUC-BKN Request | Request for knowledge retrieval or response shaping sent to Basic Knowledge. |
| AUC-DAC Request | Request for domain execution sent to Domain Access. |
| AUC-USR Request | Request to modulate User State based on interaction feedback sent to User State Refinement. |
| AUC-PAL Request | Request for expressive modulation or Personality reconfiguration sent to Personality Alignment. |
| AUC-AUF Request | Request for avatar formation, spatial output, expressive delivery and control of the motions, sent to A‑User Formation. |
| AUC-AUS Request | Instructions establishing storage scopes, retention and lifecycle policy, session identification, and the access rights Private Storage enforces, sent to Private Storage. |
| Human Command (Response) | Response of A‑User Control to the Human Command (Mode RS). The Controller passes it to the User Agent. |
4 SubAIMs
No SubAIMs.
5 JSON Metadata
https://schemas.mpai.community/PGM1/V1.0/AIMs/AUserControl.json
6 Profiles
No Profiles.
7 Reference Software
Not part of this specification.
8 Conformance Testing
Table 2 provides the Conformance Testing Method for the A‑User Control (PGM‑AUC) AIM.
If a schema contains references to other schemas, conformance of data for the primary schema implies that any data referencing a secondary schema shall also validate against the relevant schema, if present, and conform with the Qualifier, if present.
| Receives | Human Command | Shall validate against Human Command schema, with Mode RQ. |
| Process Action Response | Shall validate against Process Action schema. | |
| Portable Avatar | Shall validate against Portable Avatar schema. | |
| AUC-CXT Response | Shall validate against AUC-CXT Response schema. | |
| AUC-PRC Response | Shall validate against AUC-PRC Response schema. | |
| AUC-BKN Response | Shall validate against AUC-BKN Response schema. | |
| AUC-DAC Response | Shall validate against AUC-DAC Response schema. | |
| AUC-USR Response | Shall validate against AUC-USR Response schema. | |
| AUC-PAL Response | Shall validate against AUC-PAL Response schema. | |
| AUC-AUF Response | Shall validate against AUC-AUF Response schema. | |
| AUC-AUS Response | Shall validate against AUC-AUS Response schema. | |
| Portable Avatar | Shall validate against Portable Avatar schema. | |
| Produces | Action | Shall validate against Action schema. |
| Process Action Request | Shall validate against Process Action schema. | |
| AUC-CXT Request | Shall validate against AUC-CXT Request schema. | |
| AUC-PRC Request | Shall validate against AUC-PRC Request schema. | |
| AUC-BKN Request | Shall validate against AUC-BKN Request schema. | |
| AUC-DAC Request | Shall validate against AUC-DAC Request schema. | |
| AUC-USR Request | Shall validate against AUC-USR Request schema. | |
| AUC-PAL Request | Shall validate against AUC-PAL Request schema. | |
| AUC-AUF Request | Shall validate against AUC-AUF Request schema. | |
| AUC-AUS Request | Shall validate against AUC-AUS Request schema. | |
| Human Command (Response) | Shall validate against Human Command schema, with Mode RS. |
9 Performance Assessment
Not part of this specification.
