Skip to Content
Welcome to the Novantra documentation.
GuidesGovernanceModulesContent Extraction

Content Extraction

Content Extraction prepares source-owned records so Novantra can show extraction readiness, safe snippets, preview posture, keyword-search posture, OCR posture, and AI handoff readiness.

It is a shared foundation. It is not a second DMS, a local Document Intelligence store, or an AI-owned document repository. Source modules still own the original record, access rights, classification, retention, lifecycle status, deletion behavior, and final business workflow.

When you would use it

Use Content Extraction when an important record needs to become usable for preview, search, review, or AI-assisted workflows:

  • a DMS document version or uploaded source artifact;
  • a form submission or authored response;
  • governed evidence uploaded for an audit package;
  • a party record or due-diligence attachment;
  • a submission package or public-upload workflow;
  • an Enterprise Connector source ref whose owner can provide source rights, lifecycle context, and source content through an approved adapter.

DMS, Forms, Governed Evidence, Governed Submissions, and supported Enterprise Connector refs are source owners exposed through the product. Open a DMS document detail page, select a version, then open the Content extraction right-lane tab to view readiness or request extraction with a reason. For Forms, open a form definition and use the Extraction tab to prepare the current published version for preview, search, and AI handoff. For Governed Evidence, open an evidence requirement or claim detail and use the same readiness panel to prepare structured evidence text without copying raw evidence context into extraction metadata. For Governed Submissions, open a submission requirement or package detail and use the same readiness panel to prepare structured requirement or package text without copying recipient, policy, evidence-claim, or event snapshots into extraction metadata. For Enterprise Connectors, the connector owner resolves the external source ref through its adapter, then Content Extraction owns the extracted text, chunks, search, preview, OCR, and AI handoff posture. Submitted form responses, evidence records, submission packages, and eligible connector refs use the same backend source-owner seam when an owning workflow requests extraction.

What the readiness panel shows

The readiness panel shows:

  • whether extraction has been requested and whether extracted chunks are ready;
  • whether preview is available for the selected source;
  • whether keyword search is available or pending the configured search runtime;
  • whether OCR is needed, configured, disabled by profile, disabled by policy, blocked by the source owner, unavailable, or low-confidence;
  • whether AI handoff is available for governed Document Intelligence and retrieval workflows;
  • warnings that explain missing providers, unsupported source formats, or policy restrictions.

The panel shows source references, snippets, anchors, counts, and posture. It does not expose raw storage keys, embeddings, vector IDs, provider payloads, or internal database details.

When the owning module already has a rendered preview or a directly previewable source artifact, Content Extraction can show safe artifact references from the shared artifacts/storage foundation. Raster page-image artifacts, such as governed PNG, JPEG, or WebP page previews supplied by a source owner or renderer, are surfaced as page-image preview variants with optional page numbers. The panel shows filenames, preview kind, and readiness; it does not expose storage keys, buckets, object paths, or artifact storage bindings.

When a source artifact is renderable but no rendered preview exists yet, the panel can request preview generation with a governed reason. Content Extraction owns the request contract and readiness refresh, then delegates the actual render to the source owner. For DMS first, this uses the same DMS version render path that creates a rendered preview artifact through artifacts/storage. Cloud and on-prem deployments expose the same behavior through their deployment-specific storage coordination.

After extraction succeeds for a text-capable source, Content Extraction can also generate an encrypted text-preview artifact for the extracted chunks. This preview is owned by the shared content-extraction foundation, stored through the same artifacts/storage path in cloud and on-prem deployments, and shown only as a safe artifact reference in readiness panels.

When a source owner reports that content, rights, classification, retention, legal-hold, archive, delete, parser, OCR, or provider posture changed, the derived extraction record is marked stale, blocked, or retired through the shared lifecycle seam. Search and AI handoff then degrade through the same readiness states instead of returning old snippets.

For AI handoff, Novantra also checks that the stored extraction source is still ready, that the source owner still reports matching current source lineage, and that at least one extracted chunk is still active and available for AI handoff. If all prepared chunks are stale, blocked, retired, or no longer available for AI handoff, Copilot readiness remains blocked until the source is refreshed or the owning policy/access issue is resolved.

DMS now sends these lifecycle signals automatically for authored content updates, version artifact/import/render changes, approval or supersession events, restore events, security-label changes, document access changes, document moves, folder access changes, and document archive events. Forms also sends lifecycle signals for template, template-version, response, response-artifact, and rendition-posture changes so derived extraction records become stale or retired without Forms writing extraction chunks or search state directly. Governed Evidence sends requirement and claim lifecycle signals so changed or archived evidence invalidates derived extraction records without evidence commands writing extraction chunks or search state directly. Governed Submissions sends requirement and package lifecycle signals; submission events mark the owning package stale instead of becoming standalone extraction sources. Source modules emit these lifecycle signals so derived extraction records stay current as source truth changes.

