Technology & AI Due Diligence Framework

Every investment thesis contains an expected future state.

The first task of technology diligence is to identify where achieving that future state depends materially on technology.

Growth

If revenue is expected to triple, what must happen operationally for that growth to occur?

Which customer journeys experience additional load?

Which transaction volumes increase?

Which systems, databases, integrations and external dependencies must scale with them?

A claim that a platform is “cloud native” does not establish that it can support the workload implied by the revenue model.

The relevant hypothesis is specific:

Can the complete revenue-critical system support the workload required by the growth case at the required service level?

Margin

If margins are expected to expand, what technology economics are embedded in that assumption?

Does cost-to-serve decline with scale?

Are current infrastructure costs temporarily suppressed by credits or contractual incentives?

Do third-party fees increase with customer activity?

Does AI introduce inference, evaluation, review or recovery costs that are absent from the forecast?

The relevant hypothesis becomes:

Does the technology cost curve support the margin expansion assumed over the investment horizon?

Product and Roadmap

If the investment case requires new products, new markets or substantial product evolution, the question is not simply whether a roadmap exists.

The diligence must determine whether the architecture and engineering organization can execute it.

What dependencies constrain delivery?

What technical debt materially affects the roadmap?

What engineering capacity is already committed?

Which changes require architectural intervention before product delivery can proceed?

AI Upside

If AI contributes revenue, productivity or operating leverage to the investment case, that assumption must be decomposed further.

Is the capability technically feasible?

Does it produce accepted business or customer outcomes?

What does an accepted outcome actually cost?

Can the required data be used lawfully and reliably?

Are customers paying for the capability, or merely experimenting with it?

AI activity is not equivalent to AI value.

Execution

Technology outcomes depend on organizations as well as systems.

An architecture may be capable of supporting the plan while the organization lacks the engineering capacity, operating discipline, key-person coverage or management system required to deliver it.

Execution capability is therefore part of the technology thesis.

Transaction Dependencies

The investment case may also depend on ownership and control.

Critical software, data, intellectual property, licenses, vendor relationships or shared services may be subject to contractual, operational or transfer constraints.

A capability that cannot be operated or transferred as assumed can become a transaction condition rather than merely a technology issue.

The output of this module is not a technology inventory.

It is a set of falsifiable technology hypotheses derived from the investment thesis.

Those hypotheses determine what evidence the diligence must seek.

Technology diligence begins with claims.

• ·The platform can support five times current volume.
• ·The architecture is highly resilient.
• ·The engineering organization can execute the roadmap.
• ·Cloud costs will decline as the company scales.
• ·The AI product will create a new revenue stream.
• ·Technical debt is manageable.
• ·Recovery is tested.

These statements may all be true.

But an investment decision cannot treat assertion, design intent and observed operating behavior as equivalent forms of evidence.

The framework therefore uses a disciplined sequence:

Assertion→Evidence→Finding→Implication→Recommendation

Each transition requires support.

An architecture diagram can establish intended design. It does not establish how the system behaves at peak production load.

A management presentation can describe an AI opportunity. It does not establish customer willingness to pay.

A load test can demonstrate behavior under specified conditions. It does not establish scalability if the tested workload omits a production-critical dependency.

A security report can establish findings within its stated scope and period. It does not establish the current state of every system.

A cloud invoice establishes expenditure. It does not establish whether that expenditure is necessary, avoidable or economically efficient.

Evidence must therefore be evaluated according to relevance, provenance, completeness and reproducibility.

System Evidence

System evidence establishes what the technology is actually doing.

This may include production telemetry, traces, configuration, deployment records, repositories, CI/CD evidence, runtime behavior, capacity measurements and observed failure conditions.

The objective is not exhaustive inspection of every system.

The objective is to inspect the systems and behaviors material to the underwriting hypotheses.

Architectural Evidence

Architecture establishes relationships and constraints.

Dependencies, interfaces, data flows, trust boundaries, topology, tenancy models, external services and failure paths reveal where the investment case depends on particular technical mechanisms.

Architecture should be tested against operating evidence.

A dependency that appears absent from a diagram but appears consistently in production traces belongs in the diligence model.

Operational Evidence

Technology is operated, not merely designed.

Incident history, recovery evidence, deployment behavior, exception handling, support burden, service objectives and operational work reveal whether the organization can sustain the system under real conditions.

A recovery plan is evidence of intended procedure.

