The Discipline of Facts in AI Product Delivery: No Invented Feature Lists, No Catch-All Triads

1. Distortion Begins in the Description

AI product delivery rarely fails first at the model. It fails in the description. A system that works in engineering gets written up with capabilities it does not have; commitments that engineering cannot keep get printed on covers and in proposals. By acceptance time, the two sides no longer mean the same thing by "launched."

Such distortion is seldom malicious. It comes from three habits:

• Filling gaps with imagination. The feature list is not copied from the system; it is reverse-engineered from what users might want. Items on the roadmap quietly shift into the present tense in the document.
• Substituting templates for judgment. A few catch-all triads circulate in the industry — smart Q&A, knowledge base, data analytics, or some similar combination. They appear to cover most needs while defining no boundary of responsibility.
• Letting the cover run ahead. Marketing materials adopt wording the body text has not yet confirmed, and the body text never catches up.

2. The Single Source of Truth: The Repository and the Main Flow

To make descriptions trustworthy, you must first decide what counts as evidence. In AI products, only two places carry both fact and causality.

The engineering repository. Code, configuration, interface definitions, test cases, change records — these determine what the system can actually do, and under what conditions. A repository does not change its behavior because the market wants it to.

The main flow. The shortest path a user takes from entry to result. It determines what the user actually experiences: how many steps, how long the wait, how much human involvement, what they see when it fails.

The intersection of the two is the deliverable capability boundary. Anything outside that intersection — whether implemented but not wired into the main flow, or required by the main flow but not yet stable — should be treated as not delivered, not as supported.

The rule looks plain, and it immediately dissolves a large share of the "capabilities" written into proposals.

3. Six Tests for a Verifiable Capability Statement

1. Reproducible. Every capability statement should map to a repeatable path or test case. If you cannot write the path, it is a wish, not a capability.
2. Conditions in the same sentence. Not merely "supports document parsing," but the data formats, file size limits, language range, and whether human review is required. "Support" without conditions cannot be judged true or false at acceptance.
3. Four states, never merged. "Supported / Supported with limits / Experimental / Planned" are four different facts. They should not be flattened into one word because the layout looks better.
4. Adjectives stay out of the capability list. "Powerful," "intelligent," "leading" cannot be falsified, so they cannot be verified. They belong to brand language, not to a capability list.
5. Describe failure behavior. What happens when the model is unavailable, retrieval returns nothing, input exceeds limits, or concurrency spikes: an error, a degradation, or a handoff to a human? Failure paths are part of the product, not an appendix.
6. Boundaries matter as much as capabilities. A capability list that says only what it can do is structurally incomplete, because it shifts the cost of judgment onto the customer.

4. The Real Cost of the Catch-All Triad

The triad is popular because it is the cheapest thing to say in a sales conversation: you can give an apparently complete answer without understanding the customer's actual process.

The cost is threefold:

• It erases differentiation. What separates two AI products is usually not the category name but the constraints, the error handling, and the place of the human in the loop.
• It manufactures acceptance disputes. When both sides believe they mean the same thing, the triad becomes a container for talking past each other.
• It leaves judgment nowhere to live. The vendor no longer needs to judge whether the customer's scenario fits; the customer no longer needs to judge whether their data and process are ready.

The replacement is not complicated: describe scenario slices instead of listing categories. Rather than "we have smart Q&A," write: "for questions of type X, over documents of type Y, a user can reach a cited answer within Z steps; when sources are insufficient, the system returns empty and prompts for more input." The first cannot be accepted; the second can.

5. The Marketing Cover Must Be Accurate

The cover is the smallest unit of commitment, and the easiest place to inflate. Three spots fail most often:

• The headline. Words like "fully automatic" or "one click" delete every conditional clause. It is not forbidden to use them, but if you do, the body must supply the corresponding conditions.
• The diagram. Every extra box on a flow chart is an undelivered promise. A diagram should describe the implemented main flow, not the ideal one.
• The numbers. Any accuracy rate, efficiency gain, or cost reduction must be traceable: which evaluation, which dataset, which definition. A number you cannot trace is better left unwritten.

Consistency checking belongs in the release process: every sentence on the cover should be traceable to the body text or to an engineering record.

6. Turning Factual Discipline into a Process

Individual rigor does not scale; process does. A few concrete measures:

• Three lists travel with delivery. Capabilities (supported), boundaries (supported with limits), and non-goals (explicitly not done). The third matters most and is most often omitted.
• Changes bound to versions. A shift in capability status must map to a version number and a date, so old documents stop circulating as current.
• Cross-role review. Engineering confirms feasibility, product confirms alignment with the main flow, delivery confirms the customer can understand it. If any role cannot explain it, it does not get written yet.
• State what is not done, up front. Explaining at acceptance is worse than aligning at the start. Being explicit about boundaries may cost some signings in the short run and saves rework in the long run.

Closing

Factual discipline sounds like self-restraint. It is actually a choice about efficiency. The cost of distorted descriptions always returns to the vendor — as rework, disputes, and eroded trust.

Judgment precedes expression. What to write and what not to write is a judgment that must be made before the first sentence — and its basis should be facts that can be examined: the repository and the main flow.