Create a claims register
Extract material claims about performance, security boundaries, compatibility, decentralisation, and upgradeability. Assign the evidence needed for each.
The register prevents a polished demonstration from setting the entire diligence agenda and preserves unresolved questions.
Rank the evidence
A paper describes intent. Code shows implementation. Deployments and logs reveal operation. Incident records show recovery under pressure.
An external audit is one rung. Its scope, reviewed version, unresolved findings, and subsequent changes determine what it supports.
Inspect the human system
Key-person concentration, release discipline, privileged access, and incident communication are technical risks expressed through people.
Ask who can alter the system, who reviews a release, and how the team handles a failure it cannot immediately reproduce.
Follow one failed path through recovery
A prepared demonstration follows the route the team knows best. I also want to see a controlled failure such as insufficient permission, an unavailable dependency, an unconfirmed transaction, or an incompatible version.
The useful evidence is the trail: whether the system identifies the fault, who takes ownership, how state is retried or restored, and whether reconciliation finishes. Another clean success path would reveal less.
Preserve confidence levels
A single technology score removes useful information. Separate verified, partly verified, externally dependent, and unknown claims.
The investment view depends on that distribution—and on how effectively the team reduces material unknowns.