A successful restore under representative conditions is stronger evidence of recoverability.

Financial Evidence

Technology claims often contain economic assumptions.

Cloud and infrastructure invoices, vendor commitments, credits, SaaS costs, technology staffing, capital expenditures and workload volumes allow the diligence to connect architecture to cost.

Financial evidence should be reconciled with operating evidence.

A cost reduction that exists only in a forecast is different from a resource that has been removed, a contract that has been changed or an invoice that has actually declined.

Organizational Evidence

The investment thesis may depend on execution capability.

Delivery history, team topology, decision rights, engineering capacity, key-person dependencies, roadmap commitments and operating cadence help establish whether the organization can deliver the required future state.

Executive confidence is relevant.

Demonstrated execution is stronger.

AI Evidence

AI requires its own evidentiary discipline because technical activity can easily be mistaken for business value.

Relevant evidence can include model and runtime behavior, evaluations, accepted outcomes, inference cost, human review, retries, recovery, data lineage, rights, customer usage, paid adoption and commercial commitments.

A technically successful pilot establishes technical evidence.

It does not automatically establish recurring revenue.

Evidence Boundaries

Three states must remain distinct:

Not inspected

The diligence has not examined the relevant evidence.

Not present

The expected evidence or capability does not exist within the inspected perimeter.

Failed test

The capability was examined and did not satisfy the defined condition.

Collapsing these states creates false certainty.

If management delays access to production telemetry, the correct conclusion is not that the platform cannot scale.

The correct conclusion is that the scalability assumption remains unsubstantiated within the diligence perimeter.

Missing evidence becomes visible uncertainty.

It does not become an invented finding.

An investment thesis is realized through systems, people, operating mechanisms and execution.

Architecture matters because it constrains what the system can do.

Engineering matters because the future state usually requires change.

Reliability matters because growth without recoverability can amplify exposure.

Management capability matters because remediation and product evolution require sustained execution.

The question is therefore broader than whether the current system works.

It is:

Can the technology organization reliably produce the operating outcomes assumed by the investment case?

Architecture and Scalability

Scalability should be evaluated against the workload implied by the underwriting.

If the investment case assumes three times current revenue, the relevant question is not whether an isolated service survived an arbitrary five-times load test.

The diligence must understand what business activity creates load, how that activity propagates through the system, which dependencies participate in the complete customer journey, where saturation appears and whether the tested workload represents the future operating case.

Production behavior and representative testing should be examined together.

A platform may demonstrate substantial internal capacity while a database, vendor API, identity provider or external service constrains the complete transaction path.

The unit of analysis is therefore the critical business journey, not an isolated component.

Software Asset and Technical Debt

Technical debt matters when it changes the investment case.

Old technology is not automatically material.

The relevant questions are whether coupling, unsupported dependencies, weak test boundaries, obsolete components or architectural constraints increase the capital, capacity or time required to execute the roadmap.

The diligence should identify the work packages required to change the system safely and determine whether those requirements are reflected in the investment plan.

Reliability, Security and Data

Growth assumptions depend on continuity.

Customer obligations depend on recovery.

AI and digital products depend on data that can be accessed, trusted and governed.

The diligence should examine critical failure paths, incident history, recovery behavior, access boundaries, sensitive-data flows and material security findings.

The objective is not to declare the entire environment universally safe.

It is to determine whether material operating exposures alter the investment thesis, require containment or create conditions that must be resolved.

Engineering Execution

The future state implied by underwriting must be built by an organization.

The diligence therefore examines whether the engineering organization can execute the roadmap and remediation agenda within the required period.

Delivery history should be traced through actual work.

A recent feature can be followed from requirement through production.

A significant incident can be followed from failure through diagnosis and recovery.

These traces expose how decisions are made, where work waits, which people hold critical knowledge and whether execution depends on repeatable mechanisms or individual heroics.

Management Capability

Execution is not only an engineering-capacity question.

It is also an accountability question.

• ·Who owns the critical technology outcomes?
• ·Who allocates engineering capacity?
• ·Who resolves conflicts between product commitments, remediation and platform investment?
• ·Who can authorize the changes required by the investment plan?

A technically solvable constraint can remain economically material when no executive owns its resolution or when the required capacity is already committed elsewhere.

Operating Capability as an Investment Variable

The final judgment is not whether the organization is generically “mature.”

It is whether the organization can deliver the technology-dependent outcomes assumed within the investment horizon.

