Opportunity Database Responsibilities

Why This Exists

This document defines conceptual database responsibilities for the Opportunity 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 tender discovery, indexing, matching, recommendations, saved opportunities, and watchlists auditable and searchable.

Conceptual Tables Or Collections

Conceptual table or collection	Responsibility
tender_sources	Tender source configuration and reliability metadata.
tender_opportunities	Core tender records and lifecycle state.
tender_documents	Tender document metadata and storage references.
tender_requirements	Captured tender requirements.
tender_briefing_sessions	Briefing dates, requirements, and attendance context.
tender_deadlines	Submission, briefing, clarification, and other deadlines.
tender_indexes	Structured searchable tender fields.
opportunity_matches	Organization-to-tender match records.
qualification_assessments	Eligibility, fit, effort, readiness, and risk assessments.
recommendation_records	Bid/no-bid recommendations and win probability estimates.
saved_opportunities	Customer-saved tender pipeline entries.
watchlists	Customer watchlist criteria and state.
tender_risk_assessments	Tender risk records and causes.
opportunity_audit_log	Opportunity changes and recommendation audit history.

Indexing Considerations

Future implementation should consider indexes for:

• TenderOpportunityId.
• SourceId.
• Buyer name.
• Tender reference number.
• Tender category.
• Region.
• Closing date.
• Briefing date.
• OrganizationId for matches, watchlists, and saved tenders.
• Match score.
• Recommendation decision.
• Risk level.

Ownership Rule

Opportunity storage is canonical for Opportunity-owned records. It must not become the canonical store for Organization profile facts, Compliance state, or Proposal content.