Folder access changes are processed through the DMS folder tree in background batches. This means large folders and subfolders can be marked blocked or stale through the shared content-extraction lifecycle seam without DMS writing extraction chunks, search tokens, preview state, OCR posture, or AI handoff state directly.

Operators can also mark an existing extraction source stale from Governance > Operations > Content extraction when a parser, OCR profile, provider profile, or source profile changes outside an owning source record event. This action records a governed reason, preserves source-owner truth, and degrades extraction/search/preview/OCR/AI handoff readiness until extraction is requested again under the current policy.

For broader parser, OCR, provider, or source-profile changes, operators can mark matching sources stale from the same console by source module, source type, and profile key. Metadata source-profile changes also send this invalidation automatically for affected source owners or exact source records. This is a governed fan-out request: it does not force extraction, bypass source access, copy metadata values, or mutate the owning module. It only marks derived extraction/search/preview/OCR/AI handoff state stale so the normal extraction path can rebuild under current policy.

Search, OCR, and AI handoff

Extraction can work without AI. Authored text can be normalized and chunked so the source has a stable readiness record even in no-AI or limited-provider deployments.

Semantic retrieval and RAG profiles depend on the AI context and retrieval configuration. pgvector or another approved vector capability is only required when semantic retrieval is enabled. Keyword or digest-search readiness should be treated separately from vector retrieval.

When semantic retrieval is enabled, AI Context records embedding lineage for approved chunks. Those records carry backend kind, model, dimension, source lineage, lifecycle status, rights, classification, retention, and policy snapshots. They do not expose vector values, vector IDs, backend table names, raw extracted text, or provider payloads to source modules or document pages.

When extraction completes for an AI-enabled source, Novantra can hand the prepared source and chunk references to AI Context automatically. AI then records context-source, chunk, index-run, and embedding evidence through its own governed indexing path when the tenant has an approved embedding-capable provider model and the deployment has vector backend capability. If those capabilities are missing, the source can still be extracted and reviewed, but semantic retrieval remains visibly unavailable or misconfigured.

Deployments may use different approved vector backends. A small controlled corpus can use an AI-owned local exact-scan backend, while larger semantic retrieval profiles may use pgvector or a customer-hosted backend. The visible contract stays the same: Novantra reports vector capability state and safe retrieval evidence, not backend storage details.

AI Context includes a Vector status view for AI-enabled profiles. Use it to confirm whether semantic retrieval is configured, unavailable, or misconfigured before a reviewer depends on retrieval-heavy workflows. The status is separate from extraction, preview, OCR, and keyword-search readiness.

For pgvector-backed profiles, that status also separates database extension posture, index readiness, chunk embedding readiness, query embedding readiness, and native or approved external ranker availability. Built-in semantic-rag profiles inspect extension and index readiness through sanitized AI-owned catalog probes without exposing table names, index names, vector rows, or database connection details. A deployment should not be treated as RAG-ready when any readiness item is missing, even if extraction and keyword search are already working.

The built-in cloud and on-prem semantic-rag profiles apply the optional AI-owned pgvector migration ledger. Default AI profiles, keyword-only profiles, and no-AI profiles do not receive pgvector DDL. Source modules still interact with extraction/search/AI handoff through source refs, chunk refs, and capability states rather than pgvector tables or vector identifiers.

AI Context can also show a semantic retrieval preview for a reviewer-supplied query when a vector backend is available and tenant admins have approved a compatible query embedding model in AI Providers. Building or refreshing the vector corpus from governed chunks requires an approved chunk embedding model with a validated vector size. Operators still configure vector infrastructure for cloud or on-prem deployments, but tenant model choice is managed in the app. That preview ranks only chunks that first pass source-owner access and AI retrieval policy checks, and it returns safe source/chunk references rather than vector payloads or backend-specific details.

When Content Extraction marks a source stale, blocked, or retired, AI subscribes through its own runtime and updates context-source, chunk, and embedding lineage posture through AI-owned repositories. Source modules never update vector or embedding internals directly.

OCR is governed by deployment and tenant configuration. If a PDF, scan, image, or uploaded source artifact needs OCR and no governed OCR provider is available, the readiness panel shows that as a visible warning instead of silently pretending the source is searchable.

When an uploaded DMS source artifact is extracted, Content Extraction can call the deployment-provided artifact text resolver. AI-enabled cloud and on-prem profiles may back that resolver with the governed AI OCR/text-extraction seam; no-AI or unconfigured profiles return an unavailable posture. Successful artifact extraction records sanitized provider posture, parser/engine identifiers, language and text-direction hints, confidence, page/region/table citation summaries, and source anchors without exposing raw bytes, storage keys, provider payloads, embeddings, or internal storage details.

