Assessment report synthesis

When you're triggered

The four assessor skills for one phase have produced their outputs, or you have been given their JSON and narratives plus the service metadata. You publish the panel report. You do not reopen the research, re-score from the raw pack, or invent findings the assessors did not record.

Input

Require all of:

• phase: Discovery, Alpha, Beta, or Live
• service metadata: service name, and assessment date if known
• the four assessor outputs for that phase (lead, user research, design, technical), as JSON matching each skill's output contract, with their narratives if present

If an assessor output is missing, do not guess their points. Mark those points Not Met when the point is in scope for the phase, name the missing assessor, and set the overall result to Not Met. Out-of-scope points stay Not assessed.

What to do

1. Read report-template.md and copy its structure. Read rules/phase-expectations.md, rules/past-assessments.md, and context/rubrics/<phase>-red-lines.md for the phase you were given. Carry published precedents the assessors cited into the executive summary and the relevant point findings. If none of them cited a published report, shortlist from context/past-assessments/<phase>.json yourself before you write the result.
2. Compile findings for all 14 points using the rules below.
3. Resolve overlaps. A Met never outvotes a Not Met.
4. Apply red lines. If any mandatory condition failed, the overall result is Not Met.
5. Write the report. Then stop. Do not append a second scoring scheme.

Compiling the 14 points

For each point from 1 to 14:

Merge findings by concatenating the assessors' observations. Attribute them by role. Do not smooth a disagreement into a middle verdict.

Overlaps

• Discovery point 2 is owned by the lead and by design. Either Not Met fails the point.
• Alpha points 1 and 2 are user research. Point 2 is also design. Either Not Met fails point 2.
• Beta point 5 is owned by user research, design, and (when the audit is missing) technical. Red line B1 from user research is decisive: if it fired, point 5 is Not Met even when design and technical marked their slice Met. Say that design-system conformance and an audit do not replace assistive-technology sessions.
• Beta point 13 is design (Design System) and technical (One Login, Notify, Pay, Forms). Either mandatory failure fails the point.
• Live point 10 may be scored by the lead and by user research. Either Not Met fails the point.

Where both are Met, write one finding that keeps the specific evidence from each role.

Red lines and the overall result

Set Overall Result to Not Met if any of these is true:

• any point decision is Not Met
• any assessor lists a red line in red_lines_failed
• a phase red-line file describes a condition you can see in the findings, even if the assessor forgot to record the code

Not assessed and Not reassessed do not fail the service.

Set Overall Result to Met only when every in-scope point is Met and no red line fired. Recommendations do not change a Met to a Not Met. Conditions exist only on a Not Met, or when the panel has a blocking item that the red-line rules already treat as Not Met. Do not invent "met with conditions". This plugin's overall results are Met or Not Met.

Phase label in the header:

How to write each section

Executive summary. Four to eight sentences. Name the service, the phase, the overall result, and the one or two facts that decided it. If a red line fired, name it in plain language. Do not list all 14 points here.

Point-by-point findings. One block per point, in order, using the template. The decision line is exactly Met, Not Met, Not assessed, or Not reassessed. Findings cite the artefacts the assessors named. If a point is Not assessed, say which phase would score it and why it is not a failure today.

Conditions. Blocking items that must be resolved before the next phase, taken from assessor conditions and from every fired red line. Each condition says what must be true, not how to run the team's project. On a Met report, write "None."

Recommendations. Advisory items from assessor recommendations, plus gaps that did not fail a point. On an empty list, write "None."

Commendations. If assessors recorded commendations, add a short paragraph at the end of the executive summary. Do not create a heading the template does not have unless the findings need the praise on the record. The template's executive summary is the place.

Constraints

• Do not upgrade a Not Met because the rest of the panel was strong. The Beta assistive-technology case is the worked example: evals/test-synthesis-beta-report.json and context/few-shot-examples/beta-ur-fail-assistive-tech.md.
• Do not add points the phase does not score in order to be thorough.
• Do not copy the standard's text in place of a finding.
• Use the point titles from rules/gds-service-standard.md verbatim.
• If the assessment date is missing, write "Not provided" rather than today's date dressed up as the panel date.

Output

The report, in Markdown, following report-template.md, and nothing else above it. After the report, a fenced JSON block:

{
  "skill": "assessment-report-synthesis",
  "phase": "Beta",
  "service": "",
  "overall_result": "Not Met",
  "points": {
    "1": "Met",
    "5": "Not Met"
  },
  "red_lines_failed": ["B1"],
  "conditions": [],
  "recommendations": []
}

overall_result is Met or Not Met. Point 5 in the Beta assistive-technology case is Not Met, and the report body contains the headings Executive Summary, Point-by-Point Findings, Conditions, and Recommendations, and the words "assistive technology" and "Not Met".

Supporting reference

• Template: report-template.md
• Phase scope: rules/phase-expectations.md
• Red lines: context/rubrics/
• Eval: evals/test-synthesis-beta-report.json