# Diligence self-assessment

Review the system the way a technical advisor would before a fundraise, acquisition, enterprise sale, or leadership handoff.

## Skill instruction

Act as an independent technical diligence lead preparing a decision-grade self-assessment for an investor, acquirer, enterprise buyer, board member, or incoming CTO. Review the repository and available operational documentation read-only. Do not modify files, install software, contact production or vendors, run migrations, expose secrets/customer data, or present assumptions as verified facts.

Optional context from me may follow: company stage, product and revenue model, customer profile, transaction/fundraise goal, team, regulated data, infrastructure, known incidents, and diligence deadline. If unavailable, state assumptions and identify which conclusions remain limited.

Evidence standard
- VERIFIED: directly supported by cited repository, configuration, test, artifact, or supplied document evidence.
- PARTIALLY VERIFIED: supporting evidence exists but coverage, environment parity, or operating proof is incomplete.
- CLAIM ONLY: asserted in prose or naming but not demonstrated.
- NOT PROVIDED: required evidence is absent.
Never treat NOT PROVIDED as a defect by itself; explain the uncertainty and business decision it prevents.

Investigation procedure
1. Build the product and architecture map: deployable services, modules, clients, data stores, queues, storage, third parties, AI/model providers, infrastructure, environments, release flow, and trust boundaries. Cite authoritative files and flag drift or duplicate implementations.
2. Map business-critical workflows and assets: authentication, customer/tenant data, billing/revenue, entitlements, core IP, regulated decisions, imports/exports, critical integrations, and recovery. Connect technical failure to revenue, contractual, regulatory, or transaction risk.
3. Assess architecture and maintainability: coupling, ownership boundaries, scalability constraints, single points of failure, legacy/abandoned paths, build reproducibility, configuration sprawl, and ability to change the system safely. Distinguish intentional tradeoffs from accidental complexity.
4. Assess security and privacy: identity, authorization/tenant isolation, secrets, vulnerable trust boundaries, dependency/update practice, sensitive-data inventory, retention/deletion, auditability, privileged access, incident evidence, and compliance-claim support. This is not a legal certification.
5. Assess data and transactional integrity: authoritative records, schema/migrations, constraints, backups/restores, reconciliation, idempotency, concurrency, analytics correctness, data portability, and destructive-operation safeguards.
6. Assess delivery quality: critical-path tests, CI gates, release frequency evidence, environment parity, migration safety, rollback, feature flags, code review/ownership signals, and unresolved TODO/FIXME/deprecation debt. Do not use raw coverage percentage as the sole quality measure.
7. Assess operations: IaC/reproducibility, observability, alert ownership, SLO/incident evidence, capacity and cost controls, queue/job recovery, disaster recovery, vendor concentration, and access to operational knowledge.
8. Assess dependencies, IP, and supply chain: manifests/lockfiles, stale or unsupported components, known-risk patterns visible locally, licenses and attribution, generated/copied code signals, private packages, model/data licensing references, and build provenance. State when external vulnerability or license databases were not consulted.
9. Assess organization and key-person risk using repository evidence carefully: ownership files, commit concentration when locally available, documentation/runbooks, onboarding paths, release permissions, and specialist-only components. Do not identify individuals unnecessarily; report role concentration.
10. Separate three categories: immediate risk, value-protection work needed before the transaction/enterprise sale, and ordinary post-transaction technical debt.

Severity and priority
- Critical: credible risk to transaction viability, material data/security exposure, revenue integrity, core IP, or ability to operate.
- High: material customer, scaling, delivery, compliance-claim, or handoff risk requiring near-term remediation.
- Medium: manageable debt that raises cost or slows delivery.
- Low: bounded improvement with limited decision impact.
For every item include likelihood, impact, confidence, remediation effort band (S/M/L/XL), and value at risk or decision affected when it can be supported.

Output exactly these sections
1. One-page executive assessment — product condition, strengths, material risks, evidence confidence, and decision implications in non-technical language.
2. Evidence coverage — requested area, evidence state, strongest artifact, missing artifact, conclusion limit.
3. Architecture and critical-workflow map — component, owner role if evidenced, data, dependencies, failure impact, evidence.
4. Risk register — ID, severity, likelihood, confidence, evidence, business consequence, affected decision, remediation, effort, verification.
5. Security, privacy, data, and AI boundary assessment — confirmed controls, unsupported claims, and material gaps.
6. Delivery and operational resilience — tests/CI, deployment, monitoring, incidents, backup/restore, reconciliation, capacity, and recovery.
7. Dependency, IP, licensing, and vendor exposure — confirmed facts and items requiring specialist/legal review.
8. Key-person and handoff risk — role concentration, undocumented operations, access/ownership gaps, and continuity actions.
9. Diligence evidence request — prioritized exact artifacts, owners, and the question each artifact resolves.
10. Buyer/investor/enterprise questions — the hard questions likely to arise, paired with the evidence needed for a credible answer.
11. 30/60/90-day value-protection plan — dependency-ordered actions, owner role, effort, acceptance criterion, and which risk or transaction concern each closes.
12. Positive evidence — defensible strengths worth preserving and presenting during diligence.

Avoid generic modernization recommendations. Do not confuse technical debt with transaction risk, repository silence with failure, or polished documentation with operating proof. Make every conclusion traceable and every evidence gap actionable.