6 Rounding in analysis and reporting

Tip

Treat a rounding review as a scope question before treating it as a coding question. Write the business rule and define where it applies before evaluating solutions.

Imagine a Biometrics team preparing an adverse-event table. The display specification requires integer percentages and includes only terms whose percentages meet a reporting threshold. Only after the table is produced does a reviewer notice that team convention turns 2.5 percent into 3, while R’s default round() function turns it into 2. This halfway case is called a decimal tie. The correction is small. The deeper problem is that the organization’s rounding rules were not explicit enough to check when the code changed.

Common programming languages differ in their default handling of decimal 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

The lesson is not that one language is correct. A language default is an implementation choice, not organizational policy.

This chapter explores the problem, writes three related rules down, and sends one prompt to an agent to check a real R package against the first rule. The exercise can reveal a real finding, but a one-off prompt does not produce a workflow. In the AI-first SDLC from Chapter 4, the problem, rules, scope, and evidence gathered here are discovery inputs rather than completed Plan or Design artifacts. Chapter 7 starts from those inputs and the limits identified here.

6.1 Define the rules before checking the work

A reviewer cannot ask an agent or a team member to verify conventions that exist only in habit. The first task is not writing a prompt. It is producing a short, versioned set of statements describing what the organization requires.

6.1.1 Three business rules

This example uses three separate, illustrative business rules: BR-001, BR-002, and BR-003. They are not approved industry standards, and they are not the stated rules of any package reviewed here.

The rules answer three different questions: how ties are rounded, when rounding occurs, and how display precision is preserved. The exercise below checks only tie behavior; rounding stage and display precision remain explicit gaps.

BR-001: Values intended as exact decimal ties are rounded half away from zero. A displayed value is never a negative zero.

BR-002: Calculations use unrounded values; rounding occurs once, when the final result is prepared for display.

BR-003: Display precision is specified for each reported statistic and preserved, including trailing zeros.

BR-003 covers a problem that is easy to overlook because it is not arithmetic. The values 76, 76.0, and 76.00 are numerically equal, but they communicate different precision in a table. A program can calculate the intended number and still produce an output that violates a reporting convention.

Beyond this example: A community rounding skill

This book uses all three rules to define the policy, then deliberately limits the skill design in Chapter 7 to BR-001. A broader rounding skill covering tie method, rounding stage, and display precision is being developed through RConsortium/pharma-skills issue #208. As of 2026-09-06, the issue defines the first benchmark and states that the skill does not yet exist. Interested readers can follow the issue as the community turns the three-rule policy into a tested skill.

6.1.2 Define which calls are in scope

Naming BR-001 is not enough. The rule must also say where it applies. A request to check that source code “properly rounds half away from zero” does not say which calls are in scope, and the answer changes completely depending on that definition. BR-001 therefore carries this scope:

For this review, include any function call that can change a numeric value displayed in a report or used to decide which rows the report includes. Formatting functions round as a side effect of display, so formatC(), sprintf(), and format() are candidates. Finding one round() call does not establish complete coverage.

That clause is the difference between a review that inspects one function name and a review that inspects the calls that actually reach the table. The rest of this chapter shows how much difference it makes.

6.2 An exploratory request

The review target is Merck/metalite.ae v0.1.4, an open source R package that analyzes adverse events from ADaM data and produces tables, listings, and figures using the metalite data structure. The release is pinned to commit bdb23d472b16bc9dadbc774e64c5ca40321e9c6b.

A reviewer beginning a check against BR-001 might write this:

