Loading
Every factual claim in this course traces to something here, grouped by the module it serves. One warning that applies to most of this list: nearly everything published about technical due diligence is published by firms that sell technical due diligence. There is no standards body, no regulator, and no peer-reviewed literature on the practice. Where a publisher sells the thing it is describing, the note below says so, and the lesson that cites it says so too.
Who reads the output, what decision it changes, and the constraints the work runs under.
WhyThe firm describing its own process, and the only concrete published description of a pre-investment technical review on its site: Value Creation team subject matter experts review technology, cybersecurity and data privacy before platform investments, and significant findings are generally communicated to the investment committee and management teams and, where applicable, included in the company’s 100 days list. Everything else about how Vista runs diligence is unpublished — the course cites this sentence and stops there. Primary source for the “who reads it” lesson.
WhyNames five pillars, of which Vista’s Agentic Factory is the first, alongside Operational Transformation, Inference Infrastructure, Strategic Partnerships and Network Advantage. Source for the portfolio figures the course uses: 85+ companies and 100+ operators as of June 30, 2026, and over 250 million users as of December 31, 2025. Note that a Vista press release from April 2026 states 90+ companies and 750 million users — the same firm publishing two different counts on different bases, which is why the course cites the dated figure from this page rather than the larger one. Also the primary source for the graftability lesson (The four axes), where it supplies only the operating-model context and the portfolio scale — Vista publishes no diligence methodology and names no such axis, and that lesson says plainly that it invents the whole thing.
Cited in the graftability lesson (The four axes), as its primary sourceWhyThe firm’s own announcement of the platform the target role sits inside, described as purpose-built to scale agentic AI across its enterprise software portfolio. Useful for understanding the thesis the diligence instrument is meant to serve; useless as evidence of how the work is done, and it makes a superlative claim about being the only platform of its kind that nobody outside the firm has verified.
WhyParagraph .03 states the practitioner does not perform an examination or review and does not provide an opinion or negative assurance; .11 puts responsibility for the sufficiency of the procedures on the specified parties because they best understand their own needs; .32 has the practitioner disclaim any representation about that sufficiency. Has no authority over technical diligence — the course borrows its vocabulary and says so. Primary source for the audit-versus-diligence lesson.
WhyThe rare artifact written for the CTO being diligenced rather than for the buyer. Carries a full data-room checklist (architecture diagrams, DORA metrics, incident logs with root-cause analysis, tested disaster recovery, contractor IP assignment) and a red-flag list including bus factor of one and deferred maintenance inflating financial performance. Its advice to prefer honest engineering communication over scripted or protected staff is what makes it evidence about the norm it is arguing against. Primary source for the three-constraints lesson.
WhyFrames coverage as product functionality, infrastructure, security and innovation potential, and links diligence to value-creation planning. Cited in the course for what its coverage list does not contain: no named workstream for user experience, design systems, accessibility or front-end performance.
WhyThe page carries a pull-quote to the effect that you do not need the keys to the source code or the server farm to learn a great deal about a business from the outside in. The transcript is not published, so this is the firm’s public positioning rather than a documented method — cited that way in the constraints lesson, and useful mainly as evidence that code-free diligence is a real posture at a major firm.
WhyThe clearest published account of access as a staged negotiation: a competitive seller guards the codebase until exclusivity, releasing architecture, stack, hosting bill, dependency manifests and IP chain of title but not the repository or commit history. Also the source for the line that a confirmatory finding rarely kills a deal and more often gives the buyer a number to negotiate with.
WhyStates two-to-four weeks at a fixed fee for the core engagement, and lists a remediation roadmap with cost and timeline estimates among the deliverables. The duration is self-reported by a firm quoting for the work — the course cites the shape of the phasing, never the number as a fact. The same deliverables-list line is also cited in remediation-in-weeks (The scorecard as a product), establishing that a costed remediation roadmap is a named deliverable rather than evidence of any particular duration.
WhyThe sharpest published statement of the audit/diligence boundary: a diligence is not a penetration test, a code-quality audit or a vendor assessment, because those are downstream activities once you own the asset. Also the severity ladder the course uses — critical findings reprice or trigger escrow, high findings need a plan before close, medium findings go into the 100-day plan — and the warning that a target offering only a prepared deck and one management interview yields a surface-level read. That same severity ladder is cited again in the-finding-they-will-dispute (The scorecard as a product), as the mechanism by which a disputed finding either changes a deal or slides quietly down a rung.
WhyA seven-workstream enumeration — architecture and scalability, code quality and delivery, team and key-person risk, security and compliance, IP and licensing, data and AI exposure, roadmap credibility — which is the cleanest published list the course found, and another one with no front-end or UX workstream in it. Its best single line is that a new engineer being able to run the system locally and ship a small change within a week is the best available proxy for codebase health.
WhyEvidence that vendor due diligence is a named, purchasable practice: a seller commissions a review to surface issues before buy-side diligence and eliminate deal killers, in service of a higher valuation. Stated by a firm that sells it, which is exactly why it is credible on the incentive structure. Cited in the constraints lesson for the possibility that the target has already been assessed by someone hired to find what you are looking for.
The evidence behind each axis — a UX maturity model with named stages, framework support windows with real dates, and what a published standard actually says about human approval.
WhySix stages in order: Absent, Limited, Emergent, Structured, Integrated, User-Driven, cut across by four factors — strategy, culture, process, outcomes. Two cautions the course must carry. NN/g says a complete evaluation needs interviews, process analysis, deliverable assessment and organisation-wide surveys, which is more access than a diligence gets. And NN/g sells a paid UX Maturity Assessment engagement, so the free model is the top of a consulting funnel. The superseded 2006 eight-stage model has entirely different stage names and is retained on the site — confusing the two is an easy and visible error.
WhyThe page that matters most for an outside-in read: how to use the maturity model without a formal assessment, by reading signals in project outcomes, stakeholder feedback, product metrics, and when design gets involved. It also warns against overassessment turning maturity into a scoreboard rather than a healthy system — which is a warning aimed squarely at what a diligence scorecard does.
WhyA free self-assessment quiz plus the distribution of 5,371 self-selected respondents across the six stages. NN/g’s own caveats are unusually strong and must travel with the numbers: the respondents were not representative, low-maturity organisations are likely under-captured, and NN/g does not believe an individual’s assessment is the best way to determine organisation-wide maturity.
WhyThe one published adoption metric the course found with a real formula behind it: design-system component layers divided by total layers, scoped to recently edited files and handoff-marked pages, with a worked example of seven system layers out of fifteen total reported as 46.6%. It explicitly declines to name a target, saying it is hard to claim there is an ideal adoption number. Read its 50%-versus-2% pairing carefully: the post offers that as a hypothetical illustration of the spread a dashboard might show, not as Pinterest’s own measured result for named teams, and citing it as reported data is a misread. The teaching point survives either way — the spread between teams is the diagnostic signal, and no published adoption benchmark exists anywhere the course could open.
WhyWhat is actually measurable about a design system in Figma: insertions, detachments, total instances, teams and files using a library, and usage trends. Gated to Organization and Enterprise plans, with the analytics API restricted to Enterprise — which matters for a diligence, because whether a target can produce these numbers at all is itself evidence about the plan they are on and the attention they pay.
WhyAdoption named by 36% of maintainers as both a priority and a challenge; 84% of subscriber respondents said they were required to use the system. Small self-selected sample from a consultancy that sells design-system work, so treat the percentages as directional at best. Cited for what organisations report struggling with, not as a benchmark.
WhyThe canonical named method for measuring consistency debt: a comprehensive collection of every bit and piece that makes up an interface. The follow-up, Conducting an Interface Inventory (May 11, 2015), names sixteen categories to sweep. It publishes no numeric counts and no thresholds — the method is real, the benchmark does not exist.
WhyTurns consistency debt into countable evidence. Reports over 200 metrics and, importantly, gives both a total and a unique count per category — unique colours, font sizes, line heights, z-indexes, shadows, border radii, plus specificity distribution and `!important` counts. The uniqueness ratio is the closest thing to an objective consistency-debt measure that runs against a stylesheet you can fetch from outside.
WhyAngular moved to a yearly major release cycle starting with v22, having previously shipped majors every six months. Majors are typically supported for 24 months: 12 active, then 12 of long-term support with critical fixes and security patches only. The page carries the live table of which versions are in which state, and states that versions 2 through 19 are no longer supported. This is the model for what a dated, checkable support window looks like.
WhyThe important negative finding for the front-end debt axis. React commits to semantic versioning and to backporting security fixes to all affected major versions, and publishes no LTS window and no end-of-life dates at all. So a React version cannot be scored the way an Angular version can — there is nothing to fall off. Any rubric that scores “framework is past end-of-life” must handle the case where the framework never publishes one.
WhyThe authoritative dated table, which nodejs.org itself does not publish: even-numbered majors get 12 months of active LTS then 18 months of maintenance, a 30-month window, with explicit end-of-life dates per line. Worth citing over the website, which shows status and codenames but not the dates a diligence finding would rest on.
WhyThe `strict` flag turns on the whole strict-mode family — `alwaysStrict`, `strictNullChecks`, `strictBindCallApply`, `strictBuiltinIteratorReturn`, `strictFunctionTypes`, `strictPropertyInitialization`, `noImplicitAny`, `noImplicitThis` and `useUnknownInCatchVariables` — and the docs warn that future versions may add checks under it, so an upgrade can surface new errors. Note the precise claim: `true` is what `tsc --init` writes into a generated config, not the compiler’s behaviour in the absence of one.
WhyNamed, individually scored checks for dependency and supply-chain risk — Maintained, Code-Review, Branch-Protection, Pinned-Dependencies, Dependency-Update-Tool, Signed-Releases, Dangerous-Workflow and others — each carrying a stated risk level and scored 0 to 10. Cite the individual check names rather than a total; the doc states the set changes over time.
WhyWhat the command actually does: posts the dependency tree to the registry and returns advisories with a severity of info, low, moderate, high or critical. The detail worth knowing in a diligence is that `--audit-level` changes the failure threshold and does not filter the report — so a clean CI run says nothing about what the report contains.
WhyA SOC 2 examination reports on controls relevant to security, availability, processing integrity, confidentiality or privacy — the five Trust Services Criteria categories, governed by the 2017 criteria with revised points of focus, published September 30, 2023. The Type 1 versus Type 2 distinction is not stated on AICPA’s free pages; it lives in paywalled guides and the attestation standards, so the course does not attribute that distinction to AICPA. The related point that is on the site: SOC 3 is the general-use report, which is why a vendor will hand one over freely and gate the SOC 2.
WhyThe closest thing to a citable, vendor-neutral vocabulary for agentic readiness, and it should be labelled for what it is. Its security principles require explicit user consent before any tool invocation and clear interfaces for reviewing and authorising activity, while conceding that the protocol cannot enforce any of this — enforcement is left to the host application. Note that this revision is a large redesign: the protocol is now stateless, and Roots, Sampling and Logging are all deprecated.
WhyThe most precise published vocabulary for the review-and-approval question on the agentic-readiness axis: a three-action response model of accept, decline and cancel, where cancel means the user dismissed without an explicit choice. It also forbids collecting credentials or payment details through the in-client form path and requires clients to show which server is asking and let users edit before sending. A product that already has these concepts scores differently from one that has to invent them.
Turning evidence into one page: remediation estimates, thresholds a second reader would reproduce, and findings that survive being disputed. Two of the module’s central claims are the course’s own and are labelled as such in the prose — the one-page limit, which no published source establishes, and “the most valuable finding is the one management disputes”, which is a synthesis rather than a quotation. Most of what follows is a vendor publishing about a service it sells; the exceptions are the measurement paper, which sells nothing, and the two accessibility standards, published by bodies that sell nothing here either.
WhyPrimary source for the one-page-or-nothing lesson, cited there for one thing only: its picture of the reader — a report written to a lender-grade standard, where every material finding is evidenced because the reader was in none of the meetings that produced it. It is explicitly not the source of the page limit: nothing in it states a page count, and its own worked material runs longer than a page, and the lesson says so in prose. Also cited, in “What a diligence is for”, for its phase shape — a pre-offer screen in days, a deep dive in weeks, a confirmatory pass in days — and for the supervised-read and escrow arrangements where code is reviewed on the target’s machine or by a neutral third party without reaching the buyer.
WhyPrimary source for the red/amber/green test, and the one place this module borrows a real named concept: inter-rater reliability. It is cited for a single idea — that raw percent agreement overstates reliability, because some agreement happens by chance and how much depends on how the categories are distributed. The lesson does not take any numeric band from it, computes no coefficient, and states in a callout that the transfer from clinical measurement to a four-mark diligence page is the course’s argument rather than the paper’s.
WhyPrimary source for the remediation-in-weeks lesson, cited for the form of a costed finding rather than for any figure in it: individual findings priced in engineer-months and totalled. Every number in it is illustrative, self-reported by a firm marketing into this process, with no independent survey behind it, and the lesson takes none of them. Also cited in one-page-or-nothing as one of the two published worked examples that run longer than a page, and in “What a diligence is for” for a concrete statement of how narrow code access is when granted: read-only for five to ten business days, for a named reviewer, under NDA.
WhyAn openly readable checklist across eight sections, notable for two things the vendor lists lack. It names specific tooling per section rather than gesturing at capability, and its data-integrity section is explicitly about catching metric misrepresentation — comparing stated user counts against login records, checking analytics for bot and internal traffic. Its remediation guide maps findings to specific fixes, which is the closest published model for the estimate half of the scorecard.
WhyPrimary source for the-finding-they-will-dispute, quoted for the information asymmetry: the seller knows everything, the buyer far less, and the seller is incentivised to downplay the negatives. The lesson uses it to establish that disagreement is structural rather than an accusation of bad faith. Its negative finding is also worth carrying — its four-category diligence framework omits technology entirely. The same information-asymmetry point is also cited in “What a diligence is for”.
WhyPrimary source for running-it-on-a-real-product, and quoted again in the-finding-they-will-dispute, for the same sentence: a company will cherry-pick what a reviewer sees, so the sample is not representative. The final lesson turns it around — outside-only evidence is uncurated but still biased, because the publicly reachable surface is the part a company has the most reason to keep polished. That inversion is the course’s reasoning, not AKF’s. Also cited in “What a diligence is for”, as a rare case of a diligence vendor conceding a limit of its own product.
WhyCited for precision rather than depth: WCAG 2.2 became a W3C Recommendation on October 5, 2023 and the living version carries a revision dated December 12, 2024. Conformance levels are A, AA and AAA, and the specification itself notes that even AAA content will not be accessible to people with all combinations of disability. A target claiming “WCAG compliant” without naming a version and a level has not made a checkable claim, which is a finding. Also cited in the ux-maturity lesson (The four axes), for the same point, on the accessibility-posture question.
Cited in the ux-maturity lesson (The four axes)WhyThe dates moved in 2026 and anything written before then is stale, which makes this a good example of why a diligence rubric cites primary documents rather than summaries. The compliance date for state and local government entities of 50,000 or more was extended from April 24, 2026 to April 26, 2027, and for smaller entities and special districts from April 26, 2027 to April 26, 2028. The technical standard, WCAG 2.1 Level AA, is unchanged.
Every claim on these pages links to its source. If a source looks wrong or out of date, check the resource list and tell your teaching agent — the course is meant to be corrected.