Skip to Content
Welcome to the Novantra documentation.
GuidesGovernanceParty GovernanceLifecycles

Lifecycles

Governed lifecycles coordinate repeatable journeys for a subject, such as a Party, without moving ownership away from the modules that own the actual records.

In Party governance, a lifecycle is not a local workspace-access state machine. Membership remains the owner for workspace access activation, suspension, revocation, roles, sessions, and permission-version invalidation. A Party lifecycle coordinates evidence collection, public sessions, forms, reviews, eligibility checks, metadata or Party-core mapping, and owner-managed access actioners through registered module seams.

What lives in a lifecycle

A lifecycle has four main parts:

  • Definition: the tenant-managed lifecycle identity, subject scope, purpose, name, status, and system lineage.
  • Version: the published or draft runtime shape. A version captures applicability, runtime policy, data handling, and whether parallel instances are allowed.
  • Steps: ordered work items for the version. Each step names an actioner kind and stores only configuration snapshots needed by that actioner.
  • Instances: one subject’s actual run through a version, including step statuses, sanitized runtime refs, linked public-session refs, form-response refs, AI run refs, and review refs.

Published versions remain referenceable after later revisions. Existing instances continue to point at the version they started from.

Authoring lifecycle versions

The Lifecycles console includes a Builder tab for authoring definitions and versions without leaving the governed workspace. The builder uses the same editor-shell pattern as other Novantra authoring surfaces:

  • select or create a lifecycle definition;
  • choose registered actioners from the palette;
  • arrange steps on the canvas;
  • configure the selected version or step in the inspector;
  • review readiness warnings and blockers before saving or publishing;
  • record a governed reason when creating definitions, saving drafts, or publishing versions.

The actioner palette is deployment-aware. It lists actioners registered by the included modules, so lifecycle authoring stays subject-agnostic. The lifecycle definition/version model is not Party-specific: it works through the registered actioner seams rather than Party-specific workflow code, so any governed subject whose module registers actioners uses the same builder and model.

Actioners and ownership

Lifecycle steps execute registered actioners. Each actioner belongs to the module that owns the affected runtime truth.

Examples:

  • public-sessions owns public-session creation and completion waiting.
  • forms owns accepted form-response mapping into approved consumer commands.
  • party owns Party-core mapping actioners that call Party commands.
  • metadata owns derived metadata value application.
  • governed-eligibility owns eligibility evaluation.
  • membership owns workspace-access actioners, such as suspend and revoke, through membership commands.

The lifecycle engine executes the registered actioner. It does not write the other module’s tables directly.

Start readiness

Before starting a lifecycle, Novantra can preview whether a version is ready for the selected subject. The start-readiness check verifies:

  • the lifecycle version exists and is published;
  • the definition exists, is active, and matches the subject module/type;
  • the parallel-instance policy does not block the start;
  • the version has configured steps;
  • every step’s actioner is registered in the deployment;
  • actioner-owned prerequisites are configured, such as active public-session templates with published versions and tasks.

The readiness result uses capability states such as ready, warning, and blocked. A warning means the operator can inspect the issue before runtime; a blocked result means the selected lifecycle should not be started until the configuration is corrected.

What users see

Party records show a lifecycle panel scoped to the Party subject. The panel includes:

  • a subject dossier generated by the governed-lifecycle module;
  • active policy, open instance, completed instance, failed instance, linked evidence, blocker, and latest-activity counts;
  • the instance list;
  • a lifecycle detail view with step posture and linked evidence counts.

The subject dossier is reusable beyond Party. It reads lifecycle definitions, instances, step posture, and sanitized linked refs from governed-lifecycle source truth, then presents that posture to the subject owner. It does not create a Party-local lifecycle ledger.

The detail view summarizes open, completed, and failed steps, plus sanitized counts for public sessions, form responses, AI run refs, and review refs. It does not expose raw prompts, raw model output, raw document text, embeddings, vectors, provider payloads, storage paths, or secrets.

Evidence, work, and audit exports

Governed lifecycle contributes source-owned descriptors for:

  • lifecycle instance status;
  • subject refs and version refs;
  • step status summaries;
  • linked evidence refs;
  • start-readiness posture;
  • follow-up work for waiting or failed lifecycle steps.

Work management, compliance posture, and audit packages consume those descriptors through their own subscriber paths. The lifecycle module does not become a local task engine, posture scorer, or audit export engine.

Waiting and failed lifecycle steps are also projected into Work Management by the governed-lifecycle follow-up runner. The runner reads lifecycle source truth, extracts only policy milestone dates such as due, reminder, warning, grace, escalation, and expiry timestamps from sanitized runtime snapshots, and refreshes central work-item and calendar projections. Reminder delivery, mailing, task lifecycle, and assignee handling remain with Work Management and the deployment notification/mailer seams; lifecycle does not call providers directly or store a separate reminder queue.

Cloud and on-prem

The same lifecycle contracts, routes, UI surfaces, actioner registry, and readiness behavior are available in cloud and on-prem deployments. Provider or capability differences are represented through actioner readiness and deployment capability state, not through different product behavior.

Last updated on
Party TypesEligibility