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, conditional logic), 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 a range of field types:

• Text (short and long).
• Number with min/max and unit.
• Date and date-range.
• Select (single, multi) with defined options.
• Boolean.
• File upload (with size and type constraints).
• Address (structured with country, region, line).
• Identity reference (a structured pointer to a record in the workspace).
• Signature (when configured).
• Conditional sections that show/hide based on prior answers.

Fields can be marked required or optional, can carry validation (regex, range, custom rules), 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.

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.

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 validation, conditional logic, classification.
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.