Definition
Functional Requirements
Syntax
Semantics
Conformance Testing
Performance Assessment
Definition
AUC-BKN (PGM-UCK) is the Data Type that A‑User Control and Basic Knowledge exchange. It has two modes: the Request (RQ), sent by A‑User Control to Basic Knowledge, and the Response (RS), sent by Basic Knowledge to A‑User Control. The Request sets a goal that Basic Knowledge 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 Basic Knowledge 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-UCK-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 (AUCBKNID, AUCBKNTime).
- 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 Basic Knowledge 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 Basic Knowledge 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.
- Correction: A Request may carry a Correction with a Weight; the Response states whether it was adopted, partially adopted or declined, and why.
- Actions: A Request may ask Basic Knowledge to propose Process Actions, stating the Process Actions that may be used, the maximum number of steps, the M‑Locations, the Rights and the Wallet limit; the Process Actions shall conform with the grammar of MMM‑TEC V2.2. The Response only reports whether they were produced.
- Abandon: A Request may instruct Basic Knowledge to abandon the pursuit of an unmet need.
- Metadata: The Data shall include DataXMData and may include DescrMetadata.
Syntax
https://schemas.mpai.community/PGM1/V1.0/data/AUCBKN.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-BKN
| 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) |
| AUCBKNID | Identifier of this Request or Response. (required) |
| AUCBKNTime | 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. |
| 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. |
| Abandon | Unmet needs that AUC asks BKN to stop pursuing. |
| – NeedID | Identifier of the need. (required) |
| – Rationale | Reason for the proposal. |
| Actions | Whether Process Actions are to be proposed, which ones, and within which limits. |
| – Requirement | Whether it is required, optional or not requested. One of: required, optional, not_requested. (required) |
| – Allowed | The Process Actions that may be proposed. Each one of: Authenticate, Author, Convert, Discover, Execute, Hide, Identify, Interpret, License, MM-Add, MM-Animate, MM-Capture, MM-Move, MM-Send, Modify, MU-Actuate, MU-Add, MU-Animate, MU-Move, MU-Send, Post, Property Change, Register, Resolve, Rights Change, Transact, UM-Actuate, UM-Capture, UM-Send, Validate. |
| – MaxSteps | Maximum number of Process Actions in the sequence. |
| – Locations | M-Locations in which the Process Actions may be performed. |
| – RightsRefs | Identifiers of the Rights that the A-User holds and may use. |
| – WalletLimit | Maximum amount that may be spent from the Wallet. |
| – Syntax | The Process Actions shall conform with the grammar of MMM-TEC V2.2. |
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. |
| DeliberationState | Deliberation State. One of: deliberating, concluded, blocked. (required) |
| Conclusion | The conclusion reached by BKN. |
| – Headline | Headline of the conclusion or of the stance. |
| – FinalResponseID | Identifier of the Final Response (a Basic Text Object) sent to A-User Formation and to AUC. |
| – 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). |
| UnmetNeeds | Unmet Needs. |
| – NeedID | Identifier of the need. (required) |
| – Description | Description of the reason. (required) |
| – Partner | AIM whose partner interface could not satisfy the need. One of: PRC, DAC, USR, PAL, none. |
| – SurfacedCount | Number of times the need was surfaced. (required) |
| – DeliberationStartTime | Time at which the deliberation that originated the need began. (required) |
| ActionsOutcome | Outcome of the proposal of Process Actions. |
| – Outcome | Outcome reached. One of: produced, partial, failed, not_requested. (required) |
| – ProposedActionsID | Identifier of the Process Action sequence sent on the output Port of the AIM. |
| – StepCount | Number of Process Actions proposed. |
| – Reasons | Reasons why the goal was not fully achieved. |
| –– Reason | Reason (Response) or explanation (Correction). One of: none, ambiguity_unresolved, partner_unavailable, constraint_conflict, insufficient_context, deadline_exceeded, not_permitted. (required) |
| –– Description | Description of the reason. |
Conformance Testing
Data conforms with AUC-BKN 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.
