Form Type

Form Type

Definition

Vocabulary for the type of a form template within KH. Procurement forms (RFP, PSQ, ITT, tender) are CORE for the procurement application; non-procurement forms (checklist, questionnaire, sales_proposal_template) are CORE for their respective applications; clients may add custom forms (questionnaire-X) as client provenance per §6.2. Note: framework / DPS / G-Cloud are no longer form_types — they now live in the sibling CVs procurement_vehicle (30) and procurement_vehicle_instance (31) following the 3-tier taxonomy split (see below).

Per Q-OQR1-02 + Q-OQR1-16 (S235 ratification 14/05/2026): application_type='procurement' is the umbrella; form_type discriminates the four procurement form_types rfp / psq / itt / tender within it. (Originally five: bid was reclassified to itt and deleted from the table by 20260712065000_id145_bi8_retire_bid_creation_label.sql under a guarded DELETE that fired only once zero rows referenced it.) (The pqq→psq key rename per ID-130 AD-4 is recorded in Notes.)

Synonyms / Acronyms

• RFP = Request For Proposal
• PSQ = Selection Questionnaire (the supplier-selection stage under the Procurement Act 2023; the stored form_type key)
• PQQ = Pre-Qualification Questionnaire (legacy pre-2023 term, superseded by the psq key per ID-130 AD-4; retained as an alias)
• ITT = Invitation To Tender
• DPS = Dynamic Purchasing System
• SSQ = Standard Selection Questionnaire (often a sub-shape of PQQ)
• G-Cloud = UK Government Cloud framework

These acronyms should be authored as entity_aliases (CV 18) entries per source §6 Phase 1 step 6.

Baseline values

key	label	provenance
rfp	RFP (Request For Proposal)	core
psq	Selection Questionnaire (SQ/PSQ)	core
itt	ITT (Invitation To Tender)	core
tender	Tender	core
checklist	Checklist	core
questionnaire	Questionnaire	core
sales_proposal_template	Sales Proposal Template	core

(List drawn from source §2.1 + §4.5 + §6 Phase 1 step 3. Verifier sub-agent should confirm or refine.)

Relationships

• form_types table (live in production schema — supabase/types/database.types.ts:1788). new — to be added in Phase 1 step 3; not yet in production schema — struck S275 per ID-52.5: T2 combined-PR migration shipped the table.
• form_templates.form_type_id — planned FK to form_types.
• applicable_application_types text[] column on form_types (e.g. {procurement} for rfp/psq/itt).
• Adjacent live table: form_template_requirements.template_type (renamed from template_requirements) FK → form_types.key (see supabase/types/database.types.ts:1714). template_requirements.template_type CHECK has 10-value vocabulary today (sq, rfp, eqq, pqq, gcloud, method_statement, dos, dps, framework, other); planned form_type is structurally different scope and supersedes/coexists — struck S275 per ID-52.5: T2 combined-PR migration renamed the table and replaced the CHECK with an FK to form_types.key.
• Adjacent to CV 12 requirement_type — a form_template’s form_type constrains which requirement_types are typically used.
• Adjacent to CV 25 application_type — application_type=procurement is umbrella; form_type discriminates inside.
• Layer 5: drives form_template_fields, question_matches.question_kind discriminator.
• Layer 3 hierarchy: RFP / PSQ / ITT / tender all under “procurement_forms”; checklist / questionnaire under “compliance_forms” per Phase 3 step 3.

Consumers

• Form-extraction pipeline (cataloguer reads form_type → drives question-extraction policy per source §4.5).
• Form templates admin / catalogue UI surface.
• question_matches.question_kind discriminator (Theme A — OQ-Q113-C).
• State-machine sub-state semantics per form_type (Q-OQR1-15) — terminal states like won carry per-form-type sub-state via application_types.state_machine_config JSONB.
• lib/templates/template-coverage.ts — coverage computation by form_type.
• lib/mcp/formatters/templates.ts — MCP template surfaces.

Notes

• Status: needed — table does not yet exist. — struck S275 per ID-52.5: form_types table is live at supabase/types/database.types.ts:1788 (T2 combined-PR migration shipped the table).
• Same form_type may exist in multiple form_format values (XLSX SSQ + PDF SSQ + DOCX SSQ all map to form_type=SSQ per source §4.5).
• HYBRID per §6.2 — procurement forms CORE; clients may add custom forms.
• pqq → psq rename (ID-130 AD-4, confirmed S420). The supplier-selection form_type key was renamed pqq→psq (label "Selection Questionnaire (SQ/PSQ)") to align with Procurement Act 2023 supplier-selection terminology (the PSQ stage in restricted/CFP procedures; “SQ” is the umbrella term). DB rename shipped in supabase/migrations/20260625120000_id130_spine.sql STEP 6; the form_outcome_types shortlist set references psq. This ontology baseline was updated to match (closing the MD↔DB drift that AD-4 left open by not updating the canonical CV in lockstep). PQQ (Pre-Qualification Questionnaire) is retained as a documented legacy alias — see Synonyms.
• bid_questions and bid_responses retain their names for now (per Q-OQR1-02) — the form_type discriminator on question_matches distinguishes within the procurement workspace.
• Adjacent live table: form_template_requirements.template_type (renamed from template_requirements) FK → form_types.key (see supabase/types/database.types.ts:1714). template_requirements.template_type CHECK has a 10-value vocabulary today (sq, rfp, eqq, pqq, gcloud, method_statement, dos, dps, framework, other); only sq (66 rows) and rfp (30 rows) are observed in prod. The planned form_type vocabulary is a structurally different scope and supersedes or coexists with template_type — struck S275 per ID-52.5: T2 combined-PR migration shipped the rename + FK; the 10-value CHECK is superseded.

Planned 3-tier taxonomy split (RATIFIED-S243 Item 19)

Status: Planned for T2 combined-PR migration. Current baseline_values above mix three semantic levels — to be split into three CVs:

Layer	CV	Values	Purpose
1	form_type (this CV — trimmed)	rfp, psq, itt, tender, checklist, questionnaire, sales_proposal_template	True form types (a document filled in by a respondent)
2	procurement_vehicle (NEW CV — 30-procurement-vehicle.md)	framework, dps, dynamic_procurement	Procurement vehicle types (long-term agreements / mechanisms)
3	procurement_vehicle_instance (NEW table or CV — 31-procurement-vehicle-instance.md)	g_cloud, etc.	Specific named instances of a vehicle (G-Cloud is an instance of framework)

Rationale: Liam-surfaced inconsistency (Item 19 of pre-s244-project-feedback.md) — G-Cloud is a framework instance, not a form type. framework + dps are procurement vehicles, not forms. The conflation was inherited from live template_requirements.template_type 10-value CHECK; T2 migration cleans it up structurally.

Migration plan (T2 sub-task 9 per PLAN.md §4.2):

1. Trim this CV’s baseline_values to the 8 true form types only.
2. Create 30-procurement-vehicle.md (CV) + procurement_vehicles table with framework, dps, dynamic_procurement.
3. Create 31-procurement-vehicle-instance.md + procurement_vehicle_instances table with g_cloud (FK to procurement_vehicles.framework).
4. Migrate live template_requirements.template_type CHECK to new structure: move gcloud to procurement_vehicle_instance, framework + dps to procurement_vehicle. Retain sq / eqq / method_statement / dos / other mapping to form_type via crosswalk migration.
5. procurement_workspaces satellite gets procurement_vehicle_id + procurement_vehicle_instance_id FKs.