Go to PGM-AUA V1.0 AI Modules

Function Ref. Model I/O Data SubAIMs JSON MData Profiles Ref. Software Conformance Performance

1. Function

The Domain Access (PGM‑DAC) AIM provides authoritative domain‑level semantics to two distinct classes of consumers within the A‑User Architecture: the Context Description AIM, which requires situational, single‑turn semantic grounding during perceptual processing; and the Basic Knowledge AIM (an LLM), which requires goal‑directed, multi‑turn semantic support during reasoning.

These two uses are logically distinct. Context Description-level domain access is situational and not goal‑directed. By contrast, reasoning‑level domain access is goal‑directed and deliberative. The Domain Access AIM serves both purposes without performing perception or reasoning. At the request of Basic Knowledge, while it deliberates, or of A-User Control it also validates the feasibility of Process Actions that are being considered, answering for each step with the PA Status vocabulary of MMM-TEC (Ack, or the reason for which the Process Action would be refused: Clash, FaultyReq, IncID, IncDQ, InsRights, InsValue, LocOOR, PostRef or QualNS).

Domain Access operates on

  1. AUC-DAC Request instructions from the A‑User Control AIM;
  2. Domain Requests from the Context Description AIM via the Directed Semantic Query Interface;
  3. BKN‑DAC Requests from the Basic Knowledge AIM via the Dialogic Semantic Query Interface (MCP).
  4. DAC Interaction History Response from the Private Storage of the Module, in reply to its own request.

Domain Requests from the Context Description AIM and BKN‑DAC Requests from the Basic Knowledge AIM are resolved using external domain knowledge sources accessible to Domain Access.

It produces

  1. Domain Responses to the Context Description AIM, appropriate to the Subject of the Request (audio, visual, user or ava);
  2. BKN‑DAC Responses to the Basic Knowledge AIM supporting multi‑turn deliberative exchanges;
  3. DAC Interaction History Requests to the Private Storage of the Module, to obtain Interaction History;
  4. AUC-DAC Response reporting to the A‑User Control AIM.

A conforming Domain Access implementation shall observe the following behavioural requirements. The implementation:

  1. Shall expose a Directed Semantic Query Interface for operational, single‑turn Domain Requests from the Context Description AIM. This interface is stateless: no session continuity is preserved across successive requests.
  2. Shall expose a Dialogic Semantic Query Interface implemented using the Model Context Protocol (MCP) for multi‑turn Domain Requests from the Basic Knowledge AIM.  This interface is session‑oriented: semantic commitments may be preserved across successive exchanges within the same session.
  3. Shall resolve Domain Requests and BKN‑DAC Requests against external domain knowledge sources. The M‑Instance may be the sole provider of domain knowledge services accessible by the Domain Access AIM.
  4. Shall return Domain Responses appropriate to the Subject of the Request (audio, visual, user or ava) when responding to the Context Description AIM.
  5. Shall not modify perceptual or User descriptors produced by other AI Modules.
  6. Shall not maintain perception state or User State beyond that required for MCP session continuity.
  7. If a requested external domain knowledge source is unavailable or returns an error, the Domain Access AIM shall report the failure in AUC-DAC Response identifying the requested service, the request that triggered the failure, and whether the failure is transient or permanent. Thus the A‑User Control AIM can determine the appropriate course of action.
  8. Shall, for each Process Action submitted for validation, answer with the PA Status that it would receive (Ack or the reason of the refusal), and with an overall result.

2. Reference Model

Figure 1 depicts the Reference Model of the Domain Access (PGM‑DAC) AIM.

Figure 1 – Reference Model of the Domain Access (PGM‑DAC) AIM

3. Input/Output Data

Table 1 specifies the Input and Output Data of the Domain Access (PGM‑DAC) AIM.

Table 1 – Input/Output Data of the Domain Access (PGM‑DAC) AIM

Input Description
AUC-DAC Request Request from the A-User Control AIM that sets the goal, the domain context, the domain operations to perform, the sources that may be used and, when needed, the Process Actions whose feasibility is to be validated.
Domain Request A single‑turn semantic grounding request from the Context Description AIM via the Directed Semantic Query Interface.
BKN‑DAC Request A Multi‑turn domain knowledge request from the Basic Knowledge AIM via the Dialogic Semantic Query Interface.
DAC Interaction History Response Interaction History elements returned by the Private Storage of the Module in reply to a DAC Interaction History Request.
Output Description
Domain Response Structured domain knowledge returned to the Context Description AIM, appropriate to the Subject of the Request (audio, visual, user or ava).
BKN‑DAC Response Domain knowledge response to the Basic Knowledge AIM supporting multi‑turn deliberative exchanges via the Dialogic Semantic Query Interface.
DAC Interaction History Request Request to the Private Storage of the Module for Interaction History elements that support the deliberative exchanges.
AUC-DAC Response Response describing the execution and outcome of DAC processing, including any external service access failures. This information is reported to the A‑User Control AIM.