For supported Enterprise Connector sources such as SharePoint documents, Content Extraction can also use its built-in document text parser for launch-supported direct text, PDF text layers, DOCX, XLSX, PPTX, legacy DOC, and RTF. The connector supplies bounded in-memory bytes and safe source context, while extraction records parser posture, citation summaries, chunks, search, OCR readiness, and AI handoff state. Scans, images, SharePoint pages or HTML/ASPX files, legacy XLS/PPT, and other unsupported formats still need a governed OCR/parser path or show an explicit unsupported posture.

If OCR is blocked by policy, blocked by the source owner, unavailable because a provider is down or not configured, or completed with low confidence, the readiness panel and operator view show that condition separately. This lets reviewers decide whether to re-run extraction, change a tenant-approved OCR profile, request source-owner access review, or proceed with human validation.

If OCR reports RTL text or table anchors without verified parser support for that capability, the readiness panel shows that as a warning. This keeps bilingual and table-heavy sources reviewable without pretending the extracted layout is final truth.

Cloud and on-prem behavior

Cloud and on-prem deployments use the same content-extraction contracts and product behavior. Provider availability, OCR engines, semantic retrieval, and search runtime capabilities may differ by deployment profile, but those differences appear as capability states in the UI.

No-AI or no-provider deployments can still record source posture, extraction readiness for authored text, preview posture, warnings, and manual review context. They should not claim semantic retrieval or OCR readiness unless those capabilities are actually configured.

Both deployment modes use the same artifact text resolver contract. Cloud resolves artifacts through managed-cloud artifact/storage services, while on-prem resolves them through install-local artifact/storage services. The user-facing result is the same: extracted authored text where available, governed artifact text/OCR where configured, and explicit unavailable or unsupported states otherwise.

Cloud and on-prem operators should treat vector capability as a separate readiness item. If semantic retrieval is unavailable, extraction and keyword search may still be usable; if embedding records are stale, blocked, or dimension-incompatible, retrieval-heavy workflows should be reviewed before use.

Cloud and on-prem deployments should configure vector capability deliberately for the profile they run. Keyword-only and no-AI profiles do not need a vector backend. Semantic retrieval profiles need tenant-approved chunk and query embedding models plus a vector backend, and must show unavailable, stale, or dimension-mismatch posture when that configuration is missing or outdated.

Both deployment modes use the same extraction-to-AI handoff behavior. Cloud may use managed embedding/vector configuration and on-prem may use install-local or customer-hosted configuration, but source owners still emit source references and lifecycle posture while AI owns context indexing and vector retrieval evidence.

For the built-in semantic-rag profiles, cloud and on-prem use the same pgvector capability key, migration contribution, native AI-owned pgvector ranking path, and sanitized extension/index readiness probe. Operators should still confirm chunk and query embedding configuration before treating the deployment as RAG-ready.

Cloud and on-prem AI-enabled profiles should also expose the same vector deployment posture in AI Context. Cloud may use managed configuration and on-prem may use install-local or customer-hosted configuration, but neither deployment mode should claim semantic retrieval readiness when chunk embedding, query embedding, pgvector support where applicable, or a native/approved ranking backend is missing.

Operator view

Open Governance > Operations > Content extraction to review source extraction records across modules. Operators can use this page to identify unsupported sources, stale extraction records, OCR requirements, and AI handoff blockers before a demo, audit, or production workflow depends on extracted content.

The operator overview separates ready, stale, blocked/failed, keyword-indexed, keyword-unavailable, OCR-required, OCR blocked/down, OCR low-confidence, and vector-unavailable counts. Use those counts to decide whether a source needs re-extraction, OCR/provider setup, human validation, or an owning-module access/policy review.

Use Mark stale for reindex when a single source should be refreshed after parser/OCR/provider/profile configuration changes. Use Mark matching stale when a profile or provider change affects a matching set of sources. Both actions record the stale posture first, then the normal extraction request path rebuilds chunks, keyword tokens, preview posture, OCR posture, and AI handoff state under current source-owner access and policy.

The operator page also includes parser, OCR, provider, and source-profile coverage derived from sanitized extraction posture. Coverage rows show profile keys, affected source counts, stale/attention counts, low-confidence OCR counts, unavailable provider posture, source modules, languages, and warning codes. Profile-row stale actions preserve the profile kind, so a parser or OCR profile key does not get treated as a source-profile key. The coverage surface does not expose extracted text, storage keys, provider payloads, OCR output, or parser internals.

Last updated on
Document ManagementTerminology