# VerdictTank v3.6 - Minimum Viable Legal (MVL) Framework **Status:** Draft compliance specification. Not legal advice. **Purpose:** Define the engineering and product requirements that must be implemented before VerdictTank accepts White-Label Pilot Account #1. **Source:** Derived from the VerdictTank v3.5 Critical Review (Review ID: VT-35-2026-001), Legal/Regulatory Judge findings, Legal Killers #1 through #5. **Owner:** Product + Engineering, reviewed by outside counsel before publication to any customer or partner. **Scope note:** This document specifies what must be built, stored, disclosed, and contractually required. It does not draft final legal text for execution. All customer-facing legal text (Privacy Policy, Terms of Service, MSA, DPA) must pass through qualified counsel before publication. The templates below are engineering-ready drafts intended to give counsel a working starting point, not a substitute for counsel review. --- ## How to use this document Each of the five sections below maps to one Legal Killer identified in the critical review. Each section follows the same structure: - **Risk** - what happens if this is not fixed, in plain terms. - **Mitigation approach** - the strategy for closing the gap. - **Implementation requirements** - the specific things engineering and product must build, store, or wire up. - **Acceptance criteria** - the checklist that must be fully green before White-Label Pilot #1 is allowed to onboard. None of these five workstreams is optional. The critical review's own MVL section states these are "existence conditions for multi-tenant, multi-jurisdiction operation," not features to defer. --- ## Section 1: AI Liability Disclaimer Template **Legal Killer #2 - EXTREME. AI Liability, Defamation, Tortious Interference.** ### Risk VerdictTank generates scores, critiques, and remediation plans using AI models. A user or a third party can plausibly claim that a low score, a public critique, or a rejected remediation plan caused them financial harm: a lost investment round, a killed procurement deal, a damaged reputation, a broken deal with a counterparty who saw the verdict. Without conspicuous disclaimers and a liability cap on every surface where AI output appears, VerdictTank and any White-Label reseller carry uncapped exposure to claims that an AI-generated opinion caused financial or reputational injury. Right now, zero disclaimer language exists anywhere in the product. This is the second most severe of the five identified Legal Killers. ### Mitigation approach Treat the disclaimer as a rendered platform primitive, not a paragraph of static copy pasted into a page footer. Every output object that carries a verdict, a score, an explanation, an audit finding, or a remediation action item must carry this disclaimer inline, at the point of generation, stored alongside the content itself, not bolted on at the display layer where it can be silently dropped from an API response, an export, a White-Label embed, or a future feature. ### Exact disclaimer text (template for counsel review) This is the baseline text that must appear, verbatim or as approved by counsel, on every verdict, explanation, audit finding, and remediation plan generated by the platform. > **AI-Generated Content Disclaimer** > > This content, including any score, critique, verdict, audit finding, or remediation plan, is an automated output generated by artificial intelligence models. It is not professional advice of any kind, including but not limited to legal, financial, investment, accounting, tax, procurement, or business advice. The opinions, scores, and recommendations expressed are opinions generated by AI models based on pattern analysis of the submitted material, and do not reflect the professional judgment, endorsement, or certification of VerdictTank, its officers, employees, or any White-Label partner. > > Do not rely on this content for investment, procurement, funding, hiring, financing, legal, or comparable high-stakes decisions. AI-generated outputs may be incomplete, inaccurate, outdated, or wrong. You are solely responsible for independently verifying any information before acting on it and for obtaining qualified professional advice where appropriate. > > To the maximum extent permitted by applicable law, VerdictTank's total liability arising from or related to this content, and any decision made in reliance on it, is limited to the amount paid by you for the applicable service in the twelve (12) months preceding the claim, or one hundred US dollars (USD 100), whichever is greater. VerdictTank disclaims all warranties, express or implied, regarding the accuracy, completeness, or fitness for a particular purpose of this content. Short form for space-constrained surfaces (chat bubbles, mobile cards, API metadata fields): > AI-generated opinion. Not professional advice. Do not rely on for investment, procurement, or funding decisions. Liability limited per Terms of Service. ### Implementation requirements 1. **Disclaimer as a data attribute, not UI chrome.** Every verdict, explanation, audit finding, and remediation plan record in the data model must carry a `disclaimer_version` and `disclaimer_text_snapshot` field populated at generation time. Never render disclaimer text purely from a live template at display time with no stored record. If the legal text changes later, historical outputs must still show what was true and displayed at the time they were generated. 2. **No output path bypasses the disclaimer.** Web UI, PDF export, White-Label embed/iframe, public share links, API responses, webhook payloads, and any future chat-to-refine or coach responses must all carry either the full disclaimer or the approved short form. Build a single shared rendering component or API response wrapper that injects the disclaimer, so no individual feature team can accidentally ship a disclaimer-free surface. 3. **Disclaimer cannot be suppressed by White-Label partners.** The MSA (Section 5) must prohibit White-Label partners from hiding, shrinking below legibility thresholds, or stripping the disclaimer in their branded surfaces. Enforce this technically where possible (minimum font size, minimum contrast, non-collapsible by default) in addition to contractually. 4. **Versioning and audit trail.** Maintain a changelog of disclaimer text versions with effective dates. Every generated artifact records which version was shown. This protects the company's position if a dispute arises about what disclaimer language was live when a specific verdict was issued. 5. **Liability cap must match the Terms of Service and MSA.** The dollar/multiple figures in the disclaimer text must be identical to the caps defined in the Terms of Service and the White-Label MSA (Section 5). Do not let these drift out of sync across documents. 6. **Placement rules by surface type:** - Score/verdict card: disclaimer visible without requiring a click or hover, directly below or adjacent to the score. - Explanation text: disclaimer at the top of the explanation block, before the critique content. - Audit finding: disclaimer at the top of each individual finding, not just once at the top of a multi-finding report. - Remediation plan: disclaimer at the top of the plan and repeated adjacent to any single action item that references a decision with financial consequence (e.g., "raise pricing," "cut this feature"). - Roast/Boost public content: disclaimer attached to every publicly rendered card, not just the first view. ### Acceptance criteria before Pilot #1 - [ ] Disclaimer text has been reviewed and approved by outside counsel, including the liability cap figures. - [ ] `disclaimer_version` and `disclaimer_text_snapshot` fields exist on every content type (verdict, explanation, audit finding, remediation plan) and are populated on 100 percent of records in a QA sample of at least 50 generated artifacts across all four content types. - [ ] A shared rendering component or response wrapper is the only code path that emits these content types across web, PDF export, API, and White-Label embed. Verified by a code audit confirming no duplicate/bypassing render logic exists. - [ ] Automated test suite includes a check that fails CI if any of the four content types can be rendered without the disclaimer attached. - [ ] MSA and Terms of Service liability cap language matches the disclaimer text exactly. - [ ] Manual QA pass across every rendering surface (web, mobile, PDF export, White-Label iframe, public share link, API payload) confirms disclaimer visibility and non-suppressibility. --- ## Section 2: Privacy Program Outline **Legal Killer #1 - EXTREME. GDPR/CCPA Non-Compliance.** ### Risk The platform currently stores proposals, chat transcripts, URL snapshots, and corpus data persistently with no retention policy, no deletion policy, no Data Processing Addendum, no Standard Contractual Clauses for EU data transfer, and no Data Subject Access Request workflow. Under White-Label, multi-jurisdictional use, this is the single most severe gap identified in the critical review. A single Data Subject Access Request or regulator inquiry can trigger injunctions, fines, and a forced shutdown of the platform. This is ranked the most existential of the five Legal Killers. ### Mitigation approach Build a privacy program that treats personal data as a first-class, tracked entity across its full lifecycle: what is collected, why, how long it is kept, who can access it, how it moves across borders, and how it gets deleted on request or on schedule. This cannot be a policy document sitting apart from the data layer. It must be wired into the schema, the storage layer, and the deletion tooling from day one. ### Data inventory and retention/deletion schedule Every data type stored by the platform must have an explicit, published retention period and a deletion mechanism. Minimum baseline schedule (subject to counsel and jurisdiction review, and to be reduced further wherever the business does not need longer retention): | Data type | Retention period | Deletion trigger | Notes | |---|---|---|---| | Account/profile data (name, email, org) | Duration of account plus 30 days post-closure | Account deletion request or closure | Grace period allows account recovery | | Proposal/document content submitted for review | Duration of account plus 90 days, or per customer-configured shorter window | Account closure, explicit deletion request, or scheduled expiry | White-Label partners may require shorter windows contractually | | Chat transcripts (coach interactions) | 12 months rolling, or per customer-configured shorter window | Scheduled expiry job or explicit deletion request | Transcripts contain conversational PII; treat as high sensitivity | | URL snapshots (fetched third-party pages) | 12 months rolling | Scheduled expiry job | Snapshots may contain third-party personal data not belonging to the submitting user; shortest defensible retention | | Corpus data used for benchmarking/scoring models | Indefinite only for de-identified/aggregated data; identifiable source content follows the source document's own retention period | Cascades from source document deletion | See Section 4 for licensing and opt-out mechanics governing corpus use | | Audit logs (access, security, admin actions) | 24 months | Scheduled expiry job | Retained longer than user content for security/compliance investigation purposes | | Billing/payment records | Per applicable tax and financial recordkeeping law (typically 7 years) | Statutory expiry | Carve-out from general deletion policy; disclose this exception explicitly in the Privacy Policy | | Roast/Boost public community content | Duration of public posting, removable on takedown request or account deletion | Takedown request, account deletion, or moderation removal | See Section 3 for takedown and moderation mechanics | Requirements arising from this table: 1. **Every table in the schema that stores personal or user-submitted data must carry a `retention_class` field** mapping to one of the rows above, set at write time. 2. **A scheduled deletion job (not a manual process) enforces the retention schedule.** Manual, ad hoc deletion does not satisfy GDPR's "storage limitation" principle at scale and will not survive an audit. 3. **Deletion must cascade correctly across the corpus.** If a document is deleted, any corpus embeddings, benchmarks, or derived scoring artifacts built from that document must also be deleted or provably de-identified. Partial deletion that leaves identifiable fragments in the corpus is not compliant. 4. **Backups are covered by the same policy.** Deleted records must not persist indefinitely in backup snapshots. Define a maximum backup retention window (e.g., 35 to 90 days) after which deleted records are unrecoverable even from backup. ### Data Processing Addendum (DPA) requirements VerdictTank acts as a data processor for customer-submitted content (proposals, chat transcripts) and must offer a DPA to every customer, mandatory for every White-Label partner. The DPA must specify, at minimum: - Categories of personal data processed and purposes of processing. - Duration of processing, tied directly to the retention schedule above. - Sub-processor list (AI model providers, cloud hosting, embedding/vector storage providers) with a mechanism to notify customers of sub-processor changes. - Security measures (encryption at rest and in transit, access controls, breach notification timeline; recommend 72 hours to align with GDPR Article 33). - Customer's instructions govern processing; VerdictTank does not use customer data for purposes outside the agreed scope without additional consent (this ties directly into Section 4's corpus licensing framework). - Audit rights for the customer, or reliance on a recognized third-party audit/certification in lieu of direct audit. - Data deletion or return obligations at contract termination. **Implementation requirement:** the sub-processor list referenced in the DPA must be generated from an actual, maintained internal registry of vendors handling personal data, not manually re-typed into the DPA document. Any new AI model provider, hosting provider, or analytics vendor added to production must first be added to this registry with a compliance sign-off before going live. ### Standard Contractual Clauses (SCCs) note for EU data Because AI model providers and infrastructure are likely to include entities outside the EU/EEA, any processing of EU personal data that results in a transfer to a non-adequate country requires a valid transfer mechanism. Requirements: 1. Incorporate the current EU Standard Contractual Clauses (Module 2, controller-to-processor, or Module 3, processor-to-processor, as applicable) by reference into the DPA. 2. Complete a Transfer Impact Assessment for each cross-border transfer path (e.g., EU customer content processed by a US-based AI model provider), documenting supplementary measures (encryption, access minimization) where needed. 3. For UK data, use the UK International Data Transfer Addendum (IDTA) alongside or instead of the EU SCCs, as appropriate. 4. Maintain a public-facing summary (in the Privacy Policy) disclosing that data may be transferred internationally and identifying the transfer mechanism used, without requiring the reader to parse the full SCC text. 5. Re-review this section any time a new sub-processor is added outside the EU/EEA/UK, or when transfer mechanism guidance changes. ### Data Subject Access Request (DSAR) workflow **This is the single highest-priority build item in the entire privacy program, because it is the mechanism the critical review specifically flags as capable of triggering an existential regulatory event if it does not exist.** Requirements: 1. **Intake channel.** A published, monitored channel (dedicated email address and/or in-product request form) for data subjects to submit access, correction, deletion, and portability requests. Response commitment published in the Privacy Policy: acknowledge within 5 business days, fulfill within 30 calendar days (GDPR baseline; CCPA is 45 days with one 45-day extension allowed; align internal SLA to the stricter GDPR figure so both regimes are satisfied by default). 2. **Identity verification step.** A lightweight but real verification process (e.g., confirming via the account's registered email, or a support-verified identity check for non-account requesters) before fulfilling a request, to avoid disclosing data to the wrong person. 3. **Data layer must support a "find everything about this person" query.** This is the core engineering requirement: build an internal tool (admin-only, audit-logged) that, given an email address or account ID, returns every record across every table and every corpus artifact tied to that identity, including chat transcripts, URL snapshots, and any derived corpus data. Without this, DSAR fulfillment is a manual, error-prone search across the codebase every single time a request arrives, which does not scale past one or two requests and will fail under audit. 4. **Deletion request handling.** The same tool must support a "delete everything about this person" action that triggers the cascading deletion described in the retention section above, with a confirmation step and an audit log entry recording who requested it, who approved it, and what was deleted. 5. **Portability export.** Ability to export a data subject's own content (their proposals, their chat transcripts) in a structured, commonly used format (e.g., JSON or CSV) on request. 6. **White-Label pass-through.** Where a White-Label partner's end customer submits a DSAR to the partner rather than directly to VerdictTank, the MSA (Section 5) must define how that request is routed to VerdictTank's DSAR workflow and within what internal SLA, so the partner is not left unable to comply with its own regulatory obligations. 7. **Logging and reporting.** Every DSAR received, its type, its status, and its resolution date must be logged for compliance reporting and potential regulator inquiry. ### Consent management for chat transcripts and URL snapshots 1. **Chat transcripts.** Before a user engages with the coach/chat-to-refine feature, present a clear notice that the conversation is stored, for what duration (per the retention table), and for what purposes (service delivery, and if applicable, model improvement; see Section 4 for corpus opt-out). Store a timestamped consent record tied to the account, not just a one-time UI acknowledgment with no backing record. 2. **URL snapshots.** When a user submits a URL for review, disclose that the platform will fetch and store a snapshot of that page, including that the snapshot may capture content the user does not own or control (third-party pages). This has a secondary implication: the platform is storing third-party content that may itself contain personal data belonging to people who never interacted with VerdictTank at all. Retention for URL snapshots should therefore be treated conservatively (see retention table) and excluded from any corpus reuse without a distinct legal basis. 3. **Consent versioning.** Like the disclaimer text, consent notices must be versioned, with the version and timestamp recorded per user, so that changes in scope (e.g., adding corpus training as a new use) trigger a re-consent flow rather than silently expanding under old consent. 4. **Withdrawal mechanism.** Users must be able to withdraw consent for non-essential processing (e.g., corpus inclusion) without losing access to the core service, wired to the opt-out mechanism described in Section 4. ### Acceptance criteria before Pilot #1 - [ ] Retention schedule published internally and reflected as a `retention_class` field on every relevant data table, with a scheduled deletion job running and verified in a staging environment. - [ ] DPA drafted, reviewed by counsel, and available to be executed by any prospective customer or White-Label partner before onboarding. - [ ] Sub-processor registry exists, is current, and is the single source feeding the DPA's sub-processor list. - [ ] SCC/IDTA transfer mechanism incorporated into the DPA and a Transfer Impact Assessment completed for at least the primary AI model provider and hosting provider. - [ ] DSAR intake channel is live and monitored, with published SLA in the Privacy Policy. - [ ] "Find everything about this person" and "delete everything about this person" admin tools exist, are audit-logged, and have been tested end to end against a synthetic test account touching all data types (account, document, chat transcript, URL snapshot, corpus-derived data). - [ ] Consent capture and versioning implemented for chat transcripts and URL snapshots, with a working withdrawal/opt-out flow. - [ ] A full DSAR dry run (simulated access request, simulated deletion request) has been executed against a test account and completed within the internal SLA, with results reviewed by whoever owns compliance sign-off. --- ## Section 3: Content Safety Policy **Legal Killer #4 - HIGH. Roast/Boost Defamation Exposure.** ### Risk The Roast/Boost community feature allows public, AI-assisted critique of user-submitted content. Section 230-style safe harbors, where they exist, may not clearly protect AI-generated content the way they protect purely user-generated content, and no such safe harbor exists in most jurisdictions outside the United States. There is currently no Terms of Service, Acceptable Use Policy, or defamation takedown workflow anywhere in the product. A public "roast" that a subject considers defamatory, combined with zero moderation policy or SLA, is a direct path to a takedown demand, a cease-and-desist, or litigation with no established process to respond. ### Mitigation approach Build a content safety stack with three parts: rules for what users may post (Acceptable Use Policy), a process for responding to complaints about content already posted (Notice-and-Takedown), and a standing moderation function with committed response times (Moderation Policy with SLAs). Roast/Boost content specifically needs additional friction and disclaimer treatment given its public, evaluative nature. ### Acceptable Use Policy (AUP) requirements The AUP must be a standalone, linked document (not buried inside general Terms of Service) covering: 1. Prohibition on submitting content that is defamatory, harassing, discriminatory, or that violates a third party's intellectual property or privacy rights. 2. Prohibition on using the coach/chat feature or Roast/Boost to generate or request content that is knowingly false and damaging to a real, identifiable person or business. 3. Prohibition on submitting content that impersonates another individual or business without authorization. 4. Explicit statement that AI-generated critiques (scores, roasts, boosts) reflect the AI system's output, not a claim of objective fact about the subject, tying back to the disclaimer language in Section 1. 5. Consequences for violation: content removal, account suspension, account termination, escalating per the Moderation Policy below. 6. A mechanism for users to report violations, feeding into the Notice-and-Takedown procedure. ### Notice-and-Takedown procedure 1. **Public-facing reporting mechanism.** A "report this content" action available on every piece of public Roast/Boost content, and a general abuse-report channel for anything else. 2. **Intake and triage SLA.** Acknowledge receipt of a takedown request within 24 hours. Make an initial removal/keep decision within 3 business days for standard complaints; expedite to 24 hours for complaints alleging defamation naming a specific real person or business, given the elevated legal exposure. 3. **Precautionary removal option.** For complaints alleging defamation against an identifiable individual or business, default to temporary removal pending review rather than leaving content live during the review window, given the asymmetric downside (a wrongly-left-up defamatory post is far more costly than a wrongly-removed post pending review). 4. **Counter-notice process.** Allow the original poster to contest a takedown with a defined response window (recommend 10 business days), mirroring the structure of DMCA-style counter-notice procedures even though this is not a copyright-specific mechanism. 5. **Repeat-offender tracking.** Track takedown requests per account; define an escalating consequence ladder (warning, temporary suspension, permanent ban) for accounts with multiple substantiated takedowns. 6. **Recordkeeping.** Every takedown request, decision, and rationale must be logged, both for internal quality control and in case the decision is later challenged. 7. **Jurisdictional flexibility.** Build the takedown intake to capture the requester's jurisdiction, since defamation standards vary significantly by country (notably, the balance between free expression and reputational protection differs sharply between the US and much of Europe/UK/Australia). This does not need to be resolved with jurisdiction-specific legal logic at MVL stage, but the data must be captured so triage can escalate cross-border complaints to counsel rather than handling them with the default US-centric process. ### Moderation Policy with SLAs | Severity | Example | Acknowledgment SLA | Resolution SLA | |---|---|---|---| | Critical (alleged defamation naming a real, identifiable party; harassment; illegal content) | A Roast post naming a specific competitor's product as fraudulent | 4 hours | 24 hours (default to temporary removal pending review) | | High (clear AUP violation, no defamation claim) | Hate speech, targeted harassment | 24 hours | 3 business days | | Standard (general complaint, quality/spam) | Low-quality spam submission | 48 hours | 5 business days | Requirements: 1. Moderation queue (already referenced in the technical architecture) must route by severity, not strict first-in-first-out, so critical defamation-adjacent reports are not stuck behind a backlog of spam reports. 2. Human review required for any critical-severity item before permanent action is taken; do not allow a fully automated moderation decision to be the final word on a defamation-adjacent complaint. 3. Moderator decisions and rationale logged, tied to the recordkeeping requirement above. 4. Published moderation policy summary (what is and is not allowed, how to report, expected timelines) accessible from the Roast/Boost feature itself, not only buried in a general legal page. ### Roast/Boost-specific defamation handling 1. **Disclaimer reinforcement.** Every public Roast/Boost card carries the AI disclaimer from Section 1 plus an additional line: "This is a community critique feature. Content reflects the opinion of the submitting user and/or AI-generated output, not a verified factual claim by VerdictTank." 2. **Real-entity friction.** If a submission names a specific, identifiable third-party business or individual who is not the submitting user's own material, apply additional friction before publication: an explicit confirmation checkbox that the user has rights to submit and critique this content, and is not submitting it to harass or defame a named party. 3. **No amplification of unresolved complaints.** Content under an active takedown review must not be algorithmically boosted, featured, or included in shareable digest content until the review resolves. 4. **Indemnification linkage.** The Terms of Service must include a clause under which the submitting user indemnifies VerdictTank for claims arising from that user's own submitted content, consistent with (and referenced by) the White-Label MSA's indemnity structure in Section 5. ### Acceptance criteria before Pilot #1 - [ ] AUP drafted, reviewed by counsel, published, and linked from every Roast/Boost surface and the general Terms of Service. - [ ] Report/takedown intake mechanism is live on every public content surface. - [ ] Moderation queue routes by severity, with the tiered SLA table above implemented and measurable (i.e., timestamps captured at intake, acknowledgment, and resolution). - [ ] Precautionary temporary-removal capability exists and has been tested (a flagged item can be pulled from public view within the critical-severity SLA window). - [ ] Counter-notice workflow exists, even if manually processed at MVL stage, with a defined response window communicated to the poster. - [ ] Roast/Boost disclaimer variant (Section 1 disclaimer plus community-critique line) is live on 100 percent of public cards, verified by QA sample. - [ ] Real-entity confirmation checkbox implemented and required before publishing any submission naming an identifiable third party. - [ ] Takedown/moderation decision log exists and has at least one full test cycle (submit test report, triage, decide, log) run against it before launch. --- ## Section 4: IP Licensing Framework **Legal Killer #5 - HIGH. IP Licensing Ambiguity.** ### Risk The corpus schema currently defaults to shared access across customers, org-scoped but not license-gated. Using one customer's proprietary business content (proposals, pitch decks, strategy documents) to inform scoring, benchmarking, or embeddings that benefit other customers, without an explicit license grant from the content owner, invites both trade-secret misappropriation claims and copyright claims. A single well-funded customer alleging their confidential business content was used to train or benchmark against competitors could obtain a preliminary injunction that freezes the entire corpus, not just that customer's data, given how intertwined shared embeddings and benchmarks can become. ### Mitigation approach Every use of user-submitted content beyond direct service delivery to that same user requires an explicit, revocable license grant, captured at the point of submission, with a working opt-out, and with confidentiality carve-outs that survive termination. Corpus use cannot be a default; it must be an affirmatively granted, scoped, and revocable permission. ### License grant structure 1. **Baseline license (service delivery).** By submitting content, the user grants VerdictTank a license to process that specific content solely to deliver the requested service (scoring, explanation, remediation) to that user or their organization. This is the minimum license needed to operate and requires no separate opt-in. 2. **Extended license (corpus/benchmark use).** A separate, explicit, opt-in grant is required before a user's content can be used to inform scoring models, benchmarks, or embeddings that affect other customers' results. This must be: - **Opt-in, not opt-out**, at least for any use that trains or fine-tunes a model on the content, or that stores the content (or derived embeddings) in a form retrievable in another customer's session. - **Granular**, allowing a user to consent to aggregated/statistical benchmark use (e.g., "your score contributes to an anonymized industry benchmark average") separately from consent to direct model training use. - **Revocable**, with the withdrawal mechanism from Section 2's consent management wired to actually remove the content's influence going forward (acknowledging, and disclosing to the user, that fully unwinding influence already baked into a trained model is not always technically possible; where that is the case, disclose it plainly rather than promising something the system cannot deliver). 3. **De-identification as a default safe harbor.** Where corpus use is limited to de-identified, aggregated statistics (e.g., "the average unit economics score across submissions this quarter"), this can proceed without the extended license, provided the de-identification is genuine (no re-identification risk through combination with other stored attributes) and is documented as such. ### Opt-out mechanism requirements 1. A visible, in-product setting where a user or organization can view and change their corpus/benchmark participation status at any time, not buried in a support-ticket-only process. 2. Changing the setting to opt out must trigger a real technical action: excluding the content from future corpus queries and, per the schema's capabilities, removing or flagging previously included content for exclusion from active benchmarks and embeddings going forward. 3. Opt-out status must be inherited correctly at the organization level for White-Label and team accounts. An individual team member should not be able to unilaterally opt an entire organization's confidential content into corpus use, and organization admins need a single control to opt the whole org out. 4. Default state for new accounts is "not opted in" to extended/corpus use until the explicit opt-in step is completed. Default state for White-Label partner end customers should track whatever the Partner Addendum specifies (see Section 5); do not silently default White-Label end-customer content into the shared corpus. ### Confidentiality carve-outs 1. **Confidential content is excluded from cross-customer corpus use by default**, regardless of general opt-in status, when the content is marked or reasonably identifiable as containing trade secrets, unreleased financials, or similarly sensitive material. Provide a "mark as confidential" flag on submission that, once set, hard-blocks that specific submission from any corpus/benchmark inclusion regardless of the account's general settings. 2. **White-Label partner corpora are isolated by default** (see Section 5), not shared into the general multi-tenant corpus, unless the Partner Addendum explicitly and separately grants that permission. 3. **Confidentiality obligations survive account closure and contract termination.** Content marked confidential, or submitted under a White-Label agreement with confidentiality terms, must not be usable in the corpus after the relationship ends, even in de-identified form, unless the original agreement explicitly permits that continued use. ### Cross-use boundaries 1. **No cross-tenant retrieval.** Under no circumstance should one customer's specific submitted content be retrievable, quotable, or reconstructable by another customer through the product, even where aggregated benchmark statistics are shared. This is a harder requirement than licensing; it is a technical boundary that the corpus schema and any embedding/retrieval layer must enforce (this connects to, but is distinct from, the technical row-level-security controls already noted in the architecture review; licensing sets the legal boundary, RLS enforces it technically, and both are required together). 2. **White-Label boundary.** Content submitted through a White-Label partner's branded surface must not flow into VerdictTank's own general-market corpus, or into another White-Label partner's tenant, absent explicit written agreement in that partner's addendum. This is the direct fix for the trade-secret leakage risk named in Legal Killer #3 and must be read together with Section 5. 3. **Model provider boundary.** Where third-party AI model providers are used to generate scores or embeddings, the contract with each provider must be checked to confirm the provider is not itself retaining or training on submitted content beyond the scope VerdictTank has authorized from its own users. This is a vendor-diligence requirement feeding directly into the sub-processor registry required in Section 2. ### Acceptance criteria before Pilot #1 - [ ] Baseline and extended license grant language drafted, reviewed by counsel, and integrated into account signup and submission flows. - [ ] Opt-in flow for extended/corpus use is live, defaults to not-opted-in, and captures a timestamped consent record. - [ ] Opt-out control is live, changes take effect within a defined and tested window, and organization-level inheritance behaves correctly in a test with a multi-seat test account. - [ ] "Mark as confidential" flag exists on submission and has been verified to hard-block corpus inclusion in a test case. - [ ] Technical audit confirms no cross-tenant content retrieval is possible through any current product surface (chat, benchmark display, embedding search, admin tools), documented as a signed-off test result. - [ ] White-Label tenant isolation confirmed by test: content submitted under a test White-Label partner account does not appear in the general corpus or in a second test partner's tenant. - [ ] Sub-processor/AI model provider agreements reviewed for data retention and training-use terms, with findings logged in the sub-processor registry from Section 2. --- ## Section 5: White-Label MSA Requirements **Legal Killer #3 - HIGH. White-Label Trade-Secret Leakage.** ### Risk There is currently no Master Services Agreement, Partner Addendum, or Data Processing Addendum governing White-Label relationships. The corpus defaults to shared access, and technical isolation controls (row-level security) exist without a contractual framework defining data ownership, license scope, or the chain of liability if something goes wrong. A single cross-use incident or redisclosure claim from a White-Label partner's end customer can result in injunctive relief that freezes the shared corpus for every customer, not just the affected partner. ### Mitigation approach No White-Label partner is onboarded without a signed Master Services Agreement and Partner Addendum in place first. The MSA is the contractual backbone; the Partner Addendum is where White-Label-specific terms (branding, data isolation, revenue share, if applicable) live. Both must be finalized with counsel before Pilot #1, not drafted retroactively after a partner is already live. ### Required MSA terms (checklist for counsel drafting) 1. **Liability cap.** A defined cap on VerdictTank's aggregate liability to the partner, consistent with the cap language in Section 1's disclaimer and the general Terms of Service. Recommend a cap tied to fees paid under the agreement in the preceding 12 months, with standard carve-outs (e.g., no cap on liability for breach of confidentiality, gross negligence, or willful misconduct, per counsel's standard drafting) as applicable. 2. **Disclaimer flow-down.** The partner must agree, as a binding obligation, to display the AI disclaimer from Section 1 on every White-Label surface exactly as delivered, without stripping, shrinking, or materially altering it, and to flow the same "not professional advice" language down to its own end customers in its own terms of service. 3. **Mutual indemnities.** - VerdictTank indemnifies the partner for claims that VerdictTank's underlying platform infringes a third party's intellectual property rights (subject to standard exclusions, e.g., partner's own modifications or misuse). - The partner indemnifies VerdictTank for claims arising from the partner's own branding, marketing claims, or misuse of the platform, and for claims arising from the partner's end-customer content submitted through the partner's branded surface. - Both indemnities should be scoped and capped consistent with the general liability cap, subject to counsel's judgment on carve-outs. 4. **Data ownership.** Explicit statement that each party's end customers retain ownership of their own submitted content. VerdictTank's rights are limited to the license grants described in Section 4 (service delivery baseline, plus any extended/corpus use, which for White-Label partner data defaults to excluded unless separately and explicitly granted). 5. **License scope.** The MSA must state, without ambiguity, that partner end-customer content is not included in VerdictTank's general shared corpus by default. Any exception must be a separate, explicit grant in the Partner Addendum, opt-in, revocable, and consistent with Section 4's confidentiality carve-outs. 6. **Confidentiality.** Standard mutual confidentiality obligations covering both parties' business information and, critically, an explicit statement that partner end-customer content is confidential information not to be disclosed, shared, or used outside the scope of delivering the service to that specific partner, surviving termination of the agreement for a defined period (commonly 3 to 5 years, or indefinitely for trade secrets, per counsel's standard terms). 7. **SLA minimums.** Defined uptime commitment (e.g., a target such as 99.5 percent measured monthly, adjusted to whatever the infrastructure can realistically commit to), defined support response times, and defined incident notification timelines (recommend notifying the partner within 24 to 72 hours of a confirmed security incident affecting their data, tightened further if it involves personal data subject to breach notification law). Include a service credit or remedy structure for missed SLA targets, per standard commercial practice. 8. **Term, termination, and data return/deletion.** Clear termination rights for both parties, and an explicit post-termination obligation for VerdictTank to return or delete the partner's end-customer data within a defined window (recommend 30 to 60 days), consistent with the retention and deletion mechanics built in Section 2. 9. **Compliance flow-down for privacy obligations.** The MSA must obligate the partner to provide its own end customers with adequate privacy disclosures and to route any DSAR received directly by the partner to VerdictTank's DSAR workflow (Section 2) within a defined internal SLA (recommend 5 business days) so that the 30-day regulatory clock is not put at risk by delay on the partner's side. 10. **Content safety flow-down.** The MSA must obligate the partner to enforce the Acceptable Use Policy (Section 3) on any partner-branded submission or community feature, and to cooperate with VerdictTank's takedown and moderation process, including designating a partner-side contact for urgent (critical-severity) content safety escalations. 11. **No sublicensing without consent.** The partner may not resell, sublicense, or grant a further White-Label right to a downstream party without VerdictTank's written consent, to prevent uncontrolled propagation of the platform and its data obligations through a chain of resellers. 12. **Governing law and dispute resolution.** Standard clause, to be set by counsel, ideally consistent across all Partner Addenda to avoid a patchwork of conflicting jurisdictions as the White-Label program scales. ### Partner Addendum specifics (White-Label-specific terms layered on the MSA) 1. Branding rights and restrictions (what the partner may and may not represent about the underlying technology). 2. Explicit corpus isolation statement, restating and cross-referencing Section 4's cross-use boundaries. 3. Any revenue share, pricing, or reseller-specific commercial terms. 4. Any partner-specific technical integration requirements (API access scope, embed restrictions) with security review sign-off before go-live. 5. A named partner point of contact for legal/compliance escalations (content safety, DSAR routing, security incidents), distinct from the standard commercial point of contact. ### Implementation requirements (engineering/product side) 1. **Onboarding gate.** The account provisioning system must not allow a new White-Label tenant to go live in production until a flag confirming "MSA and Partner Addendum fully executed" is set by an authorized internal role. This should be a hard technical gate, not a process reminder that can be skipped under sales pressure. 2. **Tenant isolation configuration tied to the Addendum.** Each White-Label tenant's corpus-sharing configuration (isolated by default, or specific opt-in scope per Section 4) must be set at provisioning time to match exactly what that partner's signed Addendum specifies, with a review step to confirm the technical configuration matches the contract before launch. 3. **SLA monitoring.** Uptime and response-time commitments made in the MSA must be technically monitored and reportable, so the company can proactively identify SLA breaches rather than learning about them from a partner complaint. 4. **Disclaimer and AUP enforcement tooling**, per Sections 1 and 3, must be active on every White-Label tenant's branded surface before that tenant is allowed to go live. ### Acceptance criteria before Pilot #1 - [ ] MSA template and Partner Addendum template both drafted and finalized by outside counsel. - [ ] Onboarding system has a technical gate that blocks production go-live for any White-Label tenant without a recorded, authorized confirmation that the MSA and Addendum are fully executed. - [ ] Tenant corpus-isolation configuration process defined, with a documented review step confirming technical config matches contractual terms, tested against at least one dry-run tenant provisioning. - [ ] SLA monitoring dashboard or reporting mechanism exists for uptime and response-time commitments. - [ ] DSAR routing obligation from the partner is operational: a test request submitted "as if" from a partner routes correctly into the Section 2 DSAR workflow within the defined internal SLA. - [ ] Content safety escalation contact and process tested against a simulated critical-severity report routed through a partner surface. - [ ] Pilot Partner #1 has fully executed both the MSA and Partner Addendum, with signed copies on file, before any production account is provisioned for that partner. --- ## Cross-cutting acceptance gate: White-Label Pilot #1 go/no-go Before any White-Label partner account is provisioned in production, all of the following must be true simultaneously. This is the single go/no-go checklist referenced by the critical review's Minimum Viable Legal requirement. - [ ] Section 1 (AI Liability Disclaimer): fully implemented and verified across all rendering surfaces. - [ ] Section 2 (Privacy Program): retention/deletion schedule live, DPA available, SCC/IDTA mechanism incorporated, DSAR workflow tested end to end, consent management live for chat and URL snapshot data. - [ ] Section 3 (Content Safety): AUP published, takedown and moderation workflows live and tested, Roast/Boost-specific defamation handling active. - [ ] Section 4 (IP Licensing): license grant and opt-in/opt-out mechanisms live, confidentiality flag functional, cross-tenant isolation verified by technical audit. - [ ] Section 5 (White-Label MSA): MSA and Partner Addendum executed by the specific Pilot #1 partner, onboarding gate technically enforced, tenant configuration verified against contract terms. If any single item above is not complete, Pilot #1 does not go live. These five workstreams were explicitly identified as existence conditions, not features on a backlog, and treating any one of them as a post-launch fast-follow reintroduces the exact exposure this framework exists to close. --- ## Document control - This framework must be re-reviewed by counsel whenever a new jurisdiction, new AI model provider, new sub-processor, or new product surface (e.g., a future feature beyond verdicts, explanations, audits, remediation plans, and Roast/Boost) is introduced. - Version this document alongside the platform's own release versioning so it is clear which legal framework version was live for any given product version, mirroring the disclaimer versioning principle in Section 1. - This document is an internal compliance specification for engineering and product implementation. It is not a substitute for the actual customer-facing legal documents (Privacy Policy, Terms of Service, Acceptable Use Policy, DPA, MSA, Partner Addendum), all of which must be independently drafted or finalized by qualified outside counsel before publication or execution.