An architecture review can sound decisive even when the underlying evidence is thin. A demo completes, two AI agents agree, or a vendor benchmark shows improvement. Someone concludes that the system is production-ready. But agreement and activity do not resolve the questions a platform leader must actually answer: what was tested, which constraints apply, and which claims remain uncertain?
The useful discipline is to label each consequential claim before it shapes a purchase, deployment, operating policy, or delegation of authority. I use four categories: verified fact, inference, hypothesis, and unknown. They are not rankings of people’s confidence. They are different types of statements that require different evidence and different next actions.
Four claims that sound similar but mean different things
VERIFIED FACT — A statement supported by directly relevant, inspectable evidence within a specified scope and time. Example: “In the recorded pilot, the agent produced a draft, the destination returned an object ID, and an independent readback confirmed the expected draft status.” This establishes an outcome for that run. It does not establish that the service will succeed across every account, workload, or failure condition.
INFERENCE — A conclusion reasoned from facts, assumptions, and a model of how the system behaves. Example: “Because the failed requests share a permission-denied response, the missing credential scope is probably the immediate blocker.” That may be a strong explanation, but it should remain distinguishable from a directly observed root cause until tested.
HYPOTHESIS — A proposed explanation or intervention that can be falsified. Example: “Routing the accepted document revision through one deterministic serializer will reduce mismatch failures.” A useful hypothesis names the intervention, expected measurement, comparison baseline, and the observation that would disprove it.
UNKNOWN — An important answer that the available evidence cannot yet support. Example: “Will the deployment recover correctly when the provider returns a timeout after the remote write succeeds?” Unknown does not mean zero, safe, or failed. It means the decision needs more evidence, a narrow assumption, or a smaller initial commitment.
Why this distinction changes architecture decisions
A system may pass functional tests while failing an operational requirement. Its outputs may be accurate in controlled examples yet become unreliable when tools, context windows, connectors, approvals, or retries change. A database property can also report a successful state while its linked document or destination has not actually reached that state. The architecture assessment therefore needs both claim strength and source-of-truth verification.
NIST’s AI Risk Management Framework organizes risk-management activities around Govern, Map, Measure, and Manage. Its Measure function includes assessment, benchmarking, ongoing monitoring, and attention to uncertainty and independent review. The NIST AI Resource Center offers guidance for testing, evaluation, verification, and validation; the framework is voluntary and its first version is being revised. These are reasons to build repeatable evidence practices, not a universal certification that any individual AI system is safe.
Current OpenAI agent-evaluation guidance likewise distinguishes inspecting workflow traces from running repeatable evaluations. A trace can help diagnose tool selection, handoffs, and guardrail behavior for a specific execution; datasets and evaluation runs help reveal whether a change improves performance across cases. Neither should be described as proof of broader business value without an outcome measure connected to the actual work.
An example: the successful AI-agent demo
Imagine a research assistant that gathers public evidence, drafts an architecture recommendation, and files a completion message. A stakeholder announces that the agent has completed the research process autonomously. The completion message is a fact about messaging only if the record is authentic. Whether the report exists, cites valid sources, was saved to the correct workspace, and meets the requester’s acceptance conditions are separate propositions that must be checked.
The stronger evidence packet includes the original request and expected deliverable; permitted sources and run identity; an actual editable report; a source/claim ledger; evidence of the destination write; independent readback of the document and task status; and owner acceptance. A timeout, stale document, duplicate retry, missing permission, or empty scan must not be silently counted as verified completion.
This does not require a committee for every paragraph. Low-risk drafting can move quickly. The verification effort should scale with the impact and reversibility of the decision. An internal draft can be revised. A public claim, customer commitment, credential change, or high-impact autonomous action needs stronger evidence and a separately admitted authority.
A five-question evidence review
Before approving a proposed architecture change, ask: (1) What exact claim are we making? (2) Which source or test directly supports it, and when was it observed? (3) What are we inferring beyond that evidence? (4) Which alternative explanation or failure case have we not tested? (5) What result would make us reverse the decision?
When these answers are preserved beside the actual living report, they remain usable for a weekly review, a later customer discussion, a technical article, or a future agent. When the evidence exists only as a task status or an isolated chat response, teams tend to reconstruct it—often losing the assumptions that mattered most.
Architecture discipline means being able to say “we know,” “we infer,” “we predict,” and “we have not tested” without confusing those statements. That is how experimentation becomes cumulative rather than a series of persuasive demonstrations.
Subscribe to Decision Crafters for practical, evidence-grounded notes on measuring AI systems before their complexity outpaces their value.