Skip to main content
A proposed correction is a data correction a substitute rule has worked out but not written: the data point keeps its measured value until a person approves it. A substitute rule normally writes its corrections as soon as a method produces a value. Turn on Require approval on the rule’s Then step and it proposes them instead, and someone on your team approves or rejects each proposal. A rule that corrects many data points raises as many proposals. This page covers finding the proposals, deciding them, and what a waiting proposal blocks in the meantime.

​
Where proposed corrections appear

The same proposals show in five places:

​
Approve or reject a proposed correction

1

Open the data point

From the Events table or the rule’s Review button, click the row to open the Event Detail drawer. The proposal card shows the measured value, the value the rule proposes, the method that produced it, and how it arrived at the number.
2

Approve or reject

Two choices:
  • Use proposed, which approves it. The correction is written exactly as proposed, and the value a batch calculation reads changes. The data point’s correction history records the approval and who made it.
  • Keep current, which rejects it and keeps the measured value. Give a reason. The proposal is closed and recorded with your reason, and the value stays as measured.
Either decision is final for that proposal. A rejection also holds for that version of the rule: later runs of the same version do not propose a correction for that data point again. Editing the rule’s condition, methods or effective dates saves a new version. Proposals still waiting are withdrawn, and the new version can propose again when it next runs.
Deciding a proposal needs write access on the account, in the app and over the API.

​
What a waiting proposal blocks

A data point with an undecided proposal cannot be used in a new calculation: generating batches, changing a batch’s inputs, and running a model in the app or over the API all stop with a message naming how many data points have corrections waiting on approval. The batch generation form flags those inputs before you press anything, and Generate stays blocked until each is approved or rejected. Batches already generated are not affected, and a data point a batch used before the proposal was raised does not block changes to that batch. See Generate batches. If you need to generate before deciding them, switch Require approval off on the rule, which withdraws them (below). Completing a report is not blocked. When you click Mark as complete, the confirmation counts the corrections on the report’s data that are still waiting on approval. Once the report is complete those proposals can no longer be approved, so decide them first.

​
Switching approval off

Turning Require approval off on a rule withdraws every proposal still waiting on it. Nobody approved them, so those data points keep their measured values and are not corrected unless you evaluate the period again from the rule’s Runs tab. Data points the rule matches from then on are corrected automatically. The confirmation counts the proposals it will withdraw before you save.

​
Approving corrections over the API

Proposals appear in the rule’s results with approval_state set to pending and a proposed_correction object carrying the value, the method, and its derivation. Filter the results with approval_state=pending to list only those, and read a rule’s pending_count to see how many are waiting. Decide them one at a time with approve and reject, which take the result’s ID, or up to 100 at once with bulk approve and bulk reject. All four need a token with Data Rules write permission. See deciding proposals over the API for the flow end to end.