Reviewing AI output · illustrative example
The draft says 12 weeks. What supports that number?
Supernova helps teams review AI-generated specifications and plans against project records. This fictional example shows how source checks, a visible calculation, and human review turn an unsupported delivery promise into a clear planning decision.
- 01
Exhibit A
Find the source.
In this fictional example, a draft says delivery will take 12 weeks. The supplied scope lists screens and integrations, but neither it nor the agreement sets a delivery date. The review flags the sentence as unsupported.
Finding
The reviewer sees the missing source beside the claim.
Finding: no agreed schedule in the supplied records.
- 02
Exhibit B
Show the calculation.
Supernova's estimator uses code to total the classified work. The sample inputs below give 32 person-days of effort. That calculation checks the sum; the team must still review the task counts and effort assumptions. Person-days measure work, not calendar duration.
Illustrative inputs, not a complete project estimate Work Count × days each Person-days Screen tasks 8 × 3 24 Integration tasks 4 × 2 8 Sample effort subtotal 32 32 person-days could be spread across people and weeks in different ways. Staffing, task dependencies, and testing still need a plan before anyone can propose a calendar date.
Finding
This subtotal neither proves nor disproves a 12-week schedule.
Finding: 32 person-days for these sample inputs.
- 03
Exhibit C
Review the assumptions separately.
Supernova separates generation from verification. Powell, a checking agent, compares generated use cases with their source material and records issues for a human reviewer. This planning example uses the same review questions: where is the evidence, what is missing, and what decision is still needed?
Finding
A second review helps find gaps; it does not guarantee that every error is caught.
Finding: staffing, dependencies, and testing time are unconfirmed.
- 04
Exhibit D
Give the reviewer a decision.
The sample review keeps the 32-person-day subtotal with its inputs and removes the unsupported schedule commitment. The project manager owns the next action: confirm team availability, external dependencies, and testing allowance with the Tech Lead before proposing a delivery date.
Finding
The plan now names what is known, what is missing, and who must resolve it.
Decision: effort recorded; delivery date awaiting confirmation.
- 05
Exhibit E
Record why the plan changed.
Generation records keep the run and its outcome. Review history keeps findings and decisions. In this example, the useful record is simple: the original 12-week claim, the missing source, the effort calculation, and the reviewer's reason for withholding a delivery date.
Finding
A later reviewer can inspect the reasoning instead of asking someone to remember it.
Record: the claim, evidence, correction, and review decision.
- 06
Exhibit F
Propose a reusable review rule.
Repeated, confirmed corrections can suggest a new checking rule. A person reviews a proposed rule before it is adopted. For this example: flag schedule commitments that do not explain staffing, dependencies, and the source of the date. One correction does not automatically retrain a model or change every project.
Finding
Review feedback can improve future checks through a separate approval process.
Possible lesson: require evidence for a schedule commitment.
Illustrative review outcome
32 person-days recorded. Delivery date still to be agreed.
The project manager confirms staffing, dependencies, and testing allowance with the Tech Lead, then submits a schedule for review. The unsupported 12-week commitment is removed from the draft.
See the evidence before you approve the work.