Skip to content

supportdesk-intelligence.boundary-model.md

Latest commit

 

History

History
84 lines (60 loc) · 3.58 KB

supportdesk-intelligence.boundary-model.md

File metadata and controls

84 lines (60 loc) · 3.58 KB
Raw

Support Answer Provenance Boundary Model

Purpose

This document closes public issue #3: Add a support-answer provenance checklist that separates retrieval evidence from generated text.

It provides concrete agentic-enterprise evidence for SupportDesk Intelligence. The repo remains independent: it is not an AAIF project, not a Linux Foundation project, and not endorsed by either organization.

High-Risk Action Boundary

AI-generated customer-support answers that cite knowledge sources, summarize user data, escalate tickets, or suggest account actions.

Actors

Actor Responsibility
Support agent Owns customer-facing response approval and escalation.
Customer Provides conversation context and may share sensitive information.
Retrieval service Returns source snippets and document metadata.
Answer assistant Drafts answers from approved context but cannot invent source authority.
Supervisor Reviews escalations, QA samples, and policy-sensitive responses.

Identity Boundary

  • A drafted answer is not a support decision until a human agent approves or an approved automation policy permits it.
  • Retrieved evidence must be stored separately from generated answer text.
  • PII handling and ticket access must follow the support agent's role and tenant context.

Tool And Action Boundary

Action Boundary
knowledge.retrieve Allowed against approved knowledge sources and tenant scope.
answer.draft Allowed only with retrieved evidence ids and model/provider metadata.
answer.send Requires human approval unless a documented low-risk automation policy applies.
ticket.escalate Allowed when escalation rules match; must preserve reason and source evidence.
customer_data.read Requires role-based access and PII-aware logging.

Human Approval Gates

  • Before sending answers involving account status, billing, legal, security, or contractual terms.
  • Before using a low-confidence source in customer-facing text.
  • Before changing escalation policy or automation thresholds.
  • Before indexing new knowledge sources containing restricted or customer-specific data.

Audit Event Model

Event Minimum Evidence
conversation.message_received tenant, conversation id, channel, pii class
knowledge.evidence_retrieved source ids, score, version, tenant scope
answer.draft_created model, prompt version, evidence ids, confidence
agent.answer_approved agent id, answer id, edits applied
ticket.escalated reason, target queue, source answer id, supervisor flag

Local Proof Path

  • npm install to prove dependency resolution.
  • npm run lint for static validation.
  • npm run test for retrieval/provenance tests when present.
  • npm run build to prove the app compiles.
  • Manual inspection that answer text references evidence ids rather than only model output.

OSS And Self-Hosted Fallbacks

  • Use pgvector or Qdrant for local vector search.
  • Use PostgreSQL for ticket, conversation, and provenance metadata.
  • Use Ollama or vLLM adapters for local model testing.
  • Use OpenTelemetry or self-hosted logs for support workflow observability.

Contributor Follow-Up

Add an answer provenance fixture that stores evidence ids, generated text, approval status, and escalation reason separately.

Issue Closure Evidence

This document satisfies the issue checklist by separating:

  • identity or actor boundary
  • tool/provider/action boundary
  • human approval or escalation point
  • audit or observability events
  • OSS/self-hosted fallback direction
  • validation and static inspection path