Design Partner Review
Review the supplied agreement as the controlling paper. Use assets/template.docx only as a disclosed house-form comparator for issue coverage and possible fallback language. Never replace the supplied paper with the template, transfer template block identifiers into it, or describe the template as market consensus.
Scope gate
Classify the transaction from its substance, not its title:
- A design-partner deal ordinarily combines early or pre-release access, recurring partner feedback, and provider product-development or improvement activity.
- A short trial centered on pass/fail criteria and a go/no-go decision is functionally a pilot or evaluation. Say so and do not apply design-partner assumptions unless the user asks to continue under that lens.
- Shared inventorship, joint ownership, or substantial engineering contributions may require a joint-development agreement.
- A production subscription masquerading as a design-partner program may require an MSA, SaaS agreement, SLA, and DPA. Flag the missing commercial framework.
Intake and document set
Confirm the represented party, contract stage, leverage or deadline, product maturity, business objective, fees or value exchanged, and whether personal or regulated data will be used. Ask for incorporated order forms, exhibits, online terms, NDA, DPA, security addendum, subscription agreement, and relevant redlines. State any missing document that limits the review.
Read the entire contract package before prioritizing findings. Reconcile related documents rather than reviewing clauses in isolation.
Create a private coverage ledger before writing. Disposition every cover-page field, section, exhibit, incorporated document, and issue-map row as Finding, Acceptable, Not Applicable, or Missing Information. The executive summary may identify only the most important issues; the findings table must include every material RED or YELLOW issue.
Review workflow
- Build a section map of the supplied agreement and identify incorporated or missing documents.
- Run a structural-integrity sweep for blanks and default effects, undefined or unused terms, duplicate numbering, broken cross-references, wrong exhibits, incorporated URLs, signature defects, supersession, assignment, termination reach, survival, and order of precedence.
- Determine whether each obligation is binding, discretionary, aspirational, or undefined.
- Review every issue below from the represented party's perspective, including omissions.
- Compare the result with
assets/template.docxonly to identify house-position gaps or usable fallback concepts. - Classify findings:
- RED: legal/compliance defect, unintended ownership or data right, uncapped material exposure, unbounded development duty, or business structure requiring approval.
- YELLOW: meaningful negotiation point, ambiguity, operational burden, or unfavorable but potentially acceptable allocation.
- GREEN: acceptable or favorable term worth recording; do not clutter the redline with stylistic edits.
- For each RED or YELLOW finding, provide the section and exact quote, current effect, risk, recommended position, proposed language, fallback, and any business or factual question.
Issue map
| Issue | Review questions |
|---|---|
| Transaction characterization | Is this genuinely a design-partner program, or is it a pilot, production subscription, services engagement, reseller arrangement, or joint-development deal? Are any required companion agreements missing? |
| Product and access | Is the product and permitted use clear? Are users, environment, integrations, restrictions, availability, production use, and third-party dependencies addressed? Can access be suspended or revoked arbitrarily? |
| Partner obligations and feedback | Are testing, use, meetings, feedback cadence, personnel, response times, data contributions, case studies, and references clear and feasible? Is the partner required to disclose confidential or third-party material as feedback? |
| Provider obligations and features | Are onboarding, support, configurations, research, development, feature deadlines, acceptance, and update commitments bounded? Does aspirational roadmap language create enforceable delivery duties, or does broad discretion make the promised exchange illusory? |
| Fees and costs | Is the program free or paid? Are invoices, taxes, refunds, expenses, third-party/pass-through charges, discount consideration, and approval rights clear? Are supposedly free services subject to open-ended costs? |
| Term, termination, and wind-down | Check effective date, duration, renewal/extension, termination for convenience and cause, cure, suspension, access cutoff, accrued amounts, return/deletion, transition, and survival. Does one party retain obligations after losing the expected benefit? |
| Commercial conversion | Is later contracting optional or mandatory? Check auto-conversion, pricing, discounts, credits, conditions, expiration, exclusivity, minimum commitments, and which future agreement governs. Do not let an incomplete conversion clause create a production relationship without full terms. |
| Confidentiality | Reconcile any NDA. Check definition, marking requirements, exclusions, compelled disclosure, permitted recipients, standard of care, duration, return/destruction, residuals, the agreement's existence, and whether feedback is carved too broadly out of confidentiality. |
| Data, security, and DPA | Identify data categories, ownership, instructions, permitted uses, aggregation/de-identification, AI/model training, safeguards, incidents, subprocessors, transfers, retention/deletion, audit rights, and regulated-data limits. Treat personal-data processing without an adequate DPA as an escalation, not a drafting detail. |
| IP and feedback | Check background technology, product and improvements, custom features, deliverables, partner materials/data, feedback assignment or license, derivative works, third-party/open-source inputs, further assurances, and residual knowledge. Flag joint ownership, overbroad assignment of partner know-how, or rights insufficient to commercialize product improvements. |
| Publicity and references | Separate private customer or investor references from public name/logo use, case studies, testimonials, quotes, press releases, and reference calls. Check approval, control over wording, revocation, frequency, and post-termination use. |
| Warranties and disclaimers | Assess early-stage and as-is disclaimers, authority, rights in contributed material, legal compliance, non-infringement, product performance, regulated-industry duties, and reliance on outputs. Are disclaimers enforceable and consistent with express commitments? |
| Liability and indemnity | Identify missing as well as unfavorable clauses. Check indirect/consequential exclusions, cap base and amount, carve-outs, supercaps, uncapped obligations, exclusive remedies, and claim aggregation. Review IP, data, confidentiality, bodily injury, and misconduct indemnities plus defense control and settlement rights. Surface an intentional absence of a cap or indemnity; never assume omission is balanced. |
| General terms | Review restrictions, non-exclusivity, exclusivity/MFN, assignment/change of control, subcontracting, notices, governing law/forum, equitable relief, modifications, severability, waiver, entire agreement, order of precedence, independent-contractor status, third-party beneficiaries, export/compliance terms, counterparts, and survival. Check conflicts with any investment, advisory, reseller, or other relationship. |
Treat cover-page blanks and default mechanics as substantive when they control party identity, effective date, product scope, fees, term, governing law, risk allocation, or signatures. Analyze custom outputs and features separately from the underlying product: ownership, license, permitted use, third-party inputs, acceptance, reuse, and commercialization rights must be explicit. Identify every affiliate, adviser, investor, integrator, model provider, or other participant whose access or obligations may require a companion document.
Review output
Provide:
- an executive summary with transaction classification and the three to five most important issues;
- a prioritized findings table with section/quote, severity, effect, recommendation, proposed language, fallback, and open fact;
- cross-document conflicts and missing companion documents;
- a short list of business decisions requiring the user's approval; and
- if requested, a tracked-change DOCX redline of the supplied paper.
The three-to-five-item limit applies only to the executive summary. Do not merge distinct structural, IP, data, program, or risk-allocation findings merely to make the table shorter.
Do not copy language from a public comparator merely because it is available. Use published forms as issue-spotting perspectives, verify that any borrowed text fits this transaction, and do not call a single form the market standard.
Deterministic DOCX redline workflow
- Preserve the supplied source and make a working copy. Record its hash if supported.
- Extract current paragraphs, table cells, headers, footers, comments, and revisions; capture stable identifiers when the editor provides them.
- Build edit intent against exact quotes and structural anchors from the
supplied paper—not
assets/template.docx. Include the operation, complete proposed text, rationale, severity, and fallback. - Validate all anchors against the unchanged working baseline. If the editor uses blocks, resolve duplicate-block conflicts and use one operation per block. Never guess at an ambiguous location.
- Apply tracked changes with the available deterministic DOCX editor. Re-extract and confirm every approved edit appears exactly once, no text was truncated, and untouched language remains unchanged.
- When the host can render DOCX, inspect every page; otherwise use text readback and disclose the unavailable visual check.
- If no deterministic DOCX editor is available, or if it cannot safely reach a required table, header, footer, signature block, comment, or revision, deliver the findings and clause-by-clause edit intent. Identify the limitation and do not claim that a redline was created.
Final checks
Before delivery, confirm:
- the review states the represented party and correctly classifies the transaction;
- the supplied paper, every incorporated document, and all material omissions were addressed;
- every cover-page field, section, exhibit, incorporated document, and issue-map row has a coverage-ledger disposition;
- program duties and feature commitments are operationally bounded;
- data rights match the data flow and any DPA/security dependencies are identified;
- IP, feedback, publicity, conversion, liability, and indemnity positions are explicit;
- proposed language does not introduce conflicting defined terms, broken cross-references, or a new business commitment;
- the template was used only as a comparator and no template-specific facts, identifiers, or assumptions entered the target; and
- any redline preserves the source, opens intact, matches the findings, and renders correctly when the host supports rendering.
Public comparator
The current Common Paper Design Partner Agreement may be used for issue spotting. Its omission of privacy/security terms, liability limits, indemnities, or service commitments may be intentional but must be analyzed for the actual transaction. Do not copy its language or treat one form as market proof.