4. SubAIMs (Informative)

This section is informative. The decomposition into SubAIMs described below illustrates one conformant architecture for producing the normative outputs of PGM‑DAC. Implementations may adopt alternative internal structures, provided that they satisfy the conformance requirements of Section 8.

4.1 Reference Model

Figure 2 depicts the Reference Model of the Domain Access (PGM‑DAC) Composite AIM.

Figure 2 – Reference Model of the Domain Access (PGM‑DAC) Composite AIM

4.2 Operation

The Domain Access AIM operation receives Domain Requests from the Context Description AIM and BKN‑DAC Requests from the Basic Knowledge AIM; resolves them against external domain knowledge sources; and assembles the responses along with the execution status.

The Perceptual Domain Access Sub-AIM serves the Context Description AIM. It receives Domain Requests via the Directed Semantic Query Interface; resolves them against the relevant external domain knowledge source; and returns Domain Responses appropriate to the Subject of the Request. Each request is stateless and self‑contained; it obtains Interaction History from the Private Storage of the Module when it needs it.

The Deliberative Domain Access Sub-AIM serves the Basic Knowledge AIM. It receives BKN‑DAC Requests via the Dialogic Semantic Query Interface; maintains session continuity across successive exchanges; resolves requests using the relevant external domain knowledge sources; obtains Interaction History from the Private Storage of the Module; and returns BKN‑DAC Responses supporting multi‑turn deliberative reasoning.

4.3 Functions of SubAIMs

Table 2 specifies the functions of the SubAIMs of the Domain Access (PGM‑DAC) Composite AIM.

Table 2 – Functions of the SubAIMs of the Domain Access (PGM‑DAC) Composite AIM

Name Function
Perceptual Domain Access Serves the Context Description AIM via the Directed Semantic Query Interface. Resolves single‑turn Domain Requests using external domain knowledge sources and returns Domain Responses appropriate to the Subject of the Request.
Deliberative Domain Access Serves the Basic Knowledge AIM via the Dialogic Semantic Query Interface. Resolves BKN‑DAC Requests using internal and external domain knowledge sources and returns BKN‑DAC Responses supporting multi‑turn deliberative reasoning.

4.4 Input/Output Data of SubAIMs

Table 3 lists the Input and Output Data of the SubAIMs of the Domain Access (PGM‑DAC) Composite AIM.

Table 3 – Input/Output Data of the SubAIMs of the Domain Access (PGM‑DAC) Composite AIM

Name Input Data Output Data
Perceptual Domain Access Domain Request
AUC-DAC Request
DAC Interaction History Response		 Domain Response
AUC-DAC Response
DAC Interaction History Request
Deliberative Domain Access BKN‑DAC Request
AUC-DAC Request
DAC Interaction History Response		 BKN‑DAC Response
AUC-DAC Response
DAC Interaction History Request

4.5 AIMs and JSON Metadata

Table 4 gives the Domain Access (AIM1) and its SubAIMs (AIM2).

Table 4 – Domain Access (AIM1) and its SubAIMs (AIM2)

AIM1 AIM2 Name JSON
PGM‑DAC Domain Access X
PGM‑PDA Perceptual Domain Access X
PGM‑DDA Deliberative Domain Access X

5. JSON Metadata

https://schemas.mpai.community/PGM1/V1.0/AIMs/DomainAccess.json

6. Profiles

No Profiles.

7. Reference Software

Not part of this specification.

8. Conformance Testing

A DAC implementation conforms with Domain Access (PGM‑DAC) if it satisfies the conformance requirements of Table 5.

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.

Table 5 – Conformance Testing Method for the Domain Access (PGM‑DAC) AIM

Receives AUC-DAC Request Shall validate against the AUC-DAC schema, with Mode RQ.
Domain Request Shall validate against the Domain schema, with Mode RQ.
BKN‑DAC Request Shall validate against the BKN‑DAC schema, with Mode RQ.
DAC Interaction History Response Shall validate against the Interaction History schema, with Mode RS.
Produces Domain Response Shall validate against the Domain schema, with Mode RS.
BKN‑DAC Response Shall validate against the BKN‑DAC schema, with Mode RS.
DAC Interaction History Request Shall validate against the Interaction History schema, with Mode RQ.
AUC-DAC Response Shall validate against the AUC-DAC schema, with Mode RS.

9. Performance Assessment

Not part of this specification.

Go to PGM-AUA V1.0 AI Modules