Board Candidate Data Model & Verification Schema (related to #2500)

**Is your feature request related to a problem? Please describe.**
The OWASP Board Candidates Transparency Dashboard currently provides limited insights into candidates’ activity, credentials, and commitments.
Candidate statements are unstructured, verification is inconsistent, and promises or pledges are not easily traceable or immutable.
This makes it difficult for the community to reliably assess candidates, track verified claims, or reduce misinformation.

**Describe the solution you'd like**
I propose a standardized Board Candidate Data Model + Verification Schema to structure candidate claims as atomic, verifiable statements, and support a transparent, multi-party fact-checking workflow.
Key components:
1. Design Principles

Atomic, claim-level data (no large unstructured bios)
Evidence required for verification
Multi-party fact-checking (community + OWASP staff)
Clear distinction between verified and unverified data
Immutability for promises and verified records
Full audit trail (who verified what, when, and how)

2. Core Entities

Candidate, CandidateProfile, CandidateStatement, Evidence, Verification
ActivityMetric, ExternalProfile, CandidatePromise, PreviousElection, AuditLog

3. Candidate Statements

Each claim categorized: activity_metric, credential, certification, leadership_role, committee_role, funding_support, content_creation, community_contribution, historical_participation, commitment_promise
Promises and verified statements immutable
Candidates select limited statements to display as “verified highlights”
Unverified statements clearly marked

4. Evidence & Verification

Evidence via URL or file upload
Verification requires 2–3 community reviewers + 1 OWASP staff final approval
Verification history append-only

5. Additional Features

Activity metrics: PRs, issues, discussions per project
External profile support: ORCID, Google Scholar, YouTube, CSA, LinkedIn
Funding claims, leadership roles, candidate promises, previous elections, audit logs

UI: verified/pending/unverified states visually distinct, badges link to evidence, filters for verified-only data

**Describe alternatives you've considered**

A clear and concise description of any alternative solutions or features you've considered.
Using unstructured free-text bios (current approach) — but verification is inconsistent
Single-staff verification — increases risk of bias and human error
Displaying only verified statements without unverified context — reduces transparency
The proposed model balances transparency, verifiability, and community involvement.

**Are you going to work on implementing this?**

- [ ] Yes
- [x] No

**Additional context**
This proposal is directly related to Issue #2500 (Board Candidates Transparency Dashboard), which is currently limited to collaborators.
Below is the full candidate data model + verification schema draft:

# Candidate
Candidate:
candidate_id: UUID
full_name: string
election_year: integer
profile_slug: string
status: enum [draft, published, archived]
created_at: timestamp
last_updated_at: timestamp

# Candidate Profile
CandidateProfile:
candidate_id: UUID
short_bio: text
affiliation: string
geographic_region: string
consent_given: boolean
privacy_notice_version: string

# Candidate Statements
CandidateStatement:
statement_id: UUID
candidate_id: UUID
category: enum [activity_metric, credential, certification, leadership_role, committee_role, funding_support, content_creation, community_contribution, historical_participation, commitment_promise]
title: string
description: text
is_promise: boolean
immutable: boolean
display_priority: integer
display_as_verified: boolean
created_at: timestamp
last_modified_at: timestamp

# Evidence
Evidence:
evidence_id: UUID
statement_id: UUID
evidence_type: enum [url, file_upload]
reference: string
description: text
uploaded_by: user_id
uploaded_at: timestamp
checksum: string
archived: boolean

# Verification
Verification:
verification_id: UUID
statement_id: UUID
status: enum [unverified, pending, verified, rejected]
confidence_level: enum [low, medium, high]
verifier_id: user_id
verifier_role: enum [community_volunteer, owasp_staff]
verification_notes: text
created_at: timestamp

# Activity Metrics
ActivityMetric:
metric_id: UUID
candidate_id: UUID
platform: enum [github, forum, mailing_list]
metric_type: enum [pr_comments, issue_comments, discussion_posts]
project_scope: string
count: integer
evidence_reference: string
last_synced_at: timestamp

# External Profiles
ExternalProfile:
profile_id: UUID
candidate_id: UUID
platform: enum [orcid, google_scholar, youtube, cloud_security_alliance, linkedin]
profile_url: string
verified: boolean
verification_statement_id: UUID

# Funding & Sponsorship Claims
FundingClaim:
funding_id: UUID
statement_id: UUID
amount_range: enum [over_10k, over_50k, over_100k]
currency: string
beneficiary_project: string
funding_year: integer

# Leadership Roles
LeadershipRole:
role_id: UUID
statement_id: UUID
organization: string
role_title: string
role_type: enum [committee, board, conference, community]
start_date: date
end_date: date | null

# Candidate Promises
CandidatePromise:
promise_id: UUID
candidate_id: UUID
title: string
description: text
immutable: true
created_at: timestamp

# Previous Election Participation
PreviousElection:
record_id: UUID
candidate_id: UUID
election_year: integer
candidate_page_url: string
vote_count: integer
elected: boolean

# Audit Log
AuditLog:
audit_id: UUID
entity_type: string
entity_id: UUID
action: enum [create, verify, reject, archive]
performed_by: user_id
performed_at: timestamp