Application Type

Application Type

Definition

Application-type vocabulary that introduces an application layer above workspaces. Per Q-OQR1-01 + Q-OQR1-03 ratification (S235 14/05/2026), built as Option (c) hybrid with provenance: an application_types DB instance table with rich config columns (label, icon, route, default_template_ids[], state_machine_name, state_machine_config jsonb, default_color, default_icon) plus a provenance enum (core / client / recommended) per row. 6 baseline core rows ship from day 1.

Replaces the current workspaces.type text column (CV 15) post-combined-PR per Q-OQR1-16 — workspaces.application_type_id FK becomes the single discriminator (KISS per Q-OQR1-04).

Synonyms / Acronyms

• procurement (umbrella) = the renamed application_type that subsumes the legacy bid workspace_type. Distinguishes from the inner form_type='bid' discriminator (CV 26) which sits within the procurement workspace (per source §4.5 + Q-OQR1-02).

Baseline values

key	label	provenance
procurement	Procurement / Bid	core
intelligence	Sector Intelligence	core
sales_proposal	Sales Proposal	core
product_guide	Product Guide	core
competitor_research	Competitor Research	core
training_onboarding	Training / Onboarding	core

Relationships

• application_types table (new — Q-OQR1-16 combined PR; not yet in production schema).
• workspaces.application_type_id — planned FK to application_types (replaces workspaces.type per CV 15).
• Adjacent satellite tables per Finding 05 Option B pattern: procurement_workspaces (was bid_workspaces), then sales_proposal_workspaces as that application ships.
• Adjacent to CV 14 BID_STATES — application_types[procurement] binds to the bid workflow state-machine.
• Adjacent to CV 26 form_type — application_type=procurement is the umbrella; form_type discriminates inside it.
• Layer 2: application_type becomes a metadata element on source_documents, q_a_pairs, workspaces, pipeline_runs per Phase 2 step 4.
• Layer 3: hierarchy placement TBD per source §3.3 (sibling vs parent/child of related app types).
• Layer 5: state-machine binding via state_machine_name column.

Consumers

• All workspace surfaces (replaces workspaces.type) — lib/workspace-types.ts, components/workspace/, app/api/workspaces/.
• Future admin UI for client-added application types (v1.1 per Q-OQR1-13).
• State-machine selector (which workflow drives which workspace) — extension of lib/bid/bid-state-machine.ts shape.
• Future source_documents / q_a_pairs / pipeline_runs application_type tags.
• lib/mcp/tools/workspaces.ts — MCP workspace surfaces.

Notes

• Status: needed — table does not yet exist; lands in combined PR Q-OQR1-16.
• 6 core baseline rows are platform-shipped per Q-OQR1-03; clients add new types via admin UI in v1.1 with provenance='client'.
• All 6 ship as core-provenance stubs (state-machine wiring lands per use-case readiness; the application_type row exists from day 1 to make the platform story complete).
• Code-registered types from lib/workspace-types.ts seed the table on first migration; the registry stays as a type-system-level contract but the DB table becomes authoritative for runtime config.
• Q-OQR1-14 ratification: code-driven for v1, data-driven for v2 (state-machine config).
• Per WP-ONTO-R1 §6.2 and §6.3, this is the canonical example of the hybrid+provenance pattern (used as the YAML example in §6.3).
• Verification gate (B1, S236): these are aspirational values — cannot be drift-checked against the live DB because the table does not yet exist. The core_seed_path (scripts/seed/baseline-application-types.sql) commits the WP6 ratifier wave or later session to creating the seed file alongside the schema migration in Q-OQR1-16.