Forms

A form is a structured data capture template. Forms are how parties tell you about themselves, how members capture information into governed records, how attestations get recorded, how reviews get filled in. Each form is a versioned definition; each submission is a record tied to the form version it was completed against.

Forms are authored, reviewed, published, and retired through the same governance discipline as the rest of the program. A published form version is frozen; revisions create new versions; old submissions remain tied to the version they were completed under.

When you would reach for this

You author a form when:

• A lifecycle transition requires structured data capture.
• A party intake needs documented input.
• A periodic attestation needs auditable completion records.
• A review or assessment needs a structured response shape.
• A regulator requires evidence that questions were answered consistently across time.

You don’t reach for this for free-text email exchanges or informal note-taking. Forms are for structured, repeatable, audit-grade capture.

What lives in a form

Three record types:

Form definition is the named form (“Vendor intake,” “Buyer KYC information,” “Annual vendor refresh”). It carries:

• A name and a stable key.
• A purpose description.
• An owner.
• A pointer to the current published version.

Form version is a specific revision of a definition. It carries the full field schema (the questions, their types, validation, authored content, tables, field references, page breaks), the classification (sensitivity of submissions), any bound logic, and a status (draft, published, retired).

Form submission is one completion of a form. It captures the form version completed against, the responder, the submitted values, the timestamp, and (if relevant) the party or other subject the submission concerns.

Field types and shape

Forms support these structured field types today:

• Text (short and long).
• Number with min/max and unit.
• Date.
• Select (single, multi) with defined options.
• Boolean.
• Identity reference (a structured pointer to a record in the workspace).
• Signature (when configured).
• Stamp placeholders for formal document execution.

Fields can be marked required or optional, can carry supported validation, can be classified (sensitive vs ordinary), and can be linked to downstream targets (a field that auto-fills a party assignment, etc.).

Versioning fidelity

A submission is forever tied to the version of the form it was completed against. An auditor reviewing a submission from last year sees that submission’s responses against the v1 field shape. When v2 was published with a renamed field or a new question, v1 submissions don’t retroactively change — they’re a frozen artifact.

This matters because auditors need to know: “what was asked, and what was answered, at the time.” Without versioning fidelity, form revisions would silently rewrite history.

A worked example: the procurement marketplace’s form library

Felipe’s marketplace authors a library of forms used across the two lifecycles and the periodic refreshes:

• vendor-profile — basic company info, contacts, address, websites.
• vendor-categories — which product categories the vendor supplies, with structured sub-fields per category.
• vendor-financial-disclosure — financial standing self-disclosure with documented uploads.
• vendor-code-of-conduct-acknowledgment — the acknowledgment form for the code of conduct.
• vendor-regulatory-categories — declaration of which regulatory regimes apply.
• vendor-annual-refresh — the annual confirm-or-update form.
• buyer-profile — basic buying organization info.
• buyer-kyc-information — the KYC questionnaire.
• buyer-agreement-acknowledgment — buyer-side agreement acknowledgment.
• enhanced-due-diligence — the form for higher-risk buyer onboarding.

Each form is authored by Felipe’s team, reviewed by the compliance lead, and published. As regulator expectations evolve, certain forms gain new versions (the financial disclosure adds new line items mid-year; the regulatory-categories form gets new categories as new regulators are recognized). Each new version starts at draft, goes through review, and publishes; submissions made before the new version landed remain on the previous one.

Six months in, the form library is the audit-grade record of every question asked of every party.

What you’ll see in the product

Forms lives under Governance → Party → Forms in the workspace.

The Definitions list shows every form with its current published version, owner, and recent submission count.

Inside a definition, you see versions with their status (draft, published, retired), publication timestamps, change summaries.

Inside a version, you see the field schema, the classification, the bound logic.

The Extraction tab prepares the current published version for the shared Content Extraction foundation. It shows whether the structured form content can be extracted for preview, keyword search, and governed AI handoff. Submitted responses can also be prepared through the same backend source-owner seam when an owning workflow requests extraction.

Submissions are visible per-party from the party’s record and per-form from the form’s detail page.

Every change is captured in the workspace Audit Log.

Classification

Forms carry classification on submissions. A vendor-financial-disclosure submission is sensitive; the workspace’s classification levels determine who can view the full content. A vendor-profile submission may be less sensitive.

Classification flows into evidence: a form submission tagged as restricted only counts as evidence to viewers cleared at that level. The form definition declares the default classification for submissions.

Published versions and submitted responses keep a captured classification snapshot. When a public participant opens a form task or when Novantra generates a controlled output, the label and color come from that captured snapshot so later classification edits do not silently rewrite the historical record.

Authored content and public response tasks

Forms can include structured fields, explanatory content blocks, authored tables, fillable tables, field references, and page breaks. The public response surface renders the published version’s authored structure so respondents see the same sections, instructions, table layout, and classification context that the form owner approved.

Signature fields can capture a response-time typed signature for the form response. For formal signing, acknowledgements, attestations, reusable signatures, stamps, reminders, expiry, and external execution providers, use document execution workflows.

Generated outputs

Forms can request generated outputs through the rendition foundation:

• Blank form version output creates a controlled artifact from a published version without response values.
• Form response output creates a controlled artifact from a submitted response with its captured values and response-time signature snapshots.

The generated file is a derived artifact. The form template, published version, response values, and captured snapshots remain the source of truth. The editor preview is only a drafting aid and is not the canonical generated output.

Common workflows

Authoring a form

1. Forms → New definition. Pick name, key, purpose, owner.
2. Create the first draft version: build the field schema.
3. Add supported validation, classification, authored content, tables, and field references.
4. Test by submitting to a test target.
5. Route for review.
6. Publish.
7. Reference from the lifecycle transitions or session templates that need it.

Revising a form

1. From the definition, create a new version draft starting from the current.
2. Add, remove, rename fields. Tighten or loosen validation.
3. Run test submissions.
4. Publish; the previous version is retired (or kept as inactive for historical reference).

Reviewing submissions

1. From the form’s detail page or from a party’s record, view submissions.
2. Each submission shows the version it was completed against, the responder, the values.
3. Use filters by submission date, status, party type.

Related

• Overview - the full party governance story.
• Public Sessions - sessions use forms as tasks.
• Lifecycles - transitions bind to forms.
• Classification - submissions carry classification.
• Evidence - submissions can be evidence claims.