FEATURE SPEC¶
Questions or comments?
Post them as a comment on the tracking issue -- requires a GitHub account with access to this repo.
Input Guardrail Engine¶
Novaworks AI | x_novaw_guardrails | Stage: Refine | DRAFT
Parent Feature Set: ../concept.md.
History¶
| Version | Date | Author / Notes |
|---|---|---|
| 1 | July 29, 2026 | Eswar Vandanapu — Initial draft, derived from PRD Feature 1. |
Problem Statement¶
Nova's conversational agents send user input straight to the model with no shared checkpoint. There is no consistent way to catch a prompt-injection or jailbreak attempt, sensitive/regulated data volunteered in the prompt (SSNs, health details), or a request clearly outside an app's intended scope, before the model answers it.
Scope¶
Screen every inbound user message before it reaches the model: - Prompt-injection and jailbreak attempts - Sensitive or regulated data volunteered in the prompt (e.g. SSNs, health details) - Requests clearly outside an app's intended scope
A blocked or modified input returns a safe, on-brand response rather than being silently dropped or passed through.
Out of Scope¶
- Output screening (see ../output-guardrail-engine/spec.md)
- Sensitive-conversation category classification and human handoff (see ../sensitive-conversation-detection-routing/spec.md)
Value¶
Employees get a consistent, on-brand response instead of a silently dropped or mishandled message when a prompt is manipulated, off-policy, or volunteers regulated data — and every Nova scoped app gets this for free by calling one shared checkpoint instead of building its own.
Delivery¶
Stand up the input-checkpoint service, wire it in front of superagent and advisor first, and define the safe-response pattern for each block reason.
Acceptance Criteria¶
- [ ] Input-checkpoint service is deployed and reachable by scoped apps as part of
x_novaw_guardrails - [ ] Superagent and advisor route all inbound user messages through the checkpoint before they reach the model
- [ ] Prompt-injection/jailbreak attempts are detected and blocked
- [ ] Sensitive/regulated data volunteered in the prompt (SSNs, health details, etc.) is detected
- [ ] Requests clearly outside an app's intended scope are detected
- [ ] Each block reason has a defined safe, on-brand response — no silent drop, no silent pass-through
- [ ] Every checkpoint decision (allow / block / modify) is reason-coded and available to Feature 4 (Observability, Audit & Feedback Loop)
Dependencies / Related Features¶
- Feature 3 — Guardrail Policy & Configuration Console: thresholds and which checks run are configured there, not hardcoded here.
- Feature 4 — Guardrail Observability, Audit & Feedback Loop: every input-checkpoint decision must be logged per that feature's inventory once it is defined.
- Feature 6 — Human Escalation & Context Handoff: a blocked input may need to route to a human queue rather than only returning a safe response — exact trigger conditions TBD.
Risks¶
| Risk | Severity | Mitigation |
|---|---|---|
| Breadth of prompt-injection/jailbreak patterns to cover | High | Flagged in the PRD as the "heavy lift" of this Feature Set; scope the initial pattern set from the Phase 1 audit rather than attempting full coverage at launch. |
| Over-blocking legitimate requests (false positives) | Medium | Reason-coded logging (Feature 4) enables tuning; policy console (Feature 3) allows per-tenant threshold adjustment. |
Open Questions¶
- What is the initial pattern/rule set for prompt-injection and jailbreak detection, and where does it come from (vendor library, in-house, both)?
- What counts as "clearly outside an app's intended scope" per app — is this a per-app configurable boundary or a shared taxonomy?
- Exact safe-response copy per block reason is not yet defined.
Status: DRAFT — derived from PRD Feature 1. For internal engineering review only.
Novaworks AI | Confidential