Open Floor Assistant Manifest Specification Version 1.0.1

The Open Floor Project Open Voice Interoperability Initiative - LF AI & Data Foundation

Version 1.0.1

Editor-in-Chief: David Attwater Contributors: Leah Barnes, Emmett Coin, Deborah Dahl, Diego Gosmar, Jim Larson, Rainer Türner, Dirk Schnelle-Walka, Allan Wylie

0. SCOPE AND INTRODUCTION

0.1 Document Scope

This document specifies the Open-Floor Assistant Manifest object format. It was developed as part of the Open Floor project within the Open Voice Interoperability Initiative - LF AI & Data Foundation (Open-Floor) Assistant Manifest.

0.2 Assistant Manifest Purpose

The Assistant Manifest is a structured description of the key characteristics and capabilities of a conversational assistant that is associated with a unique speakerUri. The manifest can be thought of as the curriculum vitae of the conversational agent and a public record of the services that it offers. It can be used, for example, by other agents or users to decide whether to invite a particular agent to join a conversation. In this regard, it is particularly relevant to discovery agents who provide services to other agents to help them find assistants to achieve certain tasks for them.

0.3 Approach and Potential Uses

The Assistant Manifest intentionally avoids the use of any domain-specific schemas or ontologies. This follows the philosophy of the Open Voice Interoperability Initiative regarding a dependence on natural language to give the loosest possible linkage between components.

The Assistant Manifest is a standardized data structure that is intended to be used as a component of other specifications; it is not a stand-alone document. Having said that, target uses for this manifest are as follows:

• Enable discovery agents to compile static indexes for rapid searching of a large number of agents.
• Enable discovery agents to use language model technology to rank agents for recommendation without asking specific questions of the target agents
• Provide information on request to potential user-agents to assist with their own ranking of candidate agents for a specific task.
• Provide vocalizable information that allows other agents to know how to address this agent in a conversation (e.g. what name to address the agent by)

One standard that uses this document format is [3] Interoperable Conversation Envelope Specification Version 1.0.1. That specification defines a number of events types that are designed to help conversational agents discover other agents for certain tasks. There are events for requesting and publishing manifests, and also events for finding and recommending agents for certain tasks. These events make use of all or part of the contents of the Assistant Manifest.

1. SPECIFICATION

1.1 Representation

The Assistant Manifest will be represented as a JSON [1] object in string format. This object will be embodied in other objects. It is not expected to stand alone as a document in its own right.

1.2 Protocol

JSON was chosen for the Open-Floor conversation envelope as it is an Open and Human Readable Standard format for Data Exchange that is independent of any particular protocol.

1.3 AAA & Security

Authorization, Authentication, Accounting, and Security specifications are outside the scope of this document and will be defined in separate documents.

1.4 Nomenclature

This specification uses camelCase (i.e., no spaces with new words capitalized) for all nominal property names, such as serviceUrl and supportedLayers.

1.5 Assistant Manifest Object Structure

{
    "identification":
    {
        "speakerUri" : "tag:dev.buerokratt.ee,2025:0001",
        "serviceUrl": "https://dev.buerokratt.ee/conversation",
        "organization": "Government of Estonia",
        "conversationalName": "Buerokratt",
        "department": "Passport Office",
        "role": "Immigration Specialist",
        "openFloorRoles" : { "convener" : True },
        "synopsis": "Immigration specialist as part of the Buerokratt system."
    },
    "capabilities": [
        {
            "keyphrases": [
                "visa",
                "immigration",
                "passport",
                "permanent resident"
            ],
            "languages": [
                "en-us"
            ],
            "descriptions": [
                "international travel to and from Estonia"
            ],
            "supportedLayers": {
                "input" : [ 
                    "text"
                ],
                "output" : [
                    "text"
                ]
            }
        }
    ]
}

Figure 1. Example Assistant Manifest Object

Figure 1 shows an example of an assistant manifest object. It has two mandatory sections, identification and capabilities, which are described below.

1.6 The identification object

The identification object publishes key aspects of the conversational assistant's role and identity. It should not contain specific information about specific services or capabilities that are offered. This section allows others to know how the agent refers to itself, the organization that it represents, and its role in serving its users.

The primary key of this data model is the speakerUri which should be a unique identifier of the agent - i.e. it can be thought of as the identity of the agent.

1.6.1 Open-Floor Roles

Open-Floor agents and conversants can publish in their manifest a willingness to adopt certain roles on the conversation floor.

The definitive list of valid keys is defined in [3].

A list of the valid roles in that document is repeated below, including the default values that will be assumed if the roles are not specified in the manifest.

Note that it is the responsibility of the floor manager to assign the role of a convener to a floor. The manifest record indicates willingness to perform the role. It is not a guarantee that this role will be assigned.

1.7 The capabilities object

The capabilities object describes the capabilities offered by the agent. The manifest is keyed to a speakerUri which is the unique identity of the agent being described. This agent may provide a large number of different services and have many different capabilities. For this reason, the capabilities object is expressed as an array of capability objects. Each capability object stands alone from the others. It represents a set of characteristics that work together independently of the other capability objects. For example, if one capability supports the Welsh language for banking functions and another supports the Inuit language for sports information, this does not mean that the agent can provide banking services in the Inuit language.

The capability object can be left empty, for example when a manifest is being used to represent a user and it is not neccessary to enumerate the capabilities of the user.

The features of each capability object are shown below.

2. Schema

The structure of a JSON conversation envelope is defined as a JSON Schema located at [https://github.com/open-voice-interoperability/docs/tree/main/schemas/assistant-manifest/1.0.1/assistant-manifest-schema.json]

3. References

• [1] https://www.ecma-international.org/publications-and-standards/standards/ecma-404/ ECMA-404 The JSON data interchange syntax
• [2] https://github.com/open-voice-interoperability/docs/blob/main/specifications/DialogEvents/1.0.2/InteropDialogEventSpecs.md Open Floor Dialog Event Object Specification Version 1.0.2
• [3] https://github.com/open-voice-interoperability/docs/blob/main/specifications/ConversationEnvelope/1.0.1/InteroperableConvEnvSpec.md Open Floor Inter-Agent Message Specification Version 1.0.1
• [4] https://www.rfc-editor.org/rfc/rfc5646.txt RFC 5646. BCP 47. Tags for Identifying Languages.
• [5] https://www.ietf.org/rfc/rfc4646.txt RFC 4646 Regarding Best Practice for Tags for Identifying Languages

4. Glossary of Terms

5. Decision Log

6. Document Change Log