Re-Certify Your AI Workflow When The Business Rules Change.

An AI workflow can pass every test on Monday and become wrong on Friday without the model changing at all. A supplier revises a lead-time rule. The company raises its deposit requirement. A warranty exclusion changes. A new project manager gets approval authority. The workflow keeps running exactly as designed—against yesterday's business.

OpenAI's production-agent guidance says agent behavior has to adapt as products, policies, and user behavior change. It describes testing proposed updates against the production version before a controlled rollout. The Datum interpretation is practical: launch approval is temporary. Every important AI workflow needs written conditions that force it back through review when the operating truth beneath it changes.

Separate A Software Change From A Business-Rule Change

Teams usually think to retest when a model, prompt, or integration changes. They are less likely to retest when the business changes around a stable system. Yet the second category can be more dangerous because the workflow still looks healthy. It runs on schedule, reads the expected files, and produces polished output. Only the decision rule is stale.

List the rules the workflow depends on: price-book effective dates, markup bands, approved vendors, contract language, client promises, permit requirements, selection statuses, purchasing thresholds, scheduling buffers, warranty terms, escalation paths, and role permissions. If one of those inputs changes, the workflow may need re-certification even when no code changed.

Create A Trigger Register

• Trigger: the exact change that starts review, such as a new price book, revised contract template, policy effective date, or role-permission update.
• Affected workflow: the named automation, agent, report, or drafting process that relies on the changed rule.
• Owner: the person accountable for declaring whether the workflow remains approved.
• Required tests: the smallest representative cases that prove the new rule is applied and the old rule is no longer used.
• Interim state: paused, draft-only, human-review-required, or approved with a documented limitation.
• Evidence: the source document, effective date, test results, reviewer, and approved workflow version.

Keep the register attached to the workflow, not buried in an AI governance folder. The estimator updating a price table or the office manager revising an approval policy should be able to see immediately which automated work depends on that change.

Use Effective Dates As Control Points

A building business often has overlapping truths. A new pricing rule may apply to estimates created after September 1 while signed projects remain under the prior contract. A discontinued product may still be valid for jobs with confirmed inventory. A new warranty term may apply only to future installations. Re-certification must test the date and project conditions that select the correct rule.

Do not overwrite the old source and hope the agent infers the boundary. Version the rule, record when it takes effect, identify which records remain governed by the prior version, and make the workflow cite the rule version it used. A reviewer should be able to reconstruct why the output was correct on the day it ran.

Re-Test The Decisions, Not Just The Prompt

OpenAI describes simulations and graders that check outcomes, policy following, tool use, and escalation. Anthropic's trustworthy-agent guidance likewise emphasizes evaluation across the full system rather than confidence in a model alone. For a small building business, the useful version is a compact regression packet built from real jobs.

• A normal case that should pass under the new rule.
• A boundary case immediately before or after the effective date.
• A legacy project that must remain under the old rule.
• An incomplete record where the workflow should ask or escalate instead of guessing.
• A high-consequence case involving price, scope, schedule, compliance, customer commitment, or payment.
• A known prior failure that must stay fixed after the update.

Compare the new version with the approved production version. Review every changed decision, not merely whether the output sounds better. A wording improvement can hide a new pricing error; a correct summary can still route approval to the wrong person.

Choose A Safe Interim State

Not every rule change should stop the entire operation. Match the restriction to the risk. A marketing draft may continue with mandatory review. An estimate checker may be limited to flagging discrepancies without approving them. A client-message agent may prepare drafts but lose send permission. A purchase workflow using an uncertain price or availability rule should pause the affected action until a person resolves it.

Make the restricted state visible in the queue and logs. The worst interim state is silent uncertainty: the team assumes the workflow is approved while its owner assumes everyone knows it is under review.

Record The Approval Like A Job Decision

A re-certification record should name the changed rule, affected workflow, source of truth, test packet, results, exceptions, reviewer, approval date, and next review trigger. Preserve the prior version. If a bad output appears later, the business needs to know whether the workflow used an incorrect rule, selected the wrong version, or violated a correct rule.

Track production exceptions after approval. OpenAI's guidance treats sessions, escalations, and quality signals as inputs to post-launch improvement. Do the same locally: if people repeatedly override the same decision, either the rule, the data, or the test packet is incomplete. Route that pattern back into the next certification cycle.

Publish The Rules Customers Actually Need

Google says AI Overviews and AI Mode do not require special AI-only schema. Helpful, original, crawlable content and accurate structured data remain the foundation. When a business rule affects buyers—service boundaries, selection deadlines, lead-time assumptions, warranty coverage, or what happens after approval—publish the current rule in plain language with its scope and date. That first-party operating detail is more useful than a generic trend summary and gives both customers and search systems a reliable source.

The Datum Rule

Do not treat an AI workflow as permanently approved. Name the business rules it depends on, register the changes that trigger review, version effective dates, replay real decision cases, and restrict the workflow until a responsible operator signs off. The system is trustworthy only while its tests remain attached to the way the business actually works.

Build The Change-Control Layer

• Every AI Workflow Needs A Punch List
• Your AI Workflow Needs An Exit Plan
• Explore practical AI paths for your team

Next step, if this note maps to a problem on your desk: Book Private Training.