Start with the missing conclusion and finish with lender action.
Independent technical underwriting for AI infrastructure finance
AI infrastructure debt is repaid by useful compute, not installed GPUs.
Doku tests the complete performance chain from power and cooling to topology, software, operator, and workload. The conclusion is whether the financed system can deliver the billable performance and cash flow assumed by the debt case.
30 minutes. Fit or no fit. No project files. Direct founder reply within two business days. Prefer email? Reply with the financing context.
- Identify technical assumptions that can invalidate the repayment case.
- Translate architecture and operating risks into credit protections.
- Monitor whether useful compute and revenue remain consistent with the approved case.
Founder-led technical credit synthesis
Jorg Doku is the former Head of ML at RunPod, with prior AI work at Google Brain and Meta AI Research. The first review and every proposed scope are led directly by Jorg.
Role-specific review pathsChoose the evidence your role needs first.Four concise paths through the same underwriting note
Inspect system states, test questions, method, and evidence.
Trace financed equipment to deployability, value, and protection.
Review repeatable decision records, surveillance, and residual risk.
01 / The underwriting gap
The financial model may be complete while the technical model is missing.
Tenant credit, sponsor quality, lease terms, construction budget, power contracts, collateral, leverage, debt-service coverage, and refinancing can all be competently reviewed without proving that the financed AI system can deliver competitive, reliable, billable compute.
- 8,000 GPUs
- Signed customer agreement
- Expected utilization
- Contracted megawatts
- Forecast revenue
- Equipment collateral
- Whether the topology fits the workload
- Whether the GPUs operate as a coherent cluster
- Whether storage can sustain the workload
- Whether failure domains are correctly designed
- Whether competitive goodput is achievable
- Whether the operator can diagnose failures
- Whether the borrower controls remediation
- Whether the cluster is redeployable after customer loss
Irreversible decision gates
Test the technical assumption before capital crosses the gate.
Best fit is a North American financing, typically $100M to $3B, where one unresolved technical fact can change approval, funding, structure, covenant, reserve, or surveillance.
- 01Before credit approval
Can the proposed system deliver the workload performance, customer value, and cash flow assumed by the debt case?
Proceed, restructure, require evidence, or stop before nominal capacity becomes an accepted repayment assumption. - 02Before funding or draw
Do acceptance evidence, control rights, responsible experts, and closure records satisfy the agreed financing conditions?
Condition funding, resize exposure, hold a reserve, or defer the draw before capital crosses the gate. - 03During the financing tenor
Do useful compute, reliability, customer economics, and remediation remain consistent with the approved case?
Escalate reporting, remediation, covenant, reserve, or intervention before technical deterioration becomes a credit event.
Nominal capacity is observable. Economically useful compute requires technical judgment.
Conventional data-center underwriting, project engineering, and transaction diligence remain necessary. Their scopes often do not include distributed training, GPU fabrics, collective communication, workload topology, cluster orchestration, or neocloud operations. The missing conclusion sits across those layers.
Transaction evidence: CoreWeave credit agreement and IREN financing disclosure. These public filings support financing and acceptance context, not Doku performance claims.
02 / The repayment asset
Installed GPUs are not the repayment asset.
Installed GPUs, contracted GPUs, energized capacity, commissioned capacity, deployable compute, utilized compute, reliable workload goodput, and billable customer value are different states. Loss can occur at every transition.
Equipment is physically present.
Power is available to the deployed equipment.
The system has passed defined technical checks.
Capacity can accept the intended workload.
Work is assigned and consuming capacity.
Useful work completes at credible efficiency.
Performance satisfies the customer obligation.
Cash from delivered value supports repayment.
Conceptual underwriting relationship
Useful compute economics = price × deployable capacity × workload efficiency × reliability × billable utilization
This is a conceptual relationship, not a calibrated valuation equation.MFUScaling efficiencyJob goodputFailure ratesCheckpoint lossStragglersWorkload completion timeEffective cost per useful compute
Training evidence emphasizes scaling, step time, checkpoint behavior, and time-to-train. Inference evidence emphasizes throughput, latency, request quality, availability, and cost per completed request.
Credit reader glossaryMFU, goodput, scaling, failure domains, and redeployabilityOpen five plain-language definitions
- MFU
- Model FLOPs utilization: the share of theoretical accelerator compute converted into model work.
- Goodput
- Useful workload progress completed within the required performance and reliability envelope.
- Scaling efficiency
- How much useful performance is retained as a workload expands across more accelerators.
- Failure domain
- A shared dependency whose failure can interrupt multiple nodes, racks, or jobs.
- Redeployability
- The practical ability to move capacity to another customer or workload without destroying economic value.
Two clusters with the same GPU count can have materially different economic capacity.
Technical reference frame: NVIDIA DCGM Diagnostics and NVIDIA NCCL guidance. Transaction conclusions still require workload-specific evidence and accountable review.
03 / Questions the credit file must answer
Can this exact system perform this exact workload economically?
Lenders do not need to operate the cluster. They need an independent layer capable of testing whether technical assumptions are credible, material to repayment, and controllable through the financing.
Eight technical question groupsPower, facility, workload, topology, storage, software, operator, and controlOpen the complete technical underwriting question set
01
Power and electrical
Can the electrical system support the operating case?
- Can the utility or on-site source serve the intended rack density under credible operating and curtailment conditions?
- Do distribution, redundancy, power quality, protection, and transient behavior support the workload?
- Which conclusions remain with the responsible electrical engineer?
02
Facility and thermal
Can the facility sustain the intended compute density?
- Can cooling and heat rejection sustain the intended density through normal and failure modes?
- Are water, ambient, containment, controls, and recovery dependencies reflected in acceptance testing?
- Does facilities-to-workload acceptance prove stable performance rather than installed capacity alone?
03
Workload fit
Can this architecture perform the contracted work?
- Is the workload training, fine-tuning, inference, or HPC?
- Does the architecture match its communication, memory, storage, and latency profile?
- Are acceptance benchmarks representative of the actual workload?
04
Network and topology
Can the GPUs operate as one coherent system?
- What GPU, NVLink, rack, leaf-spine, InfiniBand, or Ethernet topology is deployed?
- What oversubscription and failure domains exist?
- Is placement topology-aware?
- Can the borrower control or remediate the underlying fabric?
05
Storage and data path
Can data movement sustain the intended workload?
- Can storage sustain data loading and checkpoint behavior?
- Are metadata, burst, and recovery paths correctly designed?
- What happens during simultaneous checkpoint or restart events?
06
Operating software
Can software preserve performance under real conditions?
- Is scheduling topology-aware?
- Are health checks, observability, isolation, upgrade controls, and incident response adequate?
- Can telemetry be reconciled to SLA and credit assumptions?
07
Team capability
Can this team diagnose and recover the system?
- Has the team operated comparable distributed workloads?
- Who owns network, storage, orchestration, performance, and customer integration?
- Is expertise concentrated in irreplaceable people?
- Can the team diagnose collective-communication and cross-layer failures?
08
Control and redeployability
What can the borrower control when the case changes?
- Who controls topology, firmware, spares, maintenance, and remediation?
- Is the capacity supplied through third parties?
- Can the cluster be reassigned if the anchor customer leaves?
- What value remains under distressed sale or redeployment?
04 / From topology to credit loss
A technical architecture flaw can migrate directly into debt-service risk.
Illustrative scenario: a borrower finances an 8,000-GPU cluster for large-scale distributed training. The debt case assumes high utilization, competitive performance, and premium pricing. The underlying supplier controls the fabric, replacement process, and physical topology.
Topology mismatchLower goodputWeaker customer economicsPrice pressure or churnLower EBITDAReduced DSCR
The cluster is fragmented across topology and failure domains, with limited borrower remediation rights.
Placement, collective communication, checkpoint recovery, and job reliability underperform the intended workload.
Realized goodput and time-to-train trail competing clusters despite the same nominal GPU count.
The customer demands price concessions, shifts workloads, or declines to renew.
Revenue, gross margin, utilization, EBITDA, and debt-service coverage fall below the approved case.
Require workload-representative testing, topology disclosure, remediation rights, reporting, reserves, milestone conditions, and intervention triggers.
Supplier control, customer concentration, or hardware redeployability may remain unresolved.
Illustrative utilization sensitivity75%underwritten billable utilization
Observed case60%billable utilization
Utilization-linked revenue effect20% lowerbefore pricing, fixed-cost, or recovery effects
Synthetic example and arithmetic only. The 75% and 60% figures are illustrative inputs, not a customer result, forecast, valuation, rating, engineering conclusion, investment recommendation, or representation of an actual financing.
05 / Technical credit product
The output is a lender-usable technical conclusion, not a generic engineering report.
Doku reconstructs the financed system, tests workload and operator fit, and converts technical uncertainty into a reviewable credit action.
5 to 10 business days$25K to $60K indicative
A bounded decision screen for fatal flaws, evidence gaps, workload mismatch, team risk, control risk, and immediate credit action.
- Fatal-flaw questions
- Missing evidence
- Architecture and workload mismatch
- Team and control risks
- Immediate credit actions
2 to 5 weeks$75K to $250K indicative
A cross-layer assessment of the system, workload, operator, acceptance case, downside exposure, and proposed credit protections.
- Architecture and workload-fit analysis
- Team, control-rights, and acceptance-test review
- Technical risk register and downside scenarios
- Conditions, covenants, reserves, and reporting requirements
Milestone or monthly cadenceScope and cadence dependent
Monitor topology changes, deployment, acceptance testing, representative performance, completion evidence, and draw implications.
- Design and topology changes
- Equipment deployment
- Workload-representative acceptance
- Evidence and draw status
Monthly, quarterly, or trigger-basedScope and cadence dependent
Track deployable capacity, goodput, reliability, incidents, customer concentration, hardware competitiveness, and triggers.
- Useful and billable capacity
- Goodput and reliability
- Incidents and remediation
- Covenant and intervention status
A rapid screen can end the process. Assessment or surveillance begins only when the screen identifies a material question and the buyer authorizes a defined scope, evidence set, cadence, and decision.
Illustrative deliverable surfaceTechnical credit decision record
Template only / not customer work / non-relianceDownload the complete sample record
DecisionFunding condition for workload acceptance
StatusConditional
ConfidenceMedium pending evidence
OwnerLender credit
The proposed supplier controls fabric topology, replacement, and remediation. Workload-representative acceptance evidence is incomplete.
Lower goodput or delayed recovery can reduce billable utilization, weaken customer economics, and reduce debt-service headroom.
Condition funding on an accepted workload test, topology disclosure, defined remediation rights, and recurring performance reporting.
Signed acceptance protocol, executed control-rights schedule, test output, accountable reviewer, date, version, and approval.
Rapid screen buyer packetScope lock, participation, acceptance, and procurement pathOpen the full buying and control details
Make the first paid step easy to buy
A bounded rapid screen with an explicit acceptance test.
Final scope and terms are controlled by the accepted proposal. The structure below is the default starting point for a live financing.
One asset or facility, one intended workload, the material technical assumptions, and the lender decision they may change.
A 60-minute kickoff, access to one accountable technical lead, and a 60-minute findings and decision review.
Architecture, topology, workload, acceptance, operating, control-rights, and customer-obligation materials relevant to the scoped questions.
Every in-scope conclusion cites evidence, states confidence and residual risk, and assigns any required action, owner, deadline, and closure evidence.
Typical start path
- 30-minute fit and conflict check
- Confidentiality and evidence-handling terms
- Concise scope, fee, reliance, and acceptance schedule
- Kickoff after written authorization
No automatic expansion. Any deeper assessment requires a separate decision and proposal.
Procurement guardrailsIndependence, reliance, and specialist responsibilityOpen the buyer-control details
The fit review identifies transaction parties, prior work, and material conflicts before a protected evidence request or paid authorization.
Scope, permitted use, reliance, distribution, liability, and acceptance are agreed in writing before a deliverable may be used for a financing decision.
The proposal names any required power, facility, network, storage, cybersecurity, legal, or other specialist and leaves source authority with that responsible expert.
The proposal identifies the contracting party, required insurance evidence, governing terms, and requested assurance materials. Any item not available remains explicitly open.
Indicative only. The accepted proposal controls final scope, timing, fee, evidence, conflicts, permitted use, reliance, liability, acceptance, expenses, and terms.
06 / Credit translation
A technical finding matters only when its financial consequence and decision owner are explicit.
Doku proposes the translation. Lender credit, counsel, and responsible technical experts retain their respective approval and source authority.
EvidenceTechnical factWorkload consequenceCommercial effectFinancial exposureMitigantCredit termResidual risk
Finding-to-action matrixEight example technical findings and credit responsesOpen the complete credit action table
| Technical finding | Potential credit action |
|---|---|
| Workload-unrepresentative benchmark | Require workload-representative acceptance testing |
| Borrower lacks topology control | Require remediation rights, supplier obligations, or reserve |
| Performance depends on one engineer | Require key-person plan, documentation, and operating coverage |
| Supplier topology cannot be changed | Haircut utilization or pricing assumptions |
| Storage path is unvalidated | Condition funding on an accepted performance test |
| Customer workload is not redeployable | Increase concentration and recovery stress |
| Telemetry cannot prove SLA performance | Require reporting and data-access covenant |
| Hardware may become uncompetitive during tenor | Require reinvestment plan or amortization protection |
Technical diligence appendixOperator capability, financing fit, role comparison, method, and evidenceOpen the specialist detail or use a direct section link below.
07 / Operator capability
The same infrastructure can produce different outcomes under different teams.
AI-infrastructure underwriting must evaluate not only the physical assets, but also the organization expected to operate, diagnose, recover, and improve them.
01Architecture ownership
02Distributed-training experience
03Network-fabric expertise
04Storage and checkpoint expertise
05Scheduler and orchestration depth
06Observability and incident response
07Capacity planning
08Customer workload integration
09Operating documentation
10Key-person concentration
11Speed of diagnosis and remediation
12Authority over third-party suppliers
Technical team quality is not a soft diligence item when repayment depends on operating performance.
Minimum operator evidence requestAsk for evidence that shows who can detect, decide, and recover.
- Named owners for network, storage, orchestration, workload performance, and customer integration
- On-call coverage, escalation paths, and recent incident postmortems
- Topology, placement, maintenance, and change-control runbooks
- Workload qualification, acceptance, and performance records
- SLA telemetry mapped to customer and credit assumptions
- Supplier rights, spares, remediation authority, and key-person coverage
Team assessment informs specific operating and control risks. Doku does not claim that a deterministic team score predicts default.
08 / Initial financing wedge
The need is greatest where repayment depends directly on cluster performance.
Technical underwriting has the highest urgency when utilization, customer value, asset control, and recovery depend on an operator’s ability to deliver competitive useful compute.
- 01Neocloud and GPU-cloud private credit
- 02GPU-backed equipment facilities
- 03Distributed-training clusters
- 04Non-investment-grade AI infrastructure tenants
- 05Supplier-aggregated capacity
- 06Emerging AI-lab customer contracts
- 07Partially merchant or utilization-dependent projects
- 08Debt extending beyond the current hardware generation
- 09Refinancing of existing GPU fleets
- 10Structured pools of AI-infrastructure exposure
Conventional hyperscaler build-to-suit transactions may have less urgent need when repayment is overwhelmingly protected by investment-grade tenant credit and contractual support.
09 / Existing diligence stack
Doku adds the missing workload-to-credit layer.
Doku complements engineers, advisers, counsel, lender credit, source systems, and operating tools. It does not claim their authority or replace their conclusions.
| Approach | Primary authority | What it evaluates well | Common stopping point | How Doku connects it to the repayment case |
|---|---|---|---|---|
| Owner's engineer | Design and technical source conclusions | Facility, systems, testing, and completion | Workload economics and lender-owned credit action | Reconciles accepted engineering facts to workload performance and the credit case |
| Data-center engineering consultant | Licensed or specialist engineering scope | Physical design, capacity, resilience, and commissioning | Cross-layer cluster performance and repayment consequences | Connects facility conclusions to useful compute, customer value, and credit protections |
| Transaction or Big Four diligence | Broad transaction workstream | Commercial, financial, operational, and process review | Persistent evidence-to-workload-to-credit lineage | Builds an inspectable chain from technical evidence to lender action |
| Credit underwriting | Lender decision authority | Borrower, structure, cash flow, collateral, and terms | Independent deep technical reconstruction of AI system performance | Tests the technical assumptions while lender credit retains approval authority |
| Rating agency | Issuer or instrument credit opinion | Public rating analysis and surveillance | Private evidence workflow and lender-owned technical action | Supports private transaction decisions without issuing a public rating |
| DCIM and telemetry | Observed operating state | Facility, equipment, capacity, alarms, and telemetry | Workload context, customer economics, and accountable credit disposition | Interprets operating data against workload, revenue, and covenant assumptions |
| Project controls | Schedule, cost, progress, and change | Delivery status and project-control discipline | Useful-compute consequence, revenue effect, and debt response | Translates delivery changes into technical capacity and repayment impact |
| Doku | Technical credit synthesis | Whether accepted physical and operating facts support workload performance | Does not replace source engineering, counsel, or lender credit | Connects useful compute to customer economics, cash flow, terms, and surveillance |
Doku evaluates whether the accepted physical and operating facts jointly support the workload performance, customer economics, cash flow, and credit protections assumed by the financing.
10 / Review method
Every conclusion must be inspectable, challengeable, and owned.
Doku’s method is a technical credit synthesis. It preserves source authority, exposes uncertainty, and keeps approval with accountable decision owners.
- 01Define the financing decision
Name the exposure, timing, threshold, and accountable decision owner.
- 02Inventory and rank evidence
Preserve source authority, date, version, provenance, confidence, and gaps.
- 03Reconstruct the technical system
Connect power, cooling, topology, storage, compute, software, and control.
- 04Test workload and operating fit
Evaluate representative performance, goodput, reliability, team, and remediation.
- 05Trace financial consequences
Connect technical outcomes to customer value, cash flow, collateral, and recovery.
- 06Propose action and surveillance
Define mitigants, credit terms, indicators, owners, closure evidence, and residual risk.
Evidence authority
A conclusion cannot outrank the evidence allowed to support it.
- 01Executed agreement or official record
- 02Official letter, certification, or accepted test
- 03Responsible expert model or report
- 04Source-system extract or telemetry
- 05Management assertion or working assumption
Confidentiality and AI use
Evidence transfer, access, retention, permitted AI use, export, and deletion are defined before restricted evidence is accepted.
Authority and reliance
Public materials are non-reliance. The proposal controls scope, use, reliance, liability, acceptance, and accountable specialists.
Claim boundary
Doku does not claim a public rating, investment recommendation, stamped engineering, legal advice, replacement of licensed technical specialists, calibration against a complete default dataset, predictive performance, or unsupported customer outcome.
Founder-led delivery
Jorg Doku, Former Head of ML at RunPod, has prior AI work at Google Brain and Meta AI Research. Delivery connects neocloud operations, ML infrastructure, distributed systems, performance, reliability, and evidence interpretation.
Delivery accountability
Founder-led, with source authority left where it belongs.
Jorg leads the technical-credit synthesis, evidence lineage, and lender readout. The accepted proposal names any required network, storage, facility, power, cybersecurity, legal, or other accountable specialist before restricted evidence is accepted.
Review founder background- Doku owns
- Cross-layer reconstruction, workload-to-credit translation, evidence lineage, uncertainty, and the decision record.
- Specialists own
- Their licensed, certified, legal, or domain-specific source conclusions when the scope requires them.
- Lender credit owns
- Approval, structure, pricing, covenants, exceptions, reliance, and the final financing decision.
Current proof status
Founder-led delivery and proposal-scoped accountable specialists. No customer logo, testimonial, reference, endorsement, completed transaction outcome, or predictive-performance claim is made. Lender credit retains decision authority, and technical specialists retain authority for their source conclusions.
Selected public evidence
These sources support market scale, financing context, acceptance logic, and infrastructure standards. Doku’s underwriting architecture remains Doku’s synthesis.
Source register reviewed July 24, 2026. Re-review occurs quarterly and before any proposal-controlled reliance.Market scaleMcKinsey
The cost of compute: A $7 trillion race to scale data centers
Market scale and capital intensityCredit activityS&P GlobalBanks meeting data-center demand with credit facilities and bonds
Financing activity and transaction contextAcceptance evidenceU.S. SECCoreWeave credit agreement, Exhibit 10.1, March 30, 2026
Documented financing and acceptance structureTranche financingU.S. SECIREN financing agreements disclosure, Form 8-K, May 29, 2026
Public financing structure and tranche contextNetwork standardIEEEIEEE 802.3 Ethernet standard
Network source authorityThermal evidenceASHRAEData-center energy, thermal, and high-density cooling resources
Thermal and facility source authorityGPU diagnosticsNVIDIA DCGMDCGM Diagnostics
Cluster readiness, health, topology, and diagnostics evidenceCollective communicationNVIDIA NCCLNCCL troubleshooting and performance guidance
Fabric, topology, multi-node, and performance evidenceLive technical underwriting review
Bring the financing whose repayment still depends on an unresolved technical assumption.
Start with one asset, one intended workload, one unresolved technical concern, and the credit decision it may change. No data room is required for the first conversation.
First review outcomeA fit decision, the smallest evidence request, the responsible expert boundary, and a scoped next step.
What happens next
Four controlled steps from first contact to authorized work.
Download the engagement protocol- 01NowFirst contact
Share high-level financing context only. No project files or restricted evidence.
- 02Within two business daysFounder fit response
Receive a direct fit or no-fit answer, the decision Doku can support, and the smallest useful evidence request.
- 03Before any restricted evidencePre-evidence control lock
Agree the contracting party, conflicts, specialists, reliance, liability, insurance evidence, transfer, access, retention, AI use, and deletion.
- 04Before paid work beginsWritten authorization
Accept scope, fee, timing, evidence, participation, decision record, and acceptance standard. No automatic expansion.
Before restricted evidenceVerify the delivery boundary, buying path, and current proof status.Open the public engagement-readiness register
Available for review now
Method, artifacts, security boundary, and founder- 96-source register and versioned method log
- Illustrative decision record and committee brief
- Public security review and restricted-evidence boundary
- Direct founder background and contact path
Agreed before evidence
Contracting, reliance, specialists, and handling- Contracting party, conflicts, scope, fee, and acceptance
- Confidentiality, transfer, retention, AI use, and deletion
- Permitted use, reliance, liability, and insurance evidence
- Named specialists required by the accepted evidence scope
Not claimed by implication
Customer proof and assurance remain explicit- No customer logo, testimonial, or reference is claimed
- No completed transaction outcome is represented
- No calibrated default prediction is represented
- No SOC 2, ISO 27001, or similar assurance is claimed
High-level financing briefPrepare a technical underwriting requestSeven high-level fields, no project files required
No. Doku preserves engineering source authority and tests how the accepted facts affect workload performance and the credit case.
No. The fit review uses high-level context. Restricted evidence is requested only after scope and handling terms are agreed.
The output records the no-expansion conclusion and remaining evidence limits. A larger engagement is never automatic.
The decision record is designed around evidence, financial consequence, proposed action, owner, closure, and residual risk.