Glossary

Starting set, pulled from recurring ambiguity and cross-cutting concepts found across ~/nova-all docs, PRDs, and this repo's Feature Sets — both naming disambiguation ("is X the same as Y, which name to use") and concepts that recur across more than one Feature Set. Add to this as new terms or concepts need pinning down; a concept that only shows up in one spec belongs in that spec, not here.

Super Agent / Nova HR Concierge

Same thing, two names used in different places: Super Agent is the engineering/repo name (nova-superagent-agent, nova-superagent-sn-app); Nova HR Concierge is the customer-facing product name used throughout implementation-guide and the front-end. It's the orchestrator that receives the user's natural-language request, decomposes multi-step transactions, and delegates to Functional Agents.

Worth stating explicitly because engineering docs and PRDs (Requirements/ticketing-integrations/ticket-integrations.md) use "Super Agent" while customer-facing docs use "HR Concierge" interchangeably with no cross-reference — a reader moving between the two doc sets currently has to infer they're the same thing.

Functional Agent (FA)

The canonical term is Functional Agent (see nova-claude-plugins/.../nova-functional-agent/SKILL.md): a Python service handling one domain of work (Core HCM, Time & Attendance, etc.), receiving a task from the Super Agent and returning a structured result over HTTP.

"Special agent" shows up as a looser synonym in customer-facing feature copy (nova-feature-list/features.md) and some PRDs write "Functional/Special agents" as if hedging between two terms for the same thing (see the blocking open item in ticket-integrations.md — the ambiguity itself became a literal open question blocking a Feature). Recommend standardizing on Functional Agent (FA) everywhere and treating "special agent" as deprecated phrasing.

Host surface

Any surface — third-party (Gemini Workspace) or native (SN Portal,
mobile) — through which an employee chats with Novaworks agents.
Conversations are owned by Novaworks regardless of host; what a given host
surface can natively support (rich rendering, notifications, document
actions) varies, and that variance is what drives most of
ai-chat-surfaces's fallback design.

See feature-sets/ai-chat-surfaces/concept.md,
feature-sets/ai-chat-surfaces/continue-in-novaworks/spec.md,
feature-sets/ai-chat-surfaces/notifications/spec.md.

Trigger condition / fallback ("Continue in Novaworks")

A defined set of conditions — unsupported form rendering, a turn-count
threshold, an unsupported document action, or any gateway-untranslatable
response — under which the gateway offers a deep link back to the
Novaworks portal as the fallback of last resort when a host surface can't
continue a conversation natively.

See feature-sets/ai-chat-surfaces/concept.md (Section 4),
feature-sets/ai-chat-surfaces/continue-in-novaworks/spec.md.

Sensitive conversation

A conversation turn classified into a risk category (harassment/
discrimination, self-harm/mental-health crisis, legal/compliance threat,
workplace safety) that requires the agent to soften its response, continue
carefully, or hand off to a human immediately. False negatives on
crisis-level content are treated as unacceptable, not just undesirable.

See feature-sets/ai-guardrails-sensitive-routing/concept.md,
feature-sets/ai-guardrails-sensitive-routing/sensitive-conversation-detection-routing/spec.md.

Guardrail (input/output checkpoint)

A shared checkpoint service called uniformly by every Nova scoped app to
screen inbound prompts (injection, jailbreak, regulated-data requests) and
generated responses (policy violations, hallucination, PII exposure, tone)
before they reach the model or the user — replacing the ad hoc, per-app
checks engineers were otherwise building independently.

See feature-sets/ai-guardrails-sensitive-routing/concept.md,
feature-sets/ai-guardrails-sensitive-routing/input-guardrail-engine/spec.md,
feature-sets/ai-guardrails-sensitive-routing/output-guardrail-engine/spec.md.

Human escalation / handoff

The mechanism that carries full conversation context, the triggering
reason, and a correlation id from a guardrail or sensitive-conversation
trigger into a queue HR Operations actually watches in real time — distinct
from the ticketing module's escalation path below, which exists for a
different failure mode (agent couldn't fulfill a request, not a
sensitive-content trigger).

See feature-sets/ai-guardrails-sensitive-routing/human-escalation-context-handoff/spec.md,
feature-sets/ai-guardrails-sensitive-routing/concept.md.

Ticketing / human escalation (as fallback for agent failure)

A minimal proxy-and-router module — deliberately not a case-management
system — that converts an unfulfillable request, an explicit user request,
or a technical execution failure into a ticket. Insourced (a scoped SN app)
is the mid-market default; outsourced (via a customer-configured Script
extension point) targets enterprise customers with an existing ticketing
system of record.

See feature-sets/ticketing-integrations/concept.md.

Correlation id / conversation tracing

An identifier that travels with a conversation across guardrail decisions
and escalations, so a flagged conversation can be followed end-to-end —
from the originating chat surface through to whichever human or system
handles it.

See feature-sets/ai-guardrails-sensitive-routing/concept.md,
feature-sets/ai-guardrails-sensitive-routing/guardrail-observability-audit-feedback/spec.md,
feature-sets/ai-guardrails-sensitive-routing/human-escalation-context-handoff/spec.md.

Platform reference

Moved to skills-product/naming-and-references.md's "Core HR domain reference" section — centralized there alongside every other domain's equivalent reference facts rather than staying in this repo's own glossary. nova-feature-set/ nova-feature read it from there now.

Not carried over from the old novaworks-prd skill in that move: the static "Key team" roster (who's CTO/CPO/designer/researcher/SME). owner/product-manager frontmatter is now sourced per Feature Set/Feature — from the GitHub issue assignee where one exists, per the AI-DLC decision log — rather than assumed from a fixed roster that goes stale the moment a role changes hands.