Sample report. Every name and number is invented. The paid product is not on sale yet.
Report
What each developer caught and missed on the assessments you set, by CWE and by language, with the settings each assessment ran under. Personal training never appears here.
- Organisation
- Fernbrook Systems
- Period
- Last 90 days2 Jun 2026 to 31 Aug 2026
- Produced
- 31 Aug 2026, 09:14 UTCPeriod boundaries are cut in UTC.
- Named detail
- Open. This document names people.
What this period shows
- 20 of the 37 people listed are below the pass mark of 70, and 17 are at or above it.
- The weakest published category is access control, where 69% of what was planted there was found.
- 6 of the 43 assignments in this period were not finished.
Every line above comes from the figures on this page. Nothing is said about a figure this report has withheld.
Coverage by CWE category
What the assessed work actually exercised, and how much of it was caught. Categories with too few people behind them are not published as an average.
- Access control69% caught74 found of 107 planted33 missed17 people
- Injection72% caught69 found of 96 planted27 missed12 people
- Authentication70% caught39 found of 56 planted17 missed14 people
- Sessions and cookies74% caught31 found of 42 planted11 missed14 people
- Data exposure70% caught28 found of 40 planted12 missed20 people
- AI safety71% caught17 found of 24 planted7 missed12 people
4 further values are not listed, because fewer than ten people are behind each of them and an average over fewer than ten identifies people.
Coverage by language
The same breakdown by the language of the codebase reviewed, taken from what each codebase declares.
- Java71% caught89 found of 126 planted37 missed14 people
- TypeScript67% caught69 found of 103 planted34 missed17 people
- PHP70% caught59 found of 84 planted25 missed12 people
- Python70% caught42 found of 60 planted18 missed12 people
2 further values are not listed, because fewer than ten people are behind each of them and an average over fewer than ten identifies people.
Developers
Open: named per-person detail is included for the roles entitled to it.
Status is the product's own grade, on the same pass mark it uses for every submission: a median score of 70 or more is a pass. Below the mark reads Needs work, and Well below where the score is also under the median of the people listed here, which is 69. That median is for this table, not the published team figure above.
Showing 1 to 15 of 37
All 37 people assessed in this period.
Page 1 of 3
Retakes
Every attempt is recorded. A retake replaces the earlier attempt in the figures only once it is submitted, and the earlier sitting stays on that person's own record. One retake touched this period, granted or sat inside it.
| Person | Assessment | Granted | Re-sit |
|---|---|---|---|
| Grace Ntuli | The third quarter access control review | 11 Aug 2026 | Submitted 11 Aug 2026 |
Assessments
Every assessment set or sat in this period. Each row shows when it ran, what help was available, and how far people got. All four completion figures count the assignments in this period.
| Assessment | Window | Switched on | Completion |
|---|---|---|---|
The third quarter access control review 6 challengesset 28 Jul 2026 | Closed 17 Aug 2026 | Nothing switched on | 14 submitted2 not completed in window |
The third quarter injection review for the payments squad 5 challengesset 6 Jul 2026 | Closed 31 Jul 2026 | Nothing switched on | 12 submitted2 not completed in window |
The second quarter secrets review for the platform squad 4 challengesset 8 Jun 2026 | Closed 30 Jun 2026 | Walkthroughs | 8 submitted |
The second quarter business logic review for the client applications squad 5 challengesset 14 May 2026 | Closed 5 Jun 2026 | Nothing switched on | 3 submitted2 not completed in window |
Who has not finished
The people behind the counts above. The counts are published at every visibility level. The names follow the same level as the developer table, so a level that switches names off shows the counts and not the people.
The third quarter access control review2 people have not finished
- Priti Raval [email protected]Not completed in windowassigned 3 Aug 2026opened 6 Aug 2026
- Niamh Corrigan [email protected]Not completed in windowassigned 3 Aug 2026never opened
The third quarter injection review for the payments squad2 people have not finished
- Kwabena Mensah [email protected]Not completed in windowassigned 13 Jul 2026opened 20 Jul 2026
- Larissa Petrova [email protected]Not completed in windowassigned 13 Jul 2026opened 29 Jul 2026
The second quarter business logic review for the client applications squad2 people have not finished
- Domhnall Kearney [email protected]Not completed in windowassigned 18 May 2026never opened
- Hakim Ferhat [email protected]Not completed in windowassigned 18 May 2026opened 3 Jun 2026
Neither comparison on this tab exists for a paying team today, and both sets of figures below were invented for this sample. The frontier-model comparison is published once a model has been run against these answer keys, and no run has been published yet. The peer percentiles need enough customers to compute, and none has been computed. A real report says both of those here and shows nothing, so read this tab as the shape it will take, not as a number you get on the day you sign.
Benchmarks
Where reviewers at other customers land on the same measure. A quarter of them score below the lower figure, half below the middle one, and a quarter above the upper.
| What is measured | Across | Lower quarter | Middle | Upper quarter | Reviewers |
|---|---|---|---|---|---|
| Planted findings caught on assessments | Every assessed review | 54% | 67% | 79% | 1,240 |
Against a frontier model
How a frontier model scored on the same challenges, given the same diffs and marked against the same answer key, with no hints and no walkthrough. The model is not named, because these figures are invented for this sample and an invented number under somebody else's product name is a claim about their product.
Both figures are scores out of 100 over the same challenges. A person is only compared on work a published run covers.
6 of these 37 people scored level with the model, within 2 points either way. 21 scored above it and 10 below. The table opens with the closest first.
37 people are compared here. 21 scored above the model, 10 below it, and 6 within 2 points of it either way.
Rows within 2 points of the model, either way, are marked.
The same report, anonymised
This is the same period's report with the names switched off. Only the person themselves sees their own detail. The totals, the delivery record and the seat figures do not change.
Per-person detail
Anonymised: only the individual sees their own detail. Everyone else gets the delivery record and the aggregates.
Per-person results are withheld at this organisation's visibility level. The delivery record above still shows 37 submitted assignments.
The team against a frontier model
The comparison from the benchmarks tab, as counts instead of names. Each band is a number of people. The peer figures on that tab have no names in them and are unchanged by this level.
A distribution is only published when at least 40 people are in it, because with fewer than that it identifies people. Fewer than that were assessed in this period, so nothing is shown.
What the record still shows
- Assessments set or sat
- 4
- Assignments made
- 43
- Assignments completed
- 37
- Distinct people who held a seat in this period
- 49
The two coverage tables at the front of the report each have ten people or more behind them, so they are published here in full and unchanged.
Seat integrity
An auditor reads these three figures together. If more people held a seat than were bought, a seat was passed between people, and the results above cover more people than the licence describes.
- Seats purchased, as things stand today
- 50
- Assigned right now
- 48
- Distinct people who held a seat in this period
- 49
The first two figures are the position today. The third covers the period, so where seats were bought or given up part way through, the comparison is across two dates. The count of people who held a seat comes from the seat assignments and releases in your audit log, and it appears on the export.
Export
The PDF is the document you hand over. It is the whole report: the period it covers, how the exercises were built and marked, what each developer caught and missed, the settings each assessment ran under, the seat figures, and the clauses in PCI DSS, DORA, ISO 27001 and the EU AI Act that this record answers.
The CSV is the same figures as rows. It opens in a spreadsheet, so someone checking the report can add the numbers up themselves, and it is the copy to keep if you want to compare this period with the next one.
Both cover the period selected above. Each of the other tabs also exports its own table on its own.
Both are produced here for real, by the same code that produces a customer's, over the invented rows on this page. Every page of the PDF is watermarked, the file names say sample, and the document says inside itself that it is not evidence. The four per-section spreadsheets on the other tabs are not produced here, because each one is recorded against an organisation and there is none behind this page.
What this record does not establish
What this record establishes: that the account named against each result was signed in, submitted those findings in the window shown, and was marked on our server against a prepared answer the browser never receives. The exercise is never published, so it cannot be practised beforehand. Hints and walkthroughs are off unless an administrator switched them on, which is stated on each row.
What it does not establish: who was at the keyboard. The sitting is not invigilated. Nothing here shows whether the named person worked alone, whether someone was helping, or whether the diff was pasted into another tool. We only see what the product offered and what was submitted to it.
Read a result as evidence of work done under this account, in this window, under the stated settings. Where a role needs more than that, run the sitting under your own supervision and record that alongside this document.
Who is in this document: everybody who was assigned an assessment in the period and held a developer seat when they sat it. That is not necessarily everybody who writes code here. This record cannot say how many engineers the organisation has or how the people assigned were chosen. An auditor who needs that should ask for it.
These paragraphs are in the exported document as well, so a reader who is handed the file reads the same thing.
Every export is recorded against this team before the file is produced, with a SHA-256 of the file exactly as delivered, the period it covers and who produced it. That record is in the audit log, and it is how a copy can be shown to be unaltered.