Why AI Workflows Need Facts, Rules, Exceptions and Evidence

Four layers solve different problems

Facts answer what is true now. Rules state what must happen. Exceptions explain when the rule changes. Evidence shows why the workflow should trust a fact or recommendation. Combining them into one unlabelled block makes conflicts difficult to detect and review.

For example, "use the standard renewal price" is a rule. "This client has an approved enterprise exception until September" changes it. The signed approval is evidence. The client's current plan and renewal date are facts.

Facts must be current and scoped

An AI workflow should know which client, project, period and version it is operating on. Facts need source, freshness and ownership where errors matter. Retrieval based only on textual similarity may return a relevant-looking but outdated document, so the workflow must also filter by status, date and relationship.

Rules should be explicit enough to test

Rules hidden in examples or team memory are difficult for both people and AI. Express the decision condition, required input and permitted output. When rules conflict, define precedence or escalate. Do not ask a model to invent policy from historical behavior.

Rules can live in structured configuration, validated instructions or deterministic code depending on risk. The important point is that a reviewer can see what governed the action.

Exceptions are part of the workflow, not noise

Service operations contain rush requests, missing data, unusual contracts, sensitive clients and one-off approvals. A design that works only for the happy path pushes the hardest cases onto people without a clear queue or context handoff.

List common exception classes during workflow mapping. Decide which can follow a separate rule, which require human review and which should stop execution entirely.

Evidence makes review efficient

Evidence should sit beside the claim or decision it supports. A reviewer should not need to search a folder to verify a figure. Include source identity, relevant excerpt or field, timestamp and confidence or status where appropriate.

Evidence also supports correction. When a source is wrong, the team can fix the fact or rule rather than repeatedly editing generated output.

Illustrative workflow control

Illustrative example—not a client result. A proposal assistant may draft a scope only when the service facts are current, pricing rules are available, contract exceptions are checked and each commercial claim points to an approved source. If the client's exception status is unknown, the workflow creates a review task instead of completing the proposal.

Define a fail-closed decision boundary

For each action, decide what happens when context is incomplete. Low-risk reversible actions may proceed with logging. Client-facing, financial, legal or difficult-to-reverse actions may require approval. Missing required evidence should never be treated as permission.