A weakness may therefore produce different consequences.

• ·It may require additional capital.
• ·It may extend the timeline.
• ·It may require specialist intervention.
• ·It may create a Day-1 priority.
• ·It may become a pre-close condition.
• ·Or it may demonstrate that an underwriting assumption cannot presently be supported.

Operating capability becomes investment-relevant when it changes what must be funded, when value can be realized, or whether the future state can credibly be achieved.

A system may support substantially greater workload while the economics deteriorate.

Infrastructure consumption may increase faster than transaction volume. Data movement may become more expensive. Third-party services may price by usage. Reliability requirements may require additional capacity. Artificial intelligence may introduce inference, evaluation and human-review costs. Engineering headcount may need to increase to sustain the platform.

The relevant question is not simply:

Can the technology scale?

It is:

What happens to cost-to-serve, capital requirements and margin as the underwriting case scales?

Establish the Economic Baseline

Technology spending must first be reconciled to the business activity it supports.

Cloud and infrastructure bills, SaaS contracts, data-platform costs, vendor commitments, technology staffing and AI costs should be connected to relevant workloads and business denominators.

The denominator matters.

Cost per customer may be useful for one business.

Cost per transaction, active account, completed workflow or accepted outcome may be more meaningful for another.

The purpose is to establish how technology economics behave as the operating model changes.

Separate Fixed, Variable and Committed Cost

Not all technology cost responds to growth in the same way.

Some cost is relatively fixed.

Some varies directly with workload.

Some changes in steps as capacity thresholds are crossed.

Some remains payable because of contractual commitments even after technical consumption declines.

Temporary credits and incentives require particular attention.

A company may appear to have attractive current cost-to-serve while cloud credits, promotional pricing or other temporary economics suppress the actual long-term run rate.

If those benefits expire during the investment horizon, the underwriting must reflect the economics after expiration.

Model the Underwriting Horizon

Technology economics should be evaluated over the period relevant to the investment case.

If the underwriting assumes substantial growth over five years, diligence should examine how technology cost behaves across that trajectory.

The model should consider changes in:

• ·customer and transaction volume;
• ·infrastructure consumption;
• ·data growth;
• ·vendor and SaaS costs;
• ·contractual commitments;
• ·AI inference and runtime;
• ·human review and recovery;
• ·technology staffing;
• ·remediation;
• ·and incremental capacity investment.

A current-state cost ratio does not establish future operating leverage.

Distinguish Capacity from Capture

Technology and AI interventions frequently release human capacity.

That capacity has economic value, but it is not automatically a cash saving.

If an engineering team saves ten thousand hours but payroll remains unchanged, the organization has created capacity.

The economic consequence depends on where that capacity goes.

It may remove planned hiring.

It may reduce contractor spending.

It may accelerate a revenue-producing roadmap.

It may absorb additional customer demand.

Or it may remain uncaptured.

The diligence should distinguish capacity, cash, margin, capital and growth rather than converting all improvement into a single financial claim.

Identify Remediation Capital

Technology constraints often have an investment solution.

The question is whether that solution is understood and reflected in the underwriting.

A scaling bottleneck may require architectural change.

Recovery may require additional infrastructure and operating work.

Technical debt may consume engineering capacity.

A vendor dependency may require revised commercial terms.

The diligence should identify the work required, estimate a defensible range, establish dependencies and determine when the intervention must occur.

A technology weakness that can be remediated economically may be an investment condition rather than an investment impairment.

Build the Evidence-Adjusted Case

The purpose of technology economics is not to assign an arbitrary financial penalty to technical findings.

It is to construct an evidence-adjusted operating case.

Management Forecast

• ·→ recurring technology-cost corrections
• ·→ remediation investment
• ·→ incremental capacity requirements
• ·→ growth-timing effects
• ·→ contingent upside

= Evidence-Adjusted Operating Case

Where the evidence does not support responsible quantification, the uncertainty should remain explicit.

False precision does not improve investment judgment.

AI creates a particular diligence problem.

Technical capability can be demonstrated quickly.

Economic and commercial value usually requires more evidence.

A model can generate useful output.

A pilot can produce impressive results.

Users can express enthusiasm.

None of these alone establishes durable revenue, operating leverage or product defensibility.

AI assumptions should therefore be tested through a progression:

Technical Feasibility→Accepted Outcome→Economic Viability→Commercial Substantiation→Durability

Technical Feasibility

What does the AI capability actually do?

Where does it operate in the customer or enterprise workflow?

What context does it require?

Which models, tools and systems participate?

What human judgment remains necessary?

The objective is to understand the complete operating mechanism rather than evaluate the model in isolation.

Accepted Outcome

Generation is not equivalent to value.

The framework asks whether the AI system produces an outcome that the business or customer actually accepts.

Acceptance should be defined independently of the system being evaluated.

Rejected outputs, retries, escalations and recovery remain part of the operating system and therefore part of the evidence.

Economic Viability

The relevant economic measure is not simply token cost or inference price.

The framework examines cost per accepted outcome.

That may include:

• ·model and inference cost;
• ·infrastructure;
• ·orchestration and tooling;
• ·evaluation;
• ·human review;
• ·retries;
• ·exception handling;
• ·and recovery.

A cheaper model does not improve economics if it produces more rejected work and increases human review.

AI economics must be evaluated at equivalent quality and acceptance.

Commercial Substantiation

Technical viability does not establish revenue.

If the underwriting assumes AI-generated ARR, diligence must determine what commercial evidence supports that assumption.

Are customers paying for the capability?

Are pilots converting to production?

Is there evidence of recurring use?

What pricing has actually been accepted?

Are customers expanding?

Does the capability solve an outcome customers value enough to purchase?

A technically successful product with strong unit economics but no paid production evidence may represent credible upside.

It does not yet substantiate base-case recurring revenue.

Durability

AI can simultaneously create value and reduce differentiation.

The diligence should examine whether the product advantage depends on a capability that competitors, customers or foundation-model providers can reproduce cheaply.

Durability may instead come from proprietary context, workflow integration, distribution, trust, operating history, rights, switching costs or accountability.

A current capability advantage should not be treated as permanently defensible merely because alternatives cannot reproduce it today.

The relevant question is what mechanism preserves customer value as AI capability changes.

Base Case and Contingent Upside

AI assumptions should ultimately be placed where the evidence supports them.

Technically feasible but commercially unproven value belongs in contingent upside.

Observed customer adoption with viable delivery economics may justify stronger underwriting support.

Claims that fail technical, economic or rights tests may require revision or removal.

The objective is neither to discount AI automatically nor to capitalize enthusiasm.

It is to distinguish demonstrated value from optionality.

Findings should not terminate as technical observations.

Every material finding must return to the underwriting assumption that made it relevant.

The framework classifies each material assumption into one of four states.

Supported

Evidence substantiates the assumption within the examined perimeter.

The conclusion should state the conditions under which that support holds.

Support is not a guarantee that future performance cannot change.

Conditional

The assumption may be supportable, but only if a specified condition is satisfied.

The condition may involve remediation, additional capital, specialist validation, commercial evidence, contractual change or demonstrated operating performance.

A conditional finding must state what evidence closes the condition.

Unsupported

Available evidence contradicts the assumption within the examined perimeter.

The investment case should not continue to rely on that assumption without revision.

Unresolved

Available evidence is insufficient to reach a responsible conclusion.

This may result from missing access, inadequate operating history, contradictory evidence or an untested future condition.

Unresolved uncertainty should remain visible rather than being converted into false confidence.

Translate the Consequence

A finding may change:

• ·recurring technology cost;
• ·remediation capital;
• ·incremental capacity investment;
• ·growth timing;
• ·product assumptions;
• ·AI upside;
• ·management priorities;
• ·transaction conditions;
• ·or the first 100 days after investment.

The appropriate consequence depends on the mechanism.

A scalability constraint may alter growth timing.

An expiring cloud credit may change the margin case.

An untested recovery dependency may become a pre-close condition.

An engineering-capacity constraint may require additional investment or sequencing.

An AI product with strong technical results but no paid adoption may move from base-case revenue to contingent upside.

From Diligence to Action

The final product is therefore not a technology score.

It is a decision architecture.

The investor should be able to see:

• ·What was underwritten.
• ·What the evidence supports.
• ·What remains conditional.
• ·What the evidence contradicts.
• ·What remains unresolved.
• ·What changes economically.
• ·What must happen before close.
• ·What must happen during the first 100 days.

Technology diligence creates value when uncertainty becomes explicit enough to price, condition, investigate, fund or manage.

Its purpose is not certainty.

Its purpose is better investment judgment.