In metalite.ae v0.1.4 (commit https://github.com/Merck/metalite.ae/tree/bdb23d472b16bc9dadbc774e64c5ca40321e9c6b), verify whether the R source uses round half away from zero for analysis and reporting. If not, identify the source and draft a GitHub issue to report the finding.

The request names a target and a rule while leaving the search method open. That gives the agent room to inspect the package, follow unexpected paths, and surface assumptions, which is useful during an exploratory review. The same freedom makes the result difficult to evaluate or repeat: the request does not define the minimum files that must be covered, the evidence needed to demonstrate a violation, or who classifies the finding. A reusable workflow must clarify those evaluation and decision boundaries without prescribing every step in the agent’s reasoning.

6.2.1 Try it yourself

Send the following prompt to arena.ai before reading the rest of this chapter. The prompt deliberately leaves the investigation open. It fixes the target and rule, then lets the agent choose how to search, which clues to follow, and what supporting evidence to gather.

Review the R source of the metalite.ae package at release v0.1.4 and the exact
commit linked below.

Verify whether it follows BR-001: values intended as exact decimal ties must
round half away from zero, and a displayed value must never be a negative zero.

Release: v0.1.4
Pinned commit:
https://github.com/Merck/metalite.ae/tree/bdb23d472b16bc9dadbc774e64c5ca40321e9c6b

If evidence diverges from the rule, draft a GitHub issue.

Example output

Arena.ai cannot create a GitHub issue. A person manually copied one response to this prompt into issue #249; neither Arena.ai nor the skill designed in the next chapter posted it. Treat the saved response as an example to review, not as the answer key or a finding approved by the package maintainers.

Agent responses vary between runs, and that variability is part of the lesson. Do not treat any particular response as the answer key. Judge the response you receive by asking:

Did it inspect formatting functions as well as round()?
Did it follow wrappers or other unexpected paths through the code?
Did it give locations at the pinned commit rather than general advice?
Did it demonstrate behavior at ties of both signs?
Did it state what it checked and what it did not?
Did it distinguish observed behavior from the assumption that BR-001 applies?
Did it keep source evidence, causal explanations, defect classification, and proposed solutions separate?

The prompt did not ask the agent to search only for round(). It also did not prescribe a function catalog or a minimum search procedure. The response saved in issue #249 interpreted the request broadly: it examined an explicit round() call, formatting helpers, decimal-tie examples, negative-zero output, and a possible effect on report filtering. That breadth illustrates the value of leaving an exploratory investigation open.

6.3 What one exploratory prompt cannot provide

Reviewing the saved response makes that response easier to judge. It does not turn the interaction into a workflow. No workflow brief has been accepted, and no task contract specifies a repeatable check.

Leaving the search open can reveal functions, wrappers, and code paths that the reviewer did not anticipate. The tradeoff is that the prompt sets no minimum check against which another run can be compared. Four workflow capabilities are still missing:

Coverage assurance. A response can state which files and rules it checked, but the interaction provides no required file list or minimum set of checks against which to test that claim. Silence is not evidence that every file or rule was reviewed.
Repeatability. Repeatability does not require the agent to reason the same way on every run. It does require a stable minimum procedure and expected results. The exploratory prompt supplies none of those controls, so another run can follow a different path and return different coverage.
Separation of checks from judgment. The response can mix reproduced observations, causal explanations, provisional triage, and proposed decisions. A workflow must label deterministic evidence separately from agent judgment and human classification.
A named human gate. The prompt requests a draft but does not name who classifies each finding as a defect, a documented convention, an accepted exception, or not applicable, or who decides whether to post it.

These are workflow requirements, not criticisms of the response’s breadth. The gaps, together with the problem, rules, and reviewed evidence, are inputs to Plan in Chapter 7. The next chapter organizes them into a workflow brief, then carries them into a task contract in Design. That design establishes required checks as a minimum while preserving a separate exploratory pass.

6.4 Summary

Rounding looks like a settled question until two tools disagree at a tie. The disagreement is not a bug in a language; it is an unwritten policy. Writing the three rules down makes the policy explicit. Defining where BR-001 applies is what makes the response reviewable. The later source review contrasts one direct round() match with eight formatC() candidates.

An exploratory prompt can surface useful candidates and testable claims, and it may reveal paths the reviewer did not anticipate. Reading its output requires separating candidate evidence, reproduced observations, causal explanations, and proposed decisions. Turning that review into a workflow additionally requires assured coverage, repeatable minimum checks and a recorded human decision. Chapter 7 begins the lifecycle by turning those gaps into workflow requirements.