Definition
Functional Requirements
Syntax
Semantics
Conformance Testing
Performance Assessment
Definition
Functional Requirements
- Header and Mode: The Data shall have Header “PGM-UCD-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 (AUCDACID, AUCDACTime).
- 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 Domain Access 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 Domain Access 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.
- Domain: A Request shall state the domain context and may request domain operations at operation level and the sources that may be used.
- Feasibility: A Request may ask for the validation of the feasibility of Process Actions; the Response gives, for each step, the PA Status that the Process Action would receive, and an overall result.
- Metadata: The Data shall include DataXMData and may include DescrMetadata.
Syntax
https://schemas.mpai.community/PGM1/V1.0/data/AUCDAC.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-DAC
| 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) |
| AUCDACID | Identifier of this Request or Response. (required) |
| AUCDACTime | Time at which the Request or the Response was produced. (required) |
| DomainContext | Request: The domain in which interpretation must occur. Response: The domain context used. |
| – DomainType | Type of domain (e.g., physical, intellectual, interactional). (required) |
| – DomainInstance | Specific domain instance. (required) |
| – OntologyRef | Reference to the ontology. |
| – ConstraintSet | Reference to the applicable constraints. |
| – InteractionMode | Interaction context applied. |
| 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. |
| Operations | The domain operations requested, at operation level. |
| – ResolveAmbiguities | Request: whether the production of the resolution of ambiguities is required, optional or not_requested. Response: fulfilment of the production of the resolution of ambiguities (produced, partial, missing or not_requested). One of: required, optional, not_requested. |
| – ApplyConstraints | Request: whether the production of the application of the constraints is required, optional or not_requested. Response: fulfilment of the production of the application of the constraints (produced, partial, missing or not_requested). One of: required, optional, not_requested. |
| – SemanticEnrichment | Request: whether the production of the semantic enrichment is required, optional or not_requested. Response: fulfilment of the production of the semantic enrichment (produced, partial, missing or not_requested). One of: required, optional, not_requested. |
| – CrossModalResolution | Request: whether the production of the cross-modal resolution is required, optional or not_requested. Response: fulfilment of the production of the cross-modal resolution (produced, partial, missing or not_requested). One of: required, optional, not_requested. |
| Serving | Whether Domain Access serves capture-level grounding, reasoning-level semantics or both. One of: capture, reasoning, both. |
| Feasibility | Validation of the feasibility of Process Actions that are being considered (used under the PRF and PCE Instructions). |
| – ProcessActions | The Process Action statements, in the syntax of MMM-TEC V2.2. (required) |
| –– Step | Index of the Process Action in the sequence. (required) |
| –– Statement | A Process Action statement conforming with the grammar of MMM-TEC V2.2. (required) |
| – SceneContext | Scene and focus the Process Actions refer to. |
| –– SceneID | Identifier of the scene. |
| –– UserFocus | Identifier of the entity the User focuses on. |
| Sources | External domain knowledge sources that Domain Access may use. |
| – ExternalAllowed | Whether external domain knowledge sources may be used. |
| – Allowed | The Process Actions that may be proposed or used. |
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, service_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. |
| Fulfilment | Fulfilment of the requested operations. |
| – ResolveAmbiguities | Request: whether the production of the resolution of ambiguities is required, optional or not_requested. Response: fulfilment of the production of the resolution of ambiguities (produced, partial, missing or not_requested). One of: produced, partial, missing, not_requested. |
| – ApplyConstraints | Request: whether the production of the application of the constraints is required, optional or not_requested. Response: fulfilment of the production of the application of the constraints (produced, partial, missing or not_requested). One of: produced, partial, missing, not_requested. |
| – SemanticEnrichment | Request: whether the production of the semantic enrichment is required, optional or not_requested. Response: fulfilment of the production of the semantic enrichment (produced, partial, missing or not_requested). One of: produced, partial, missing, not_requested. |
| – CrossModalResolution | Request: whether the production of the cross-modal resolution is required, optional or not_requested. Response: fulfilment of the production of the cross-modal resolution (produced, partial, missing or not_requested). One of: produced, partial, missing, not_requested. |
| FeasibilityResult | Outcome of the feasibility validation, expressed with the PA Status vocabulary of MMM-TEC V2.2. |
| – Steps | Outcome for each Process Action. (required) |
| –– Step | Index of the Process Action in the sequence. (required) |
| –– PAStatus | Ack: the Process Action can be performed. Otherwise the PA Status it would receive. One of: Ack, Clash, FaultyReq, IncID, IncDQ, InsRights, InsValue, LocOOR, PostRef, QualNS. (required) |
| –– Detail | Detail on the result. |
| – Result | Result of the operation. One of: feasible, not_feasible, deferred. (required) |
| ServiceFailures | Failures of external domain knowledge sources. |
| – Service | Name of the external service. (required) |
| – RequestID | Identifier of the Request that the Response answers. |
| – Kind | Kind of source or of failure. One of: transient, permanent. (required) |
Conformance Testing
Data conforms with AUC-DAC 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.