Decide whether to trust the report

Decide what makes this report trustworthy

A useful report gives you an answer you can explain, together with evidence for the parts you cannot check by eye.

Click Open formatted report. Find its date range, entry count and total. This is the six-row example used by the current course.

Then ask: what supports those numbers, and what remains uncertain?

By the end of this lesson, you will compare the report with its input, distinguish a software-check result from your judgment and write a bounded review decision. Reading these files makes no model call.

Keep the current software-check record beside the report so its commands, source and environment can be inspected.

Check one answer yourself

The six-row fixture is small enough to audit without reading the implementation.

Read the supplied CSV. Add its minutes: 90 + 30 + 45 + 60 + 30 + 15 = 270.

The project totals and category totals each add to 270. They describe the same work grouped in two ways; adding both tables together would count every minute twice.

Choose one group and explain how its rows produce the expected subtotal. Compare it with the expected text report and the formatted report.

Your arithmetic check

Write your answer in your own notes, or use the interactive lesson.

This optional note is saved in local browser storage when available. It is not a Harness result or approval.

Read the recorded result within its scope

A check is useful when you can identify the input, expected answer, command and actual result.

Read the Current software-check record. Find the selected runtime/source, reporting files, actual commands, environment and recorded outcome. Check what ran and whether anything failed, skipped or remained unexecuted.

The current bundled-report test run passed 77 checks, with no failures or skips. Read Text checks and HTML checks when you want to understand an expectation. That result supports the cases it exercised; it does not prove every possible input.

Read this prompt before sending it. It requests inspection only.

evidence inspection prompt

Inspect the current reporting source, six-row CSV, expected report and current-checks.json. Explain which commands actually ran, what their results establish, what failed or skipped and which claims remain unverified. Separate independent arithmetic, executed checks and your interpretation. Keep the inspection read-only. Do not start a model, change files, approve work or rerun anything merely because a result is uncertain.

Turn a concern into a checkable question

A plausible concern deserves a concrete input and expected result before you decide whether it is a defect.

1. Identify the exact input: the unchanged six-row CSV.
2. State the independent expectation: 6 entries, 270 minutes and Orion at 180.
3. Describe the supposed failure: 5 entries, 255 minutes and Orion at 165.
4. Ask whether current output or a suitable test actually shows that mismatch. Keep the concern unconfirmed until the evidence exists.

If a mismatch is observed, retain the failing input/output and choose a bounded investigation or correction. If it is not observed, report that outcome. A suggestion does not become a bug because it sounds reasonable.

Handle a real finding without changing the answer

When evidence establishes a defect, preserve the expectation and make the correction inspectable.

Use the missing-row concern as a paper exercise. Decide what a repair task would need before authorizing it:

1. Keep the six-row input and independently derived expected totals.
2. Prepare a focused check that exposes an observed mismatch. Verify it against the failing behavior before treating it as a regression check.
3. Define the smallest allowed implementation change and protect the acceptance expectation from the repair worker.
4. After separately authorized work, inspect the same check, actual diff and broader relevant results. Preserve failed attempts and any remaining concerns.

Notice when a plausible total is wrong

The omitted-row example lets you practice checking a result with fewer hints.

If the final 15-minute testing row were omitted, the report would show 5 entries and 255 minutes. Orion would total 165 and Testing 30; Lumen would remain at 90. These numbers could look plausible until compared with the complete input.

1. Identify the omitted row in the six-row fixture.
2. Recalculate one affected subtotal.
3. Explain which check would expose the omission: entry count, grand total, project total or category total.
4. State what your check would leave untested, such as invalid input or output-file handling.

Use an independent expected answer. Asking the same implementation to produce its own expected total can repeat the same mistake.

Leave an explanation another person can inspect

Use a short note to connect the useful result, checked claims and next decision.

Your review decision

Write your answer in your own notes, or use the interactive lesson.

Your wording stays in local browser notes when storage is available. It does not alter a Harness record.

Next: Open Tutorial 5: Make the tool usable to prepare a local handoff.