Generate Dd Checklist Tech Acquisition

Skill: Due Diligence Checklist Generation for Technology / Robotics Acquisition

2. Failure modes the skill is correcting

• The checklist is generated from a generic M&A template without tailoring it to the specific technology sector, missing items unique to software, robotics, automation, and IP-intensive businesses.
• IP and technology diligence items are addressed at a high level without requesting the document types a technology company acquisition requires, such as source code escrow arrangements, open-source compliance materials, software component inventories, and development agreements with IP assignment.
• Entity structure and ownership complexity identified in the deal materials is not reflected in the checklist's corporate and governance section.
• The checklist does not reflect the specific concerns identified in the deal materials, such as preliminary transaction documents, offering materials, or risk factors flagged by the deal team.
• The request list omits the supporting records needed to test scope, ownership, restrictions, and exceptions across multiple entities, products, and jurisdictions.

3. Legal frameworks / domain conventions that apply

• Technology-company diligence priorities: IP ownership and chain of title, freedom to operate, software licensing (inbound and outbound), open-source usage and compliance, data privacy and security, customer contract obligations, service levels, and compliance programs.
• Industrial robotics and automation diligence: patent portfolio, prosecution status, product safety, product liability, field performance, installation and maintenance obligations, and third-party claims.
• Export controls and trade compliance: technology classification, export-license history, sanctions screening, and compliance procedures for robotics and automation products.
• Standard M&A diligence categories still apply: corporate and governance, financial and accounting, tax, employment and benefits, real estate, material contracts, litigation, regulatory, and insurance.
• Request lists should be written as document-and-information asks, not as legal conclusions; use source-document terminology where available and align the asks to the transaction’s defined perimeter.

4. Analytical scaffolds

• Review the executed preliminary transaction documents first and extract the deal perimeter, defined business lines, special diligence asks, excluded assets, and any disclosure or access limitations.
• Review the business overview materials to identify revenue streams, core products, installation/service offerings, recurring revenue, customer concentration, and operational dependencies.
• Review the IP and technology materials to identify product architecture, software components, hardware integration, firmware, data flows, development practices, and any disclosed infringement or ownership issues.
• Review the organizational materials and enumerate all relevant entities, branches, and foreign operations before drafting entity-specific asks.
• Build the checklist by category in conventional M&A order, but tailor each category to robotics and automation where the business facts warrant it.
• For each category, include the records needed to test ownership, compliance, customer commitments, regulatory exposure, and change-of-control sensitivity.
• If the deal materials flag a specific risk, elevate the related request to the front of the relevant category and include the underlying supporting records, not just summaries.
• Where there is more than one business line, product family, jurisdiction, or entity, break the requests out separately rather than collapsing them into a single generic ask.

5. Vertical / structural / temporal relationships

• Treat the checklist as a hierarchy: enterprise-wide requests first, then entity-level requests, then product-, contract-, and jurisdiction-specific requests.
• Distinguish current-state materials from historical records and future-facing obligations; include both where needed to assess continuity and transition risk.
• For software and robotics businesses, trace relationships among source code, firmware, embedded systems, third-party components, deployment environments, service tooling, and customer-facing commitments.
• Where the business uses distributors, integrators, OEM arrangements, or managed services, request both the master form and representative transactions to capture structural variation.
• Where the group includes subsidiaries, foreign branches, or non-operating holding entities, request standalone records for each relevant entity and then group-wide consolidations only as a supplement.
• Where the materials reveal a phased deal process or multiple draft versions, align requests to the latest operative version and preserve any earlier versions that still govern rights, obligations, or disclosure.

6. Output structure conventions

• Produce a single due diligence request checklist organized by subject-matter category using conventional M&A headings.
• Each category should contain concise, specific requests phrased as documents, schedules, policies, registers, agreements, and representative samples.
• Include technology-specific asks inside the relevant category rather than in a standalone “miscellaneous” bucket.
• Use a consistent request style: ask for the operative document, all amendments, side letters, schedules, exhibits, and representative samples where relevant.
• Include an explicit note at the top or in the introductory paragraph that the checklist is tailored to the transaction materials reviewed and should be updated as additional disclosure is received.
• Preserve enough breadth to support a full acquisition diligence process, but keep each request operational and concrete rather than explanatory.
• End with a short Recommended Actions section that directs the deal team to finalize the checklist against the latest documents, circulate it to the seller-facing team, and update it as diligence responses come in.