Skip to content

Schema changes for nova-policy-advisor

AI-DRAFT. Written against ../../schema/nova-advisor-sn-app.md (reverse-engineered, accepted as-is — not authored or confirmed by the team that owns the app). Re-validate this delta if that doc changes after further review.

What already exists (per the reverse-engineered schema doc)

x_novaw_advisor_thread and x_novaw_advisor_message already cover most of the Auditable Conversation History feature's persistence needs — a thread has a kb_knowledge reference (the article it's grounded in) and a status; messages are ordered, timestamped, and attributed. This Feature Set does not propose new tables for that part.

The app's PolicyService/PolicyServiceImpl script includes and "Policy editor"/"Policy List" widgets already exist in the x_novaw_advisor scope, but — per the reverse-engineered schema doc's Open Question #6 — no Policy table exists in this app's dictionary export. This Feature Set's Native Policy Editor feature is written on the assumption that policy content is modeled as ServiceNow Knowledge Base articles (kb_knowledge/kb_knowledge_base, out-of-box tables, external to this scope) rather than a bespoke Policy table — consistent with the source PRD's description of policies as "KB articles" throughout. This assumption needs confirmation from whoever owns PolicyService before it's treated as settled — if policy content is actually meant to live in a dedicated table, that's a materially different schema delta than the one below.

Proposed delta

  1. KB ownership/manager fields. The Knowledge Base Governance feature (System Admin assigns/removes KB owners and managers) needs owner/manager fields at the kb_knowledge_base level. Confirm whether OOB kb_knowledge_base already carries an owner/manager field usable as-is, or whether this app needs its own x_novaw_advisor_kb_manager m2m-style table (owner-per-KB, manager-per-KB, both referencing sys_user) — the cross-scope privilege on x_novaw_platform_kb_base_type_m2m noted in the reverse-engineered schema doc suggests a similar m2m pattern may already exist for a related concept (KB base type) and could be a model to follow rather than inventing a new shape.
  2. In-editor policy creation + manager assignment. The PRD states the editor "as of early July" supports creating a brand-new policy directly in the tool (not just editing existing KB articles) and assigning a manager to it. If this is net-new relative to what ships today, it likely needs no new table (creation still produces a standard kb_knowledge record) but does depend on the KB ownership/manager delta above being in place first.
  3. No new fields proposed on x_novaw_advisor_thread / x_novaw_advisor_message. The existing kb_knowledge reference, status, ordered content/role/sent_at fields already satisfy the Conversational Policy Advisor and Auditable Conversation History features' persistence needs, per the reverse-engineered schema doc. Revisit only if construction turns up a concrete gap (e.g. a field to record which grounding tier — see the Codex Curator three-tier model — an answer came from, since neither table currently has one).

Once the schema-first gate is signed on the above, apply this delta to ../../schema/ and flip status to applied.