Bid Database Responsibilities

Why This Exists

This document defines conceptual database responsibilities for the Bid Domain.

It does not define SQL implementation, final schemas, migrations, or storage technology.

Owner

The owner is the Chief Product Officer and Enterprise Architect.

Business Value

Clear persistence responsibilities make bid work auditable, collaborative, trackable, and reusable for learning.

Conceptual Tables Or Collections

Conceptual table or collection	Responsibility
bid_workspaces	Root workspace state and references.
bid_plans	Bid plans, milestones, and planning metadata.
bid_tasks	Assigned tasks and status.
bid_team_members	Workspace team membership.
bid_comments	Internal chat and comments.
proposal_drafts	Draft artefact metadata and versions.
proposal_sections	Proposal section state and content references.
sbd_forms	SBD form state and validation.
pricing_workbooks	Pricing workbook metadata and status.
boq_references	BOQ references and source links.
submission_checklists	Checklist items and readiness state.
approval_workflows	Approval steps, approvers, decisions.
briefing_notes	Briefing notes and source context.
submission_packs	Submission pack metadata and readiness.
electronic_submission_requests	Electronic submission support records.
manual_submission_packs	Manual submission preparation records.
bid_outcomes	Bid result and outcome data.
loss_feedback	Loss feedback records.
lessons_learned	Lessons captured from bid work.
bid_audit_log	Bid changes, approvals, submission, and outcome audit.

Indexing Considerations

Future implementation should consider indexes for WorkspaceId, TenderOpportunityId, OrganizationId, task owner, task status, approval status, submission status, due dates, outcome result, and correlation ID.

Ownership Rule

Bid storage is canonical for bid workspace and preparation state. It must not become the canonical store for tender facts, organization facts, compliance facts, intelligence sessions, or contract obligations.