Definition
Functional Requirements
Syntax
Semantics
Conformance Testing
Performance Assessment
Definition
Functional Requirements
- Header and Mode: The Data shall have Header “PGM-UCP-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 (AUCPALID, AUCPALTime).
- 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 Personality Alignment 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 Personality Alignment 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.
- Stance: A Request may state the framing, the role, locale and expressive constraints, a personality reconfiguration and a Correction; the Response shall report the stance adopted and how the Correction was treated.
- Metadata: The Data shall include DataXMData and may include DescrMetadata.
Syntax
https://schemas.mpai.community/PGM1/V1.0/data/AUCPAL.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-PAL
| 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) |
| AUCPALID | Identifier of this Request or Response. (required) |
| AUCPALTime | 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: align, style, tone, calibrate. (required) |
| Goal | Binding as to the objective and the constraints. (required) |
| – Objective | The objective to pursue. (required) |
| – Constraints | Constraints, as strings. |
| 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. |
| Framing | Framing strategy for the expression of the A-User. |
| – Style | Style of delivery. |
| – Tone | Tone of delivery. |
| Constraints | Role, locale and expressive or behavioural constraints to apply. |
| – Role | Role of the A-User to apply. |
| – Locale | Locale to apply. |
| – Guidelines | Expressive or behavioural guidelines. |
| Personality | Personality reconfiguration. |
| – ProfileTarget | Identifier of the Personality profile to use. |
| – ForceProfileSwitch | Whether to force the switch to the target profile. |
| – FallbackProfile | Identifier of the Personality profile to fall back to. |
| Evidence | The evidence Personality Alignment may use. |
| – 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., Personality profiles) that Personality Alignment may consult. |
| Properties | The properties to be produced, at property level. |
| – AUserState | Request: whether the production of the A-User State is required, optional or not_requested. Response: fulfilment of the production of the A-User State (produced, partial, missing or not_requested). One of: required, optional, not_requested. |
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. |
| Alignment | Alignment. One of: aligned, calibrating, out_of_range. |
| AUserStateID | Identifier of the A-User State sent to A-User Formation. |
| PropertyFulfilment | Fulfilment of the requested properties. |
| – AUserState | Request: whether the production of the A-User State is required, optional or not_requested. Response: fulfilment of the production of the A-User State (produced, partial, missing or not_requested). One of: produced, partial, missing, not_requested. |
| AdoptedStance | The stance adopted for the A-User State. (required) |
| – Headline | Headline of the conclusion or of the stance. (required) |
| – SelectedProfile | Identifier of the Personality profile applied. |
| – FallbackUsed | Whether the fallback profile was used. |
| 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). |
| FramingOutcome | Framing as delivered. |
| – Style | Style of delivery. |
| – Tone | Tone of delivery. |
Conformance Testing
Data conforms with AUC-PAL 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.