KnowledgeAnswersSensitivityInstruction

GoogleApi.ContentWarehouse.V1.Model.KnowledgeAnswersSensitivityInstruction


Table of Contents ▼

Jump to a specific part of the page:

Description

Instructions (eg., logging, disambiguation, ads serving) of handling a sensitive intent and its data. LINT.IfChange NextId: 8

Attributes List

This module has the following attributes (case-insensitive ascending order):

View Attributes

Attributes

  1. argument (type: GoogleApi.ContentWarehouse.V1.Model.KnowledgeAnswersSensitivityInstructionArgument, default: nil)
    -
  2. intent (type: GoogleApi.ContentWarehouse.V1.Model.KnowledgeAnswersSensitivityInstructionIntent, default: nil)
    -
  3. legacyAssistantSensitivity (type: GoogleApi.ContentWarehouse.V1.Model.SearchPolicyRankableSensitivity, default: nil)
    - This field is for backward compatibility.
  4. multiAccountAllowed (type: boolean(), default: nil)
    - Controls whether a top-level intent is multi-account approved. NLU will do go/cross-account-understanding only for intents with this bit on. Also, this bit should be propagated to user turn Attentionl Entities to extend protection of cross-account data to next turns. In principle fulfillment services (e.g., Monastery) should only dispatch such intents to multi-account approved fulfillers (schemas), at least when the user has a linked dasher account. The Assistant runtime policy engine should treat a query as dasher data if 1) this bit is true in the string redaction, and 2) the user has a linked dasher account, and apply a more restrictive rule for whitelisting, regardless of the actual account provenance in Sensitivity. Example: [User logged in to their personal gmail account.] Q1: "Schedule a meeting tiltled okr review at 3pm". Assistant: "Should I scheduled it on your xyz@gmail.com account?" Q2: "No, add it to my xyz@bigcorp.com account." We don't know Q1 is dasher data until Q2. To prevent leaking of Q1 to non-dasher approved binaries, this bit should be used as a proactive measure. It might introduce some over-triggering (e.g., user says "Yes" in Q2), but is much better than blindly treating every query as dasher, not considering whether it actually triggers any multi-account capable intents or not (see b/164420114 for example).
  5. previousQuery (type: GoogleApi.ContentWarehouse.V1.Model.KnowledgeAnswersSensitivityInstructionPreviousQuery, default: nil)
    -

Type

@type t() :: %GoogleApi.ContentWarehouse.V1.Model.KnowledgeAnswersSensitivityInstruction{
argument: GoogleApi.ContentWarehouse.V1.Model.KnowledgeAnswersSensitivityInstructionArgument.t() | nil,
intent: GoogleApi.ContentWarehouse.V1.Model.KnowledgeAnswersSensitivityInstructionIntent.t() | nil,
legacyAssistantSensitivity: GoogleApi.ContentWarehouse.V1.Model.SearchPolicyRankableSensitivity.t() | nil,
multiAccountAllowed: boolean() | nil,
previousQuery: GoogleApi.ContentWarehouse.V1.Model.KnowledgeAnswersSensitivityInstructionPreviousQuery.t() | nil
}

Function

@spec decode(struct(), keyword()) :: struct()

Data sourced from HexDocs : GoogleApi.ContentWarehouse.V1.Model.KnowledgeAnswersSensitivityInstruction