Outcome observations

A program can carry several outcome observations. Each line has a parent program and a source record identifier, with room for a sequence, description, quantity, unit, observed date, amount and outcome value. The observation outcome can be pending, accepted or rejected. Those distinctions let an operator separate a received measurement from one whose source and meaning have been checked.

The observation also carries its own citizen reference, service code, document hash, decision reason and delivery reference. These details matter when the result originates outside the program workspace. They let the team compare a line with the source that produced it and with the eventual delivery reference. The program’s overall value should be interpreted in light of these individual lines and their recorded outcomes.

• One parent. Attach each observation to the impact program being measured.
• Source identity. Retain the source record identifier for each line.
• Outcome distinction. Keep pending, accepted and rejected lines visible separately.

Operators enter the lines. Reviewers inspect them with program context before deciding on the revision. Analysts can group accepted and rejected observations by program and observed date to understand how a published value was reached.

Agree a consistent unit for each kind of outcome and decide whether quantity, amount or outcome value is the measure used in a particular program. Define the meaning of the observation date and observed-on date if both are used by your source. Confirm how the source system creates identifiers and how duplicate deliveries are recognized. A source mapping can record the field names, types, transform rule and version used to interpret an incoming line.

Prepare observations that exercise the edge cases: a line with a missing supporting document, a duplicate source identifier, a rejected measurement and a later corrected record. Decide who can set the outcome after verification and what reason should accompany a rejection. The parent program and source identifier should make each line traceable during review.

A service team records two observations under one program. The first carries a measured quantity and outcome value, a service code and the identifier used in the source system. The second has a value but an uncertain document hash. The operator leaves the second line pending, adds a follow-up action for the supporting document and attaches the document when it arrives. A reviewer can inspect both lines from the program workspace and compare their source references with the evidence before deciding on the program revision.

After verification, the first line is accepted and the second is rejected with a decision reason. The program retains both lines. The analyst’s observation report can distinguish the accepted measure from the rejected one without treating every captured value as a confirmed outcome.

• Observations awaiting outcome — Pending lines with their parent program and source identifier.
• Accepted and rejected observations — Decided lines with values and reasons.

Define and collect covers observation entry. Verify evidence covers source checks before review.