Data Handling Policy

Product Nerve AI Operated by Product Nerve AI Limited, a company incorporated under the laws of the Federal Republic of Nigeria, with its principal business location in Lagos, Nigeria, trading as Product Nerve AI and Product Nerve ("Product Nerve", "PNAI", "we", "us", "our") Effective date: 24 August 2026 · Last updated: 24 August 2026 Contact: [privacy@productnerve.com]

1. Why this document exists

Founders put their most sensitive material into Product Nerve AI: identity documents, unlaunched ideas, financials, cap tables, and investor materials. This policy states, in operational detail, how each category of data is stored, processed, protected, retained, and deleted. It supplements the Privacy Policy: that document explains your rights, this one explains our handling. Where they overlap, both apply.

2. Data categories and how each is handled

Category 1 — Identity documents (highest sensitivity)

What: government issued ID and passport images and data submitted for KYC; business registration documents submitted for KYB.

Handling rules, absolute:

1. Stored in a dedicated, access restricted storage bucket, physically and logically separate from all other platform data.
2. Never processed by any AI model, never included in any AI context, never indexed into any project knowledge base, under any circumstance or instruction.
3. KYC documents flow to our verification provider (Didit) for automated verification; KYB documents are reviewed manually by authorized staff through the admin system.
4. Access is limited to named staff roles with verification duties, protected by multi factor authentication, and every single access is written to an append only audit log.
5. Served only through signed links that expire within minutes.
6. Retained only as long as verification integrity and fraud prevention require, then deleted (retention table, section 5).

Category 2 — Venture content

What: project descriptions, validation answers, knowledge base uploads and links, generated reports and documents, tasks, decisions, comments.

Handling: stored in our database (Supabase) and file storage (Cloudflare R2 general bucket), encrypted at rest and in transit. Isolated per workspace by database level row security, meaning accounts outside your workspace cannot read your rows even in the event of an application logic error, and additionally isolated per project inside the AI pipeline: content from one project is never used as context for another. Relevant excerpts are sent to AI providers only to generate the outputs you request. Access by our staff is restricted to support roles, is read only, and is audit logged, including a visible banner and full session log whenever staff view an account for support.

Category 3 — Account and billing data

What: names, emails, hashed passwords, subscription state, invoices, payment provider references.

Handling: passwords exist only as secure hashes generated by our authentication provider; we cannot read them. Card numbers never touch our systems: Paystack, Paddle, and the app stores (via RevenueCat) hold them as PCI DSS responsible processors. We hold what we need to manage your plan and issue invoices. All billing state changes are recorded in the append only audit log.

Category 4 — Usage, technical, and communications data

What: analytics events, device data, IP addresses, error reports, support tickets, email logs.

Handling: analytics inside the product runs on PostHog configured without cross site tracking; marketing tags exist only on public pages under consent per the Cookie Policy. Error reports (Sentry) are scrubbed of secrets and never include identity documents. Logs never contain passwords, tokens, card data, or identity document contents, and rotate on short schedules.

3. The AI boundary, precisely

When you run validation or a studio tool, the system assembles context from exactly these sources: your validated summary, your project's knowledge base, prior documents in the same project, and your direct input. That context is sent to the assigned AI provider (Anthropic or Google AI) to produce your output. Contractual position with each provider: content is processed to provide the service and is not used to train their models. What is never sent: identity documents, payment data, other projects' content, other customers' content. Every generated document records which sources influenced it, and you can see that attribution in the product.

4. Where data lives and how it moves

| Data | Primary systems | Regions | Transfer safeguard | |---|---|---|---| | Database records | Supabase (Postgres) | European Union | SCCs / provider DPA | | Files (venture) | Cloudflare R2, general bucket | European Union | SCCs / provider DPA | | Files (identity) | Cloudflare R2, restricted bucket | European Union | SCCs / provider DPA | | Backend processing | Render | European Union | SCCs / provider DPA | | Web delivery | Vercel, Cloudflare edge | Global edge | SCCs / provider DPA | | AI processing | Anthropic, Google AI | US and provider regions | SCCs / provider DPA | | KYC verification | Didit | European Union | SCCs / provider DPA | | Payments | Paystack (NG), Paddle (UK/EU), RevenueCat (US) | Provider regions | Provider DPAs, PCI DSS | | Email | Resend | US | SCCs / provider DPA | | Analytics | PostHog | European Union, as supported by the provider | SCCs / provider DPA | | Errors | Sentry | US | SCCs / provider DPA | | Cache and rate limiting | Upstash | European Union | SCCs / provider DPA |

Product Nerve AI has adopted an EU-first data infrastructure for its initial operations, per the table above. We operate globally from Nigeria; transfers out of the EU, UK, and Nigeria rely on Standard Contractual Clauses or equivalent mechanisms in each provider's data processing agreement, and international transfers outside the EU happen only where required for service delivery and subject to those safeguards. [Counsel: verify each provider DPA is executed and the SCC module inventory is complete before launch; revisit at Delaware incorporation.]

5. Retention schedule

| Data | Retention | Then | |---|---|---| | Account and venture content | Life of account | 30 day soft delete recovery window, then purge from live systems, backups expire within 35 further days | | Identity documents (KYC/KYB), raw materials | Minimum period necessary to complete verification, fraud/security review, and any legally required compliance process — not the lifetime of the account unless a legal or regulatory requirement demands it, per Nigerian AML and fraud prevention obligations | Deleted from restricted store; verification status, timestamps, provider reference IDs, and necessary audit evidence retained for the lifetime of the account and an appropriate period after, without the underlying document | | Payment and invoice records | 6 years (tax and accounting law) | Deleted | | Audit logs (security, billing, identity access) | 24 months minimum | Archived or deleted per legal hold status | | Operational logs | 30 to 90 days by class, identity adjacent shortest | Rotated out | | Analytics events | 12 months | Aggregated or deleted | | Support tickets and associated correspondence | 24 months after closure | Deleted | | Newsletter subscription | Until you unsubscribe | Suppression record kept to honor the unsubscribe |

Personal data may be retained beyond these periods where reasonably required to comply with legal, tax, accounting, fraud prevention, security, dispute resolution, or regulatory obligations. Once the applicable period expires, personal data is deleted, anonymised, or irreversibly de-identified as appropriate. Deletion requests under applicable law are honored ahead of these schedules except where a legal obligation requires retention, in which case we retain the minimum, isolate it, and tell you.

6. Security measures, standing

Encryption in transit (TLS) and at rest on every store. Default deny row level isolation on every database table. Two bucket separation with the identity store under stricter policy. Short lived signed URLs for all file access. Role based access for users (six workspace roles) and staff (four admin roles), with staff access audit logged and support impersonation read only. Multi factor authentication on all staff accounts and on every infrastructure provider account. Server side validation of every input. Layered rate limiting. Webhook signature verification on every payment event. Secrets held only in platform environment stores, never in code. Independent monitoring and alerting on authentication anomalies, isolation violations, and unusual AI usage. Security practices are tested against a launch checklist before production and re run after material changes.

7. Breach response

If we become aware of a personal data breach we will: contain and assess immediately; notify the Nigeria Data Protection Commission and, where GDPR applies, the relevant supervisory authority within 72 hours where the legal thresholds are met; notify affected users without undue delay when the breach is likely to result in risk to them, with a plain description of what happened, what data was involved, and what we and they should do; document the incident and remediation in our internal record. Payment card incidents are additionally handled with the relevant processor under their PCI obligations.

8. Your controls

In product: export your content, delete files, delete projects (30 day recovery), close your account, manage team access, manage notification and newsletter preferences, manage cookies. By request at [privacy@productnerve.com]: access, correction, deletion, portability, objection, and consent withdrawal per the Privacy Policy.

9. Subprocessor changes

The provider table in section 4 is our current subprocessor list. We will update this page when it changes and, for changes involving new processing of venture content or identity data, notify account owners at least [14] days in advance with the ability to object.

10. Review

This policy is reviewed at every material infrastructure change, at the Delaware incorporation, and at least annually. Questions: [privacy@productnerve.com].