Nova AI Guardrails & Sensitive Conversation Routing¶
Questions or comments?
Post them as a comment on the tracking issue -- requires a GitHub account with access to this repo.
Novaworks AI | x_novaw_platform + Nova scoped apps | v0.1 Draft | IN-PROGRESS
History¶
| Version | Date | Author / Notes |
|---|---|---|
| 1 | July 29, 2026 | Eswar Vandanapu — Feature Set created from the Nova AI Guardrails & Sensitive Conversation Routing PRD v0.1. |
Business case¶
Nova's conversational agents (superagent, advisor, HR Concierge, and future scoped apps) today send user input straight to the model and the model's output straight to the user, with no shared checkpoint in between. There is no consistent way to catch a manipulated or off-policy prompt before it is answered, no consistent way to catch a policy-violating, hallucinated, or data-leaking response before it is shown, and no reliable way to recognize that a conversation has turned sensitive — harassment, discrimination, self-harm, legal threat, workplace safety — and get a human involved. Where checks exist today they are ad hoc, per-app, and undocumented, which leaves HR Operations without a queue of what needs their attention and leaves Compliance without an audit trail of what the agent was asked, what it almost said, or why.
Goal¶
A shared guardrail framework — one guardrail service called the same way by every Nova scoped app — that screens every inbound prompt before it reaches the model, screens every generated response before it reaches the user, detects when a conversation has turned sensitive, and reliably routes sensitive or blocked conversations to a human. Administrators can tune thresholds and routing per customer or pilot group on the same targeting pattern as the platform feature-flag service, and every guardrail decision is captured in a reason-coded audit log defensible to Compliance and Trust & Safety.
Scope¶
x_novaw_platform and all Nova scoped apps (corehcm, superagent, edm, onb, comp, advisor, frontend); new x_novaw_guardrails service.
Sources¶
Nova Platform Enhancements PRD v0.4; Nova TWM Platform, Frontend & HR Concierge solution designs; industry LLM guardrail and content-moderation practice. Primary source (per frontmatter) kept at reference/Nova_AI_Guardrails_Sensitive_Routing_PRD_v0_1.docx for durability.
Related PRDs¶
- Nova Platform Enhancements v0.4 (correlation-id tracing, feature-flag service, per-conversation transaction visibility)
- HRBP Persona Canvas Experience v0.4
Who this is for¶
| Persona / Role | Friction today | Value gained |
|---|---|---|
| Employee / End User (primary) | Cannot tell whether a sensitive disclosure (harassment, health, legal, safety) will be handled appropriately by an AI agent; no guarantee an off-policy or manipulated response is caught before it reaches them. | Input and output screening on every turn, and sensitive topics reliably handed to a human rather than answered by the agent. |
| HR Operations / Case Management (primary) | No real-time visibility into which conversations are high-risk; escalations today depend on the employee re-reporting elsewhere. | A live queue of flagged conversations with full context handed off automatically, so nothing sensitive is missed. |
| Nova Platform / App Engineer | Guardrail logic, if it exists, is ad hoc and duplicated per app; no shared way to add or update a check across the suite. | One guardrail service every scoped app calls, with shared input/output checks and a shared routing decision. |
| Compliance / Legal / Trust & Safety | No audit trail of what the agent was asked, what it nearly said, or why a message was blocked or escalated. | A reason-coded audit log of every guardrail decision, defensible for compliance and post-incident review. |
| Customer SN Administrator | No way to tune sensitivity, thresholds, or which categories route to a human, per customer or per pilot group. | A configuration console — built on the same targeting pattern as feature flags — to tune and pilot guardrail policy. |
What we are building¶
Six capabilities across three stages: four are ready to build with minimal research (Refine), one is a research-and-direction task (Approach), and one needs a spike before commitment (Experiment).
| # | Feature | Stage | Folder |
|---|---|---|---|
| 1 | Input Guardrail Engine | Refine | input-guardrail-engine/spec.md |
| 2 | Output Guardrail Engine | Refine | output-guardrail-engine/spec.md |
| 3 | Guardrail Policy & Configuration Console | Refine | policy-configuration-console/spec.md |
| 4 | Guardrail Observability, Audit & Feedback Loop | Approach | guardrail-observability-audit-feedback/spec.md |
| 5 | Sensitive Conversation Detection & Routing | Experiment | sensitive-conversation-detection-routing/spec.md |
| 6 | Human Escalation & Context Handoff | Refine | human-escalation-context-handoff/spec.md |
Prioritization & Sequencing¶
A light audit informs the build; only Feature 5 needs a spike, and Feature 4 sets direction alongside it.
- Phase 1 — Audit (light, gate): inventory the ad hoc checks each app runs today (feeds F1/F2); confirm the sensitive-category model is customer-defined (name, description, examples) rather than a fixed taxonomy Novaworks catalogs — Novaworks seeds a starter example set at feature completion, in the implementation guide (feeds F3, F5); confirm which queues and case systems can receive an escalation (feeds F6). This is the minimal research the build features rely on.
- Spike — Experiment: F5 proves sensitive-conversation classification meets the false-negative bar on crisis content, and that routing fits within normal response latency, before its delivery plan is committed.
- Build — Refine: F1 input guardrails, F2 output guardrails, F3 the policy console, and F6 escalation handoff are implementable with minimal research and go straight to delivery.
- Direction — Approach: F4 produces an options-and-decision doc that the audit and logging approach for every guardrail decision then follows.
Grouping.
- Quick wins: output guardrails (F2), which can lean on established content-moderation patterns, and the policy console (F3), which extends the existing feature-flag targeting layer.
- Core: sensitive-conversation detection and routing (F5) and the escalation handoff that depends on it (F6).
- Heavy lift: the input guardrail engine (F1), given the breadth of prompt-injection and jailbreak patterns to cover.
- Foundation-first: observability, audit, and the feedback loop (F4), since compliance sign-off on the whole framework depends on it.
Table-Stakes & Differentiation¶
| Table-stakes capability | Bar set by | Where we cover it |
|---|---|---|
| Pre-inference input screening (prompt injection, jailbreak, PII intake) | Mature LLM platforms screen every inbound prompt before it reaches the model. | Feature 1 |
| Post-inference output screening (policy, hallucination, PII leakage) | Production agent stacks validate a response before it is shown to the user. | Feature 2 |
| Configurable policy by tenant / group | Rollout tooling resolves guardrail behavior by customer and cohort, not one global switch. | Feature 3 |
| Auditable decision log | Trust & safety and compliance require a reason-coded record of every block, allow, and escalation. | Feature 4 |
| Sensitive-topic detection with human handoff | Regulated and HR-adjacent products route self-harm, harassment, and legal risk to a human, not a bot. | Features 5–6 |
Differentiation. One guardrail service, called the same way, by every Nova scoped app — the same input/output checkpoints, the same sensitive-conversation taxonomy, and the same policy console — rather than each app inventing its own checks. Escalations carry the correlation id from the platform tracing work, so a flagged conversation can be followed from the chat surface through to the human who picked it up.
UX & Interaction Design¶
Link to Figma — [To be added]
Open Questions¶
- Figma link / interaction design for the policy console (F3) and HR Operations escalation queue (F6) is not yet available.
- Feature 5's spike (classifier false-negative rate on crisis content, routing latency) has not yet run — its outcome may change the Feature 5/6 delivery plan.
- Feature 4's storage direction (existing platform data store vs. a dedicated guardrail data store) and feedback-loop approach (human-in-the-loop relabeling vs. periodic offline review) are undecided.
Status: DRAFT / IN-PROGRESS — derived from Nova AI Guardrails & Sensitive Conversation Routing PRD v0.1. For internal engineering review only. Not for external distribution.
Novaworks AI | Confidential