3  AI-first workflow for business rules

Tip

An AI-first workflow turns business rules into continuous, evidence-backed checks while keeping accountable decisions with people.

Clinical teams rely on business rules to produce consistent work across studies, tools, and programmers. The rules may govern derivations, naming, rounding, display conventions, or escalation. A rule is useful only when the team can tell where it applies, whether it was followed, and who decides an exception.

This chapter builds one small workflow for clinical analysis and reporting. When project code changes, the workflow checks three rules for numeric rounding and display precision. The example is intentionally narrow, but the design can be reused for other organizational rules.

3.1 Why business rules need active enforcement

Business rules translate an organization’s policies, standards, and experience into repeatable constraints on how work is done. Many never appear in a protocol or SAP. They live in standards documents, review comments, and the memory of experienced colleagues.

Manual review is therefore fragile. It depends on the right reviewer noticing the right detail at the right time. As code moves between projects and languages, an unstated convention can quietly become several different implementations. An AI-first workflow makes the rule available at the moment of change, checks what can be checked mechanically, and brings unresolved edge cases to the subject matter expert for a decision.

3.1.1 Rounding exposes the problem

Numeric rounding looks universal, but common programming tools disagree at exact ties:

Language or tool	Default tie behavior	-2.5	2.5
SAS ROUND()	half away from zero	-3	3
R round()	half to even	-2	2
Python round()	half to even	-2	2

Display adds a separate choice. The values 76, 76.0, and 76.00 are numerically equal, but they communicate different precision in a table. A program can therefore calculate the expected number and still produce an output that violates the organization’s reporting convention.

The lesson is not that one language is correct. A language default is an implementation choice, not organizational policy. The workflow needs an explicit rule that applies independently of the tool used to implement it.

3.2 Define rules that can be enforced

An organization must define the method, the point in the calculation when it applies, and the required display. For this example, suppose it adopts three rules:

Business rule 1: Exact decimal ties are rounded half away from zero.

Business rule 2: Calculations use unrounded values; rounding occurs once, when the final result is prepared for display.

Business rule 3: Display precision is specified for each reported statistic and preserved, including trailing zeros.

Together, the rules form one reporting contract:

Rule	What it prevents	Evidence needed
Tie method	Tool defaults changing a result	Boundary-test results and the formatter used
Rounding stage	Double or intermediate rounding	The calculation path from source value to display
Display precision	Suppressed or inconsistent decimals	The precision specification and rendered output

Store the contract as a versioned artifact that both people and tools can read. The format is less important than the content. The business rules need an owner, scope, version history, and examples that determine the expected result. If a rule cannot determine an answer, the first workflow finding should be a request to clarify the rule.

3.3 Design the workflow around one change

The workflow starts when project source code changes. Keeping one trigger makes each finding easy to explain: this change, at this location, conflicts with this rule.

Figure 3.1: A project code change triggers deterministic checks followed by a focused AI review. Findings go to a human reviewer, whose decisions are recorded and may lead to an approved rule update.

The workflow has five steps:

Step	Action	Owner
1. Trigger	Identify the changed files and affected outputs	Version-control system
2. Load context	Read the current rule contract and prior approved decisions	Workflow
3. Check	Scan call sites, run boundary tests, and compare rendered output	Deterministic tools
4. Interpret	Trace data flow and explain cases the checks cannot settle	AI agent
5. Decide	Accept, reject, or request a change; record the reason	Accountable reviewer

Two design choices matter. Deterministic checks run before the model, because repeatable facts should not depend on model judgment. The human reviewer acts last, because an agent can prepare evidence but cannot approve an exception or change organizational policy.

3.3.1 Walk through one code change

Suppose a programmer adds this code while preparing a mean change from baseline:

subject_change <- round(adam$CHG, 1)
mean_change <- mean(subject_change, na.rm = TRUE)
display_mean <- as.character(mean_change)

The workflow evaluates the change against all three rules:

Rule	Finding
1	round() uses R’s default tie method rather than the approved method.
2	Subject-level values are rounded before the mean is calculated.
3	as.character() does not apply the specified precision or preserve trailing zeros.

A source scanner can locate round() and as.character(). Boundary tests can show the tie behavior, and an output comparison can detect lost zeros. The AI agent adds value by tracing subject_change into mean_change and explaining that the first rounding occurs before aggregation.

A compliant implementation should keep the values unrounded and route the final statistic through an organization-approved formatter:

mean_change <- mean(adam$CHG, na.rm = TRUE)
display_mean <- format_org_number(mean_change)

Here, format_org_number() represents a validated helper that implements the rule contract. Centralizing the convention reduces the number of places the workflow must monitor.

3.3.2 Return a finding, not an essay

Each finding should be a small record that a reviewer can verify and close:

id: BR-NUM-001-0042
rule: BR-NUM-001.2
location: R/table-change.R:18
observed: subject values are rounded before the mean is calculated
evidence: subject_change flows into mean_change on line 19
status: needs_review
owner: statistical-programming-lead
question: Should the intermediate rounding be removed?

Use a CI failure only when a deterministic check proves a violation. Use a code review comment or task when interpretation is required. Every run should also report its coverage: files checked, outputs compared, and anything it could not resolve. Silence must not be interpreted as proof that every rule was checked.

3.4 Build the minimum viable workflow

A team can pilot this pattern without building a large agent platform:

1. Choose one rule and one trigger. Name the rule owner and limit the first workflow to project code changes.
2. Write executable examples. Include positive and negative ties, intermediate rounding, and trailing-zero expectations.
3. Automate repeatable checks. Run source scans, boundary tests, and output comparisons in CI.
4. Use AI only for the remainder. Give the agent the changed code, rule contract, test results, and prior approved decisions. Require locations, evidence, uncertainty, and a question for the reviewer.
5. Record the human decision. Preserve the resolution with the code commit, rule version, check version, and reviewer. Repeated questions may justify a human-approved rule update.

Start by running the workflow in advisory mode. Review false positives, missed cases, and coverage reports before allowing any deterministic check to block a change. Model-generated findings should remain advisory unless a human converts the underlying condition into an approved deterministic rule.

3.5 Know the boundary

This workflow is intentionally limited:

• It reacts to project code changes. Dependency updates, specification changes, and data refreshes need their own triggers and checks.
• It enforces an organizational convention; it does not validate the statistical method or replace independent QC.
• It can identify missing or ambiguous policy, but only the rule owner can resolve it.
• It must run inside an approved environment when code or data are confidential.

These limits are part of the result. A trustworthy workflow says what it checked, what it did not check, and who must decide what remains.

3.6 Summary

Business rules become practical when they are explicit, versioned, testable, and connected to a trigger. For each rule:

1. use deterministic tools for facts that can be reproduced;
2. use an AI agent for narrow interpretation and evidence assembly;
3. send judgment and policy changes to an accountable human; and
4. record the decision and the workflow’s coverage.

That is the reusable AI-first pattern: rules define expectations, tools check facts, agents explain context, and people decide.