Skip to content
Canonical

Entity Glossary — canonical core-entity definitions

Entity Glossary

Section titled “Entity Glossary”

Split out of platform-direction.md S504 (ruling R6) — this half was the load-bearing content specs and tasks actually cite. Definitions are canonical and verified against the schema + ontology (lineage: S391 original glossary, S462 DR-038 revision, 27/07/2026 post-ID-145-W1 cutover fold). Reuse them verbatim wherever an entity-definition block is needed.

  • application / application_type = a use-case CLASS, realised as the reference TABLE application_types (6 keys: procurement, intelligence, sales_proposal, product_guide, competitor_research, training_onboarding). NOT a container; there is NO applications table. It REPLACED the legacy workspaces.type enum via workspaces.application_type_id FK (T2 migration, S246/S247). It is the layer ABOVE workspace. (“application was the missing abstraction.”)
  • workspace = LEGACY tier (DR-038, S452) — removed from the containment chain. “Workspace” was the wrong abstraction for scoping application-type data: each activity carries its own id (form id, proposal id, guide id, …) and structured data scopes to the ACTIVITY. The workspaces table still exists as legacy infrastructure (a back-pointer during migration only); no new *_workspaces tables are ever minted, and the procurement workspace-keyed surfaces (procurement_workspaces, procurement_vehicles/procurement_vehicle_instances, form_questions.workspace_id) were dropped in ID-145 W1 (migrations 20260712062000_id145_w1c_rename_reshape.sql + 20260712064000_id145_w1e_drop_workspace_stratum.sql, merged to main in canonical PR #119). workspace was never a synonym for client/tenant.
  • form = a submission/questionnaire instance (form_instances row of a form_type: psq/itt/tender/rfp/questionnaire/checklist/sales_proposal_template) — the procurement ITEM itself (owner ruling 2026-07-11 + DR-038): the activity carrying its own per-form workflow_state, outcome (+audit triad), deadline, submission_date, issuing_organisation (id-130 machinery). “bid” is NOT a form_type — the row was deleted by 20260712065000_id145_bi8_retire_bid_creation_label.sql and the live form_types keys are checklist/itt/psq/questionnaire/rfp/sales_proposal_template/tender. It survives only as a legacy word for the procurement activity. Post-ID-145-W1 schema: the instance table is form_instances (renamed from form_templates); form_questions is scoped by form_instance_id (NOT NULL, FK CASCADE) — the legacy workspace_id column is dropped; the reusable template table is form_requirement_templates (renamed from form_template_requirements); form_template_fields is renamed to form_instance_fields. (form_questions.status defaults to 'pending'; consumers render a safe fallback for any value outside the typed union.)
  • q_a_pair = the corpus-level reusable knowledge unit; NOT activity-partitioned. source_form_response_id / source_question_id / source_form_instance_id are NULLABLE provenance/lineage only (the legacy source_workspace_id column was dropped in ID-145 W1). Relevance is computed at query time via scope_tag overlap, not a scoping FK. It is ONE CLIENT’s corpus, shared across that client’s applications/activities/AI tooling.
  • reference_item = EVIDENCE, not a record (DR-132). An external reference — citable and attributable, never authoritative on its own. Two consequences that were re-derived by two independent lanes before being written down here. (1) No knowledge-admission gate. corpus-reframe-review.html R2’s sign-off gate governs records, the things that carry authority; a reference item has no publication_status and no promotion step, and superseded_by is the whole of its lifecycle. That is correct, not incomplete — nothing is missing from the table. DR-125 binds scope_tag to promotion, so a reference item has nothing to attach one to either. (2) Not a form-matching corpus. Form matching draws on q_a_pairs only; question_match_recompute being q_a_pair-only is correct, and search_for_form_response searching both was the defect. specs/id-131-.../PRODUCT.md §I BI-29’s “reference_items (optional)” clause is disowned by the owner (S538) — do not re-derive the arm from it. Reference items and source_documents remain separate first-class entities discriminated by lifecycle, walked vs not (DR-124).
  • tenant = the client’s DATABASE itself. Deployment is one Supabase project per client, and the database is the only cross-tenant boundary — there is no tenant_id column anywhere. A workspace was never the tenant: legacy “cross-workspace” prose means across ONE client’s workspaces (intra-tenant), never across clients. (Re-homed from the retired CV 15-workspaces-type per the id-417 B3 ruling.)
  • subject taxonomy (domains/subtopics) = display-level, derived metadata — never a driver (DR-130). Nothing in the platform is driven by a platform-global subject vocabulary. The driving axes are: scope (scope_tag — the only filter-shaped mechanism retrieval needs, DR-125), semantics (embeddings + keywords + entity extraction; aboutness at query time is ranking, never an exclusion predicate), and concept membership (bundle topics + guides as curated clusters, DR-126). The IMS-era platform-global 7×34 taxonomy_domains/taxonomy_subtopics vocabulary is retired; if a client ever needs a subject vocabulary (badges, guide-membership display), it returns as an R6 client-overlay CV in the client bundle — curated, display-only, never NOT NULL, never minting identity, never a pipeline gate.

Containment: tenant (one DB per client) ⊃ applications per client (application_type) ⊃ ACTIVITIES (form / proposal / guide — each carrying its own id, per DR-038) ⊃ their child records (form_responses under a form, …); q_a_pairs are corpus-level (one client’s shared corpus), not activity-partitioned. The former workspace tier is retired from this chain.