Enterprise Readiness
Enterprise readiness is the product posture a tenant should show before using Novantra for regulated AI-assisted document treatment. It is not a proposal script, certification statement, or customer-specific evidence package.
Use this guide to assemble a reusable readiness package for regulated enterprise, government, healthcare, financial, energy, or internal governance buyers. Scenario documents, proposal scripts, screenshots, and customer-specific mappings should live outside product configuration.
Capability States
Use the same state labels in operator notes, readiness matrices, and buyer evidence:
| State | Use it when |
|---|---|
configured | The capability is implemented and the tenant has the required setup, permissions, providers, and policy. |
unavailable | The capability cannot run for the current source, policy, or deployment, and no fallback should be implied. |
fallback-only | The workflow can continue through an explicit deterministic or non-live path. |
policy-blocked | Tenant policy, source rights, classification, retention, legal hold, or deployment policy blocks use. |
provider-not-configured | The product surface exists, but the external or local provider is not configured. |
not-configured | Optional tenant-owned setup, such as source packs, terminology, or evidence templates, has not been configured. |
no-AI profile | The deployment intentionally excludes optional AI behavior. |
deployment-dependent | Availability depends on cloud, on-prem, air-gapped, customer-managed, provider, or operating evidence. |
evidence-required | The product may support the topic, but the claim needs operational proof before it is represented as available. |
roadmap | The capability is intentionally deferred to a future generic product owner. |
not-applicable | The source owner has no stable truth or workflow semantics for the requested projection. |
reference-only | The current path may point to an external or future owner, but it must not store mutable truth or imply configuration. |
Buyer Evidence Matrix
| Buyer requirement | Novantra evidence to show | State discipline |
|---|---|---|
| Governed AI use | AI system, profile, provider, action policy, use authorization, run, suggestion, and reviewer evidence. | configured, provider-not-configured, fallback-only, or no-AI profile. |
| Controlled document source | DMS document/version context, classification/security posture, extraction readiness, and source refs. | configured, policy-blocked, or not-applicable where a source lacks stable truth. |
| Source-grounded suggestions | Selected source packs, language scope, retrieval/source coverage, citations, confidence, and warning keys. | configured, not-configured, fallback-only, or evidence-required. |
| Source graph and citations | Graph scopes, graph versions, reviewed relationships, citation anchors, source refs, and limitation snapshots. | configured, not-configured, reference-only, policy-blocked, or roadmap depending on source readiness. |
| OCR and scanned records | OCR/extraction posture, engine evidence where configured, page/anchor evidence where policy permits, and low-confidence warnings. | configured, provider-not-configured, fallback-only, or deployment-dependent. |
| Human review | Review decisions, manual attestation, formal review requests where used, reasons, and application status. | configured or policy-blocked; do not imply AI auto-approval. |
| Owning-module application | Metadata updates or target-applier records in DMS, change management, findings, risks, controls, obligations, evidence, privacy, retention, or document governance. | configured only for implemented target appliers; otherwise not-applicable or roadmap. |
| Audit package readiness | Run evidence, source refs, profile/policy refs, review decisions, redaction posture, hashes, artifact refs, and descriptor-backed package fields for the document treatment path. | Use descriptor-backed evidence where the selected package supports it; broader package coverage remains roadmap or evidence-required. |
| Follow-up work | Work-management projections from source owners that expose stable due, review, expiry, or action-required semantics. | configured, not-applicable, or roadmap; do not create local task truth. |
| Compliance posture | Sanitized posture signals from source owners for AI quality, document readiness, review status, follow-up, and terminology where configured. | configured, not-configured, reference-only, not-applicable, or roadmap. |
| Terminology and bilingual review | Tenant-owned terminology sets, versions, entries, import lineage, and safe terminology refs for governed consumers. | configured when tenant terminology is active; otherwise not-configured, reference-only, or unavailable. |
| Public integrations | Implemented public service-account, OpenAPI, webhook, idempotency, and rate-limit evidence. | Public Document Intelligence APIs remain roadmap unless separately implemented. |
| Deployment and operations | Cloud/on-prem/no-AI deployment notes, provider setup, backup/DR, support, logging, credential, and release-gate evidence. | deployment-dependent or evidence-required unless backed by current operational evidence. |
Operator Checklist
Before presenting or accepting an enterprise AI document governance path, confirm:
- The document is opened from a controlled DMS source or another approved source path with safe source context.
- Content extraction, preview, search, OCR, retrieval, provider, and source-pack readiness are visible before the run.
- The selected AI profile declares source packs, supported languages, evaluation posture, privacy/redaction/export-control warnings, and manual-attestation policy where needed.
- The selected user has a valid use authorization and action policy for the workflow.
- The run records selected source packs, selected language keys, citations, confidence, quality warnings, and provider/fallback mode.
- Material suggestions are reviewed or formally routed before application.
- Applied outcomes go through the owning module, not through an AI-local truth store.
- Audit evidence can show source refs, run/profile/policy refs, reviewer decisions, application refs, redaction posture, hashes, and artifact refs.
- Work-management and posture evidence use source-owner descriptors where implemented, or explicit
not-applicableandroadmapstates. - Public API, certification, SLA, residency, accuracy, legal-validity, confidential vector search, regulator-delivery, and eDiscovery/redaction-release claims are marked with the correct state.
Provider And OCR Setup
Document Intelligence can be shown through a configured provider, a local/fallback path, or an unavailable/no-AI posture. The evidence must name the actual mode used.
- Use
configuredonly when the tenant has the provider, credential, policy, permissions, and deployment support needed for the run. - Use
provider-not-configuredwhen the AI/OCR surface exists but the tenant has not connected the provider. - Use
fallback-onlywhen the run used deterministic or non-live continuity behavior. - Use
no-AI profilewhen the deployment intentionally excludes optional AI behavior. - Use
deployment-dependentfor cloud, on-prem, air-gapped, customer-managed provider, BYOK, BYO storage, backup, DR, logging, or support topics that depend on the deployed environment.
Audit Package Setup
For current runs, use the implemented AI run evidence and Document Intelligence readiness checklist to prove what happened. For formal audit packages, use descriptor-backed export fields and generation artifacts where the selected package supports them.
Do not assemble an evidence package from raw prompts, provider responses, document body text, extracted values, storage keys, vectors, internal route names, repository names, database names, or implementation-only payloads.
Document-treatment audit descriptors cover the governed treatment chain across AI/Document Intelligence, DMS source context, review decisions, change applications, governed target records, privacy, retention, and terminology refs. Label broader package coverage as roadmap or evidence-required rather than filling the gap with local exports.
Terminology Posture
Terminology is tenant-owned truth. Before terminology is configured, readiness evidence may show selected language keys, glossary declarations, or source-pack references as not-configured or reference-only.
Do not store mutable glossary truth inside AI snapshots, DMS metadata, catalog rows, or scenario files. Once tenant terminology is configured, governed consumers should reference stable terminology set, version, entry, and import evidence without copying sensitive term content unnecessarily.