Skip to Content
Welcome to the Novantra documentation.
GuidesGovernanceModulesCatalog Adoption

Catalog Adoption

Catalog Adoption is the workspace surface for bringing trusted package releases into your organization without making the upstream catalog your runtime truth.

Use it when a reviewed package contains frameworks, source objects, templates, mappings, evidence requirements, terminology, benchmark fixtures, or other governance components that your organization wants to review and adopt locally.

What Catalog Adoption Owns

  • Local package release cache records.
  • Import receipts and version-check snapshots.
  • Adoption workspaces for reviewing a package release.
  • Component decisions such as accept, merge, reject, defer, supersede, or detach.
  • Handler dispatch into the module that owns the target record.

Supported handlers can materialize owner records. For example, Regulatory Register can adopt reviewed catalog register profiles and source sets into local profile/source-set records, Forms can adopt reviewed catalog form templates into local draft template versions, Document Management can adopt reviewed catalog document templates into editable local draft document versions, and Governed Lifecycle can adopt reviewed lifecycle templates into local draft lifecycle versions. Catalog Adoption keeps the package decision and lineage evidence; the owner module keeps the operational record and its normal publish, review, approval, or activation rules.

Catalog Adoption does not own frameworks, documents, forms, evidence, regulatory-register records, source graph records, AI context, vectors, work items, posture scores, or audit exports. Those remain with their source-owner modules.

User Journey

  1. Open Governance > Catalog Adoption.
  2. Import a signed package bundle or inspect a locally cached package release.
  3. Review the package trust, rights, signature, source, and compatibility posture.
  4. Open an adoption workspace for the package release.
  5. Review each component decision and the target owner module.
  6. Apply accepted decisions through the owner module handler.
  7. Use lineage, trace, work-management, posture, and audit-package surfaces to show what was adopted and why.

Source Owner Rule

Catalog packages are distribution truth. After adoption, operational truth stays local:

  • Framework nodes belong to Frameworks.
  • Documents and controlled versions belong to Document Management and Document Governance.
  • Forms belong to Forms.
  • Lifecycle definitions, draft versions, activation, and runtime instances belong to Governed Lifecycle.
  • Evidence requirements and claims belong to Evidence.
  • Source records belong to Sources.
  • Regulatory profiles belong to Regulatory Register.
  • AI indexing and vectorization, when allowed, belong to AI context and retrieval owners, not Catalog Adoption.

AI Use And Rights

A package may describe AI-use rights, but rights do not automatically make a document or package component available to AI. AI preparation still depends on source-owner access, classification, retention, legal hold, tenant AI policy, deployment provider policy, and no-AI profile posture.

When a package is restricted to metadata-only use, Catalog Adoption can preserve the package lineage while preventing protected source text from being used for retrieval, vectorization, or benchmark fixtures.

Cloud And On-Prem

Cloud and on-prem use the same local adoption model. Cloud cells and on-prem installations may receive signed package releases through different operational channels, but normal workspace use reads the local cache and local adopted records. That cache is workspace-local in both deployment modes, so each organization reviews and adopts packages into its own runtime truth.

Last updated on
OverviewFrameworks