Definition
Functional Requirements
Syntax
Semantics
Conformance Testing
Performance Assessment
Definition
AUC-USR (PGM-UCU) is the Data Type that A‑User Control and User State Refinement exchange. It has two modes: the Request (RQ), sent by A‑User Control to User State Refinement, and the Response (RS), sent by User State Refinement to A‑User Control. The Request sets a goal that User State Refinement attempts: it is binding as to the goal and the constraints it imposes and advisory as to the conclusion. Every Request is answered by a Response that reports the goal User State Refinement understood, the outcome reached and, if the goal was not achieved as requested, the reason.
Functional Requirements
- Header and Mode: The Data shall have Header “PGM-UCU-V1.0” and Mode equal to RQ for a Request and to RS for a Response; the properties that belong to the other mode shall not be present.
- Identification: The Data shall carry the identifiers of the M‑Instance, of the U‑Environment and of the session, and a unique identifier and a time (AUCUSRID, AUCUSRTime).
- Correlation: A Response shall carry the identifier (RequestID) of the Request that it answers; a Request that continues an exchange shall carry, in Exchange, the identifier of the Response to which it follows.
- Instruction: A Request shall state the Instruction (PED, GLA, PKQ, GII, PRF, PCE, CME or AFR) under which A‑User Control issues it.
- Storage: A Request may state what User State Refinement may write to and read from the Private Storage of the Module, under the rules set by A‑User Control; the Response reports the outcome of the writes in StorageOutcome.
- Process Action outcome: A Request may convey the outcome of a Process Action performed by A‑User Control, so that User State Refinement operates knowing the current state of the M‑Instance.
- Outcome and Reason: A Response shall state the goal as it was understood (GoalUnderstood, where the type has it) and the Outcome (achieved, achieved_differently or not_achieved); when the Outcome is not achieved, the Response shall carry a Reason.
- Evidence and control: A Request may state the Urgency, the control mode (Overseer or Micromanager), the properties to be produced, the evidence that may be used and the conditions of override; it may carry a Correction.
- Engagement: A Response shall report the Engagement, the override report and the provenance of the refinement.
- Metadata: The Data shall include DataXMData and may include DescrMetadata.
Syntax
https://schemas.mpai.community/PGM1/V1.0/data/AUCUSR.json
Semantics
Table 1 gives the properties common to the two modes, Table 2 those of the Request and Table 3 those of the Response.
Table 1 – Properties common to the Request and the Response of AUC-USR
| Label | Description |
| Header | Header of the Data Type, with the version. (required) |
| Mode | RQ for a Request (A-User Control to the AIM), RS for a Response (the AIM to A-User Control). One of: RQ, RS. (required) |
| MInstance | Identifier of the M-Instance. (required) |
| UEnvironment | Identifier of the U-Environment. (required) |
| SessionID | Identifier of the A-User session. (required) |
| AUCUSRID | Identifier of this Request or Response. (required) |
| AUCUSRTime | Time at which the Request or the Response was produced. (required) |
| DataXMData | Data Exchange Metadata of MPAI-PTF: provenance, authorisation, security and confidence of the Data. |
| DescrMetadata | Descriptive metadata (plain text, at most 2048 characters). |
Table 2 – Properties of the Request (Mode RQ)
| Label | Description |
| Instruction | The Instruction under which AUC issues the Request. One of: PED, GLA, PKQ, GII, PRF, PCE, CME, AFR. (required) |
| Exchange | Exchange. (required) |
| – Phase | Whether the Request starts an exchange (new) or continues one (continuation). One of: new, continuation. (required) |
| – ResponseID | ID of the Response to which a continuation Request follows. |
| Storage | What the AIM may write to and read from the Private Storage of the Module, under the rules set by AUC. |
| – Write | Data that the AIM may write, with the rules that apply. |
| –– Category | Category of the data. (required) |
| –– Readers | AIMs that may read the datum. |
| –– Time | Longest time the datum is kept: module, session or persistent. One of: module, session, persistent. |
| – Read | Categories of data that may be read. |
| ProcessActionOutcome | Outcome of a Process Action performed by AUC in the M-Instance, conveyed so that the AIM operates knowing the current M-Instance state. |
| – PAStatus | PA Status of the Process Action: Ack or the reason of the refusal (Clash, FaultyReq, IncID, IncDQ, InsRights, InsValue, LocOOR, PostRef, QualNS). |
| – Complements | The Complements received with the Process Action Response. |
| – Constraint | Resulting constraint on the Goal. |
| Operation | Operation. One of: estimate, update, reset. (required) |
| Goal | Binding as to the objective and the constraints. (required) |
| – Objective | The objective to pursue. (required) |
| – Constraints | Constraints, as strings. |
| Urgency | Urgency. One of: low, normal, high. |
| ControlMode | The mode in which AUC controls User State Refinement. One of: Overseer, Micromanager. |
| Properties | The properties to be produced, at property level. |
| – Engagement | Engagement of the User. One of: required, optional, not_requested. |
| – EntityState | Request: whether the production of the Entity State is required, optional or not_requested. Response: fulfilment of the production of the Entity State (produced, partial, missing or not_requested). One of: required, optional, not_requested. |
| Evidence | The evidence User State Refinement may use. |
| – Modalities | Modalities of the evidence to consider, in decreasing order of weight. Each one of: Text, Audio, Visual, Speech. |
| – History | How much of the Interaction History is used. |
| –– Include | Whether the Interaction History is used. |
| –– MaxTurns | Maximum number of turns of the Interaction History. |
| –– TimeWindow | Time window of the Interaction History. |
| – MInstanceServices | M-Instance services (e.g., Authenticate) that User State Refinement may consult. |
| Correction | A correction proposed by AUC. The AIM may adopt it, adopt it partially or decline it, and says so in the Response. |
| – Proposal | The correction proposed. (required) |
| – Weight | Importance that the AIM should give the proposal: low, medium or high. One of: low, medium, high. (required) |
| – Rationale | Reason for the proposal. |
| Override | Override conditions: whether AUC accepts the refined User State or overrides it with the one provided. |
| – Decision | Decision on the Correction (Response) or on the refined User State (Request). One of: accept, override. |
| – Engagement | Engagement of the User. |
| –– Level | Level, between 0 and 1. |
| –– Mode | RQ for a Request (A-User Control to the AIM), RS for a Response (the AIM to A-User Control). |
| – EntityState | Request: whether the production of the Entity State is required, optional or not_requested. Response: fulfilment of the production of the Entity State (produced, partial, missing or not_requested). |
| – Rationale | Reason for the proposal. |
Table 3 – Properties of the Response (Mode RS)
| Label | Description |
| RequestID | ID of the Request this Response answers. (required) |
| Outcome | The outcome reached. One of: achieved, achieved_differently, not_achieved. (required) |
| Reason | Structured reason, required when Outcome is not ‘achieved’. |
| – Code | Code of the reason. One of: none, ambiguity_unresolved, partner_unavailable, constraint_conflict, insufficient_context, deadline_exceeded, not_permitted. (required) |
| – Description | Description of the reason. |
| StorageOutcome | Outcome of the writes instructed by the Request. |
| – Category | Category of the data. (required) |
| – Result | Result of the operation. One of: written, not_authorised, not_attempted. (required) |
| GoalUnderstood | The goal as the AIM understood it. (required) |
| – Objective | The objective to pursue. (required) |
| – Constraints | Constraints, as strings. |
| UserStateID | Identifier of the refined User State sent to Personality Alignment and made available to A-User Formation. |
| PropertyFulfilment | Fulfilment of the requested properties. |
| – Engagement | Engagement of the User. One of: produced, partial, missing, not_requested. |
| – EntityState | Request: whether the production of the Entity State is required, optional or not_requested. Response: fulfilment of the production of the Entity State (produced, partial, missing or not_requested). One of: produced, partial, missing, not_requested. |
| CorrectionResponse | Treatment of the Correction proposed by AUC. |
| – Decision | Decision on the Correction (Response) or on the refined User State (Request). One of: none, adopted, partial, declined. (required) |
| – Reason | Reason (Response) or explanation (Correction). |
| Engagement | Current engagement. (required) |
| – Level | Level, between 0 and 1. |
| – Mode | RQ for a Request (A-User Control to the AIM), RS for a Response (the AIM to A-User Control). |
| OverrideReport | Override Report. |
| – Applied | Whether the override was applied. (required) |
| – Type | Type of override. |
| Provenance | Provenance of the refinement. |
| – Source | Source of the evidence. (required) |
| – Kind | Kind of source or of failure. |
Conformance Testing
Data conforms with AUC-USR if it validates against the schema of Section 3 and, if the Mode is RQ, contains the properties required for a Request and none of those of a Response, and vice versa. 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.
Performance Assessment
Not part of this specification.
