Release 1B: build the public claims evidence register and remediation plan

[support371]

Objective

Create a source-grounded inventory of every material public claim across GEM Enterprise and prepare an evidence-backed remediation plan before promotional video production or broader public campaigns.

This issue begins as a read-only audit. Code changes must use a separate focused branch after PR #182 is merged or the branch dependency is explicitly approved.

Priority routes

• /
• /community
• /community-hub and all nested preview routes
• /hub
• /services and /services/[slug]
• /company
• /about
• /personnel
• /request-access
• /get-started
• /store, /store/main, and /store/[slug]
• /trust-center
• /compliance-notice
• /resources
• /intel

Claims to inventory

At minimum:

• Executive and personnel identities
• Employment histories
• Academic and professional credentials
• Team and staffing counts
• SOC locations, regional hubs, and 24/7 coverage
• Response times and SLA statements
• Six-minute MTTA or similar performance metrics
• Automatic playbook execution
• Live monitoring, intelligence feeds, dark-web monitoring, deed monitoring, and real-time alerts
• Encryption and secure-messaging claims
• KYC/KYB and verification-status claims
• Compliance, certification, audit-readiness, legal, regulatory, and framework statements
• Association, partner, institutional, trustee, government, or provider relationships
• Product availability, pricing, licensing, fulfillment, recovery, protection, and insurance-like statements
• Community membership, partner-firm, mandate, opportunity, event, or transaction counts
• Customer-support hours and acknowledgement targets

Required record for every claim

• Exact wording
• Route and section
• Source file
• Component or data source
• Current production visibility
• Classification: production, conditional, target, planned, demonstration, mock, historical, provider-dependent, or unsupported
• Evidence reference
• Evidence status: verified, conditional, missing, expired, rejected, or confidential
• Risk level
• Approved public wording
• Required disclosure
• Responsible owner
• Reviewer
• Review deadline
• Search-indexing impact

Immediate safeguards

• Do not delete legitimate identity or operating information without evidence review.
• Do not represent synthetic or sample records as real.
• Do not publish a new claim merely because it appears in existing code.
• Do not activate providers or operational features.
• Do not alter Prisma schema until PR Plan command-center Prisma operating-model promotion #173 and existing models are reviewed.
• Preserve controlled-production and request-only disclosures.

Deliverables

1. docs/PUBLIC_CLAIMS_INVENTORY.md
2. docs/PUBLIC_CLAIMS_REMEDIATION_PLAN.md
3. Route-to-source-file claims matrix
4. Prioritized P0/P1/P2 remediation queue
5. Exact replacement wording for unsupported or conditional claims
6. Tests preventing removed high-risk wording from reappearing
7. Search indexing and recrawl plan
8. Proposed data model only after review of PR Plan command-center Prisma operating-model promotion #173 and existing Prisma foundations

Acceptance criteria

• Every priority route has been inspected in production and source.
• Every material identity, staffing, availability, performance, security, compliance, affiliation, and commercial claim has a record.
• Mock and demonstration claims are clearly separated from production facts.
• P0 public exposures have replacement wording and an implementation path.
• No claim is marked verified without an evidence reference.
• The audit report identifies facts that require owner confirmation instead of guessing.
• Any remediation PR passes the canonical Vercel verification gate before review.

Dependency

PR #182 must receive explicit owner approval before merge. Any code branch for this issue should be created from the updated main after that merge, unless a stacked branch is deliberately approved.

[onspotrepair4u-lgtm]

A public-claims register with evidence status is the difference between a trust page that survives review and one that creates new questionnaire findings.

The row model I'd use: claim → deployment model it applies to → evidence ref → status (verified/conditional/missing) → approved wording. Anything without an evidence reference stays "conditional" or unpublished — never "verified". That same register becomes the source for security-questionnaire boilerplate so sales and eng stop inventing divergent encryption/compliance lines.