Field Notes · Technical Diligence August 21, 2026 · 6 min read

A technical claim is not evidence.

Secure, scalable, private, zero trust, AI-powered, enterprise ready, compliant. Each of these is a proposition wearing the costume of a fact. Organizations sign contracts, approve architectures, and price acquisitions on such labels, and the labels survive because nobody converts them into statements precise enough to be false. This note describes the conversion: what each common label actually asserts, the hierarchy of evidence that can support it, one question that does most of the testing work, and why a vendor's refusal to warrant a claim is itself information.

Labels are compressed propositions

A technical label is a compression. "Secure" compresses a set of claims about threat models, controls, and verification into one word. Compression is not deception; specialists use these words with each other and silently decompress them from context. The failure occurs at the boundary where the word crosses from specialists to decision-makers: the buyer hears the compressed form, cannot perform the decompression, and treats the word as a property the product simply has, like a color. At that moment a proposition that was never tested enters a contract, a budget, or a board deck as a fact.

The corrective is to decompress deliberately. Every load-bearing label in a proposal or data room should be expanded into the specific statements it asserts, because only specific statements can be checked. What that expansion looks like differs by label:

• "Secure" asserts: against a particular threat model, specific controls exist, and someone has verified they work. Decompressed questions: secure against what? Verified by whom, when, and with what scope? What did the last assessment actually examine, and what did it find?
• "Scalable" asserts: a defined dimension of load can grow to a defined level, at a cost curve someone has measured. Decompressed: which dimension (users, transactions, data volume, concurrency)? Demonstrated at what level, or extrapolated from what? What is the cost per unit at 10x current load, and is that number measured or hoped?
• "Private" asserts a custody and flow model: where data lives, who processes it, which subprocessors see it, what telemetry leaves. Decompressed: does "your data is never used for training" also cover the vendor's subprocessors, support tooling, and diagnostic telemetry? Under what agreement, with what audit right?
• "Zero trust" asserts an architecture: per-request authentication and authorization based on identity and context rather than network location. Decompressed: which resources are actually behind identity-aware enforcement, and which still trust the network segment? A rebranded VPN concentrator and a per-request authorization architecture both ship under this label.
• "AI-powered" asserts that a model materially performs some function. Decompressed: which function, with what model, owned or rented? What is the failure behavior when the model is wrong, and who bears it? What in the product stops working if the model API disappears?
• "Compliant" or "certified" asserts an artifact with a scope and a period, which is the subject of its own note: the label is only as strong as the boundary of the underlying examination.

The hierarchy of evidence for a claim

Once decompressed, each statement can be placed against the evidence available for it, and the kinds of evidence are not equal. In descending order of strength:

1. Independent verification. A qualified party with no stake tested the specific claim: an assessment whose scope covers the statement at issue, read in full rather than by its cover letter.
2. Direct observation. You, or someone acting for you, watched the claim be true: a load test you specified, a configuration you inspected, a data flow you traced.
3. Operational artifacts. Records produced by the system's normal functioning, not assembled for you: real utilization data, real incident history, real audit logs. Artifacts can be curated, but they are harder to conjure than documents.
4. Documentation. Architecture papers, whitepapers, policies. These state intent and design. Their evidentiary weight is real and modest: they establish what the vendor says, in a form more specific than the label.
5. Assertion. The claim itself, restated with confidence. The bottom of the hierarchy, and the level at which most consequential technical claims are actually accepted.

The practical discipline is matching: a claim carrying material cost or risk should be supported at a level of the hierarchy proportional to what it carries. No decision-maker needs level-one evidence for every statement in a proposal. The failure pattern is specific: seven-figure commitments resting on level five.

The question that does the work

Most of the testing compresses into one question, asked of each material claim: what would we expect to observe if this were true, and may we observe it? The question is powerful for two reasons. First, it converts an argument about words into a request for something concrete: a test, a configuration view, a traced data flow, a report with the scope pages included. Second, the response is informative regardless of its content. A vendor who can say "here is exactly what you would see, and here is how to see it" has, at minimum, thought about the claim as an operational reality. A vendor who responds to the request with offense, deflection to the label ("as a zero-trust platform, we..."), or an NDA-walled document that restates the assertion has told you where on the evidence hierarchy the claim actually lives.

There is a contractual corollary. Claims can be converted into warranties, service levels, and termination rights, which moves the cost of falsity from the buyer to the seller. A vendor's willingness to warrant a claim is a price signal about their own confidence in it. Declining to warrant what the marketing asserts is not proof of falsity; sales and legal are different departments with different incentives. But the gap between what is claimed and what will be warranted is a measurement, and it is available to any buyer who asks for both numbers.

Boundary conditions

Two honest limits. First, vendors cannot expose everything: multi-tenant security details, other customers' data, and genuinely proprietary mechanisms justify some opacity. The legitimate substitutes are the middle of the hierarchy: independent assessments with readable scope, contractual commitments, and observation under NDA. Opacity plus refusal of all substitutes is a different posture than opacity plus a credible substitute, and the two should be priced differently. Second, testing costs time and goodwill, and not every claim deserves it. The materiality filter is the same one used elsewhere in this corpus: decompress and test the claims whose falsity would change the price, the architecture, or the risk the organization is accepting. Let the brochure keep its adjectives; audit the ones the money is resting on.

Conclusion

Labels are how technical properties are marketed, and propositions are what they actually are. The gap between the two is where expensive surprises live: the "scalable" platform with an unmeasured cost curve, the "private" deployment with telemetry nobody mentioned, the "proprietary AI" that is three API calls in a coat. The discipline is not cynicism about vendors; it is grammar. Decompress the label into statements, place each statement against the evidence hierarchy, ask what you would observe if it were true, and put the claims that matter into words the contract can enforce. Whatever survives that process is no longer a claim. It is what you actually bought.

Related: Technical Due Diligence Should Test the Investment Thesis, Not Merely the Technology, on applying this discipline when the claims are priced into an acquisition.

← All Field Notes