[AI-DLC TEST] Nova Worker Document Management (Nova WDM)¶
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_edm | reverse-scoped from a shipped, ServiceNow-certified application (v2026.06.00)
Major Change History¶
| Version | Date | Author / Notes |
|---|---|---|
| 1 | 2026-08-07 | Vanessa Gutierrez — Feature Set created, reverse-scoped from the shipped Nova WDM (x_novaw_edm) Solution Design Document and supporting PRD material. |
Business case¶
- What's broken today: HR document handling for workers happens outside any governed system — offer letters, tax/compliance forms (I-9, W-4/W-2), immigration/visa paperwork, certifications, and separation records accumulate across file shares, email, and disconnected systems. The specific moment of failure: a work-authorization document or a professional certification expires and goes unnoticed until an audit or a compliance escalation, because nothing ties expiration dates to worker eligibility or automatically tracks renewal. Document metadata (dates, parties, identifiers) is keyed by hand, and access to sensitive documents (immigration status, performance warnings, medical certifications) is enforced inconsistently rather than by a defined role/relationship model.
- Who has the problem: HR Operations and HR business partners (manage documents across the workforce, including multi-tenant/MSP HR service providers managing several client workforces), people managers (need visibility into their direct reports' document/compliance status), and employees across worker types — salaried, hourly, and contingent — needing self-service access to their own records.
- Measurable cost: manual data entry per uploaded document; compliance exposure on regulated document types (I-9, FMLA/ADA, immigration/visa) when expirations aren't caught; audit findings when retention/expiry can't be demonstrated; HR time spent chasing signatures and re-keying metadata instead of doing case work.
- Value to customers: a single governed, worker-linked document repository with AI-assisted classification and metadata extraction (removing manual keying), least-privilege access enforced by role + relationship + document-type allowlist, automated lifecycle/expiry tracking with a daily enforcement sweep, integrated e-signature (DocuSign) with automatic status sync back to the document, and conversational self-service so employees and managers can review or ask about documents without opening a case.
- Value to Novaworks: document handling is foundational HR infrastructure every HCM buyer expects — its absence would block Core HR deals outright, not just weaken them. Shipping it also extends the Nova TWM agent framework's reach into a new transactional surface (agent-driven upload and Q&A), reinforcing "AI-native platform" as a cross-suite positioning rather than a claim specific to one app. It opens compliance-sensitive verticals (regulated industries, immigration-heavy workforces) and multi-tenant HR service providers as segments where governed document handling is a differentiated requirement, not a nice-to-have.
- Novaworks lens: the document repository itself is table-stakes — every HCM vendor in the reference set has attachment/document storage. Novaworks' deliberate differentiation is the AI layer on top of it: automatic classification and metadata extraction instead of manual tagging (EDMDocumentExtractor/EDMMetadataMapper), a validation gate that catches owner-mismatch and expiry-sanity errors before they reach HR, and conversational upload/Q&A through the same agent framework used across every other Nova scoped app — not a bolt-on chatbot specific to this one. This is an intended "own way" bet, not a deliberate table-stakes call.
Goal¶
Every worker's documents — offer letters, compliance forms, certifications, immigration paperwork, signed agreements — have a single governed home on the Now Platform, tied to their Core HR worker/person record. Uploads are automatically classified and validated, access follows role and relationship, expirations are tracked and enforced automatically, signatures close the loop through DocuSign, and workers, managers, and HR can review documents through a portal or ask about them conversationally.
Scope¶
New scoped application x_novaw_edm (Nova Worker Document Management): 5 custom tables (category, document type, document, document signature, document metadata), 8 script includes, 6 business rules, 1 scheduled job, the edm_agent Scripted REST API, a Service Portal Document Page + widget, and AI agent transactions registered in x_novaw_platform. Depends on x_novaw_corehcm (Nova Core HR — worker/person master data) and x_novaw_platform (Nova TWM agent framework). Integrates with an external document-extraction microservice and the ServiceNow DocuSign spoke.
Note: the shipped app uses the x_novaw_edm_* table prefix — consistent with nova-corehcm-sn-app's actual x_novaw_corehcm_* prefix, and in the same tension specs-corehr/CLAUDE.md already flags against naming-and-references.md's stated x_nova_corehcm_*. This Feature Set adds a second confirmed data point for x_novaw_ as the real prefix — see Open Questions.
Sources¶
- Nova WDM Solution Design Document, app version 2026.06.00 (ServiceNow Store Certification package) — primary source for current shipped state: business case, personas, use cases, data model, roles/ACLs, integrations.
- Nova EDM Overview (early vision/design-principles doc; predates the Employee → Worker rename).
- Upload Worker Document — Nova EDM transaction reference (agent transaction contract for chat-based upload).
Related PRDs¶
- Nova Core HR (
x_novaw_corehcm) — hard schema dependency; not yet its own Feature Set in this repo. - Nova WDM Bulk Transactions Story Registry — a drafted-but-not-yet-shipped extension (batch upload, matching-key-based bulk operations) found alongside the WDM source material. Not incorporated into this concept — see Open Question 3.
Who this is for¶
| Persona / Role | Friction today | Value gained |
|---|---|---|
| Employee | Documents and compliance/certification status are scattered with no single place to check them; signatures get chased manually. | Self-service portal (Needs Attention / Documents / Certifications) and conversational Q&A over their own documents; DocuSign closes the signature loop without leaving the conversation. |
| Manager | No visibility into a direct report's document or compliance status without asking HR directly. | Read access to their team's documents, validated against the Core HR manager chain, to check compliance readiness without filing a request. |
| HR Operations | Manually keys document metadata from scattered files, chases expirations by hand, and enforces access to sensitive document types inconsistently. | AI-extracted and validated metadata, an automated daily expiry sweep, and role + document-type allowlists that enforce least-privilege without custom code. |
| System Admin | No configurable way to define document taxonomy, categories, or extraction rules without engineering involvement. | Administers categories, document types, extraction schemas, and validation prompts through configuration. |
What we are building¶
Candidate Features below are grouped from the shipped app's use cases (UC-1–UC-7); none has a spec.md yet — Feature-level scoping is a separate session per convention.
| # | Feature | Folder |
|---|---|---|
| 1 | Worker Document Upload, Classification & Lifecycle (capture, AI classification/extraction, validation, replace-in-place, daily expiry enforcement) | not yet seeded |
| 2 | Conversational Document Agent (chat-based upload and Q&A over a worker's documents) | not yet seeded |
| 3 | Employee Self-Service Document Portal (Service Portal Document Page: Needs Attention / Documents / Certifications) | not yet seeded |
| 4 | Document E-Signature (DocuSign send, envelope events, signature-status sync) | not yet seeded |
| 5 | Document Taxonomy & Extraction Schema Administration | not yet seeded |
Role-based access (EDMDocumentAcl) is cross-cutting infrastructure underlying all five Features above, not a standalone customer-announceable capability, so it isn't listed as its own row.
Table-Stakes & Differentiation¶
| Table-stakes capability | Bar set by | Where we cover it |
|---|---|---|
| Centralized document repository linked to the worker record | Workday, BambooHR, Rippling | Feature 1 |
| Role-based / least-privilege access to sensitive documents | Workday, BambooHR, Rippling | Feature 1 |
| E-signature integration | BambooHR, Rippling (native or via DocuSign/HelloSign) | Feature 4 |
| Expiration / renewal tracking for compliance documents | Workday, BambooHR | Feature 1 |
Headwind: incumbency — Workday, BambooHR, and Rippling already hold customers' sensitive compliance documents inside suites they already pay for and trust; the switching-cost and trust barrier is the obstacle here, not feature parity.
Differentiation. - AI-assisted classification and metadata extraction removes manual upload-and-tag work entirely, instead of the manual tagging flow competitors ship (Feature 1). - Conversational upload and Q&A run through the same Nova agent framework used across the whole product suite, not a bolt-on chatbot scoped to this one app (Feature 2). - A validation gate (owner-name match, expiry sanity) catches document errors before they reach HR, rather than surfacing bad data downstream (Feature 1).
UX & Interaction Design¶
No Figma or Claude Design link found during sourcing. The shipped UI is documented in the Nova WDM Solution Design Document's Attachment Index (ER diagram, use case model, process model) and its own description of the Service Portal Document Page and documents-widget.
Open Questions¶
| # | Question | Blocks |
|---|---|---|
| 1 | The shipped app confirms x_novaw_edm_* as its real table prefix, matching x_novaw_corehcm_* — should naming-and-references.md's Core HR section be corrected from x_nova_corehcm_* to x_novaw_corehcm_* now that a second app confirms the same pattern? |
Citing a table prefix in any future Feature spec without a redundant caveat. |
| 2 | The data model ships category_permission and four cat_*_can_access_mtom tables for category-level access, but the solution doc states the actual enforcement is the EDMDocumentAcl script, not this scaffolding. Is the scaffolding a planned future mechanism, or a known-unused artifact? |
Whether a future schema-changes.md documents it as reserved or omits it. |
| 3 | The WDM Bulk Transactions Story Registry describes batch/matching-key-based bulk operations not present in the shipped app. Is that in scope as a Feature under this Feature Set, or does it belong to a separate future Feature Set? | Whether to seed it as a 6th Feature row now or leave it out until scoped. |
For internal engineering review only. Not for external distribution.
Novaworks AI | Confidential