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
- Q2 20261 Apr 2026 to 30 Jun 2026 inclusive
- Produced
- 31 Aug 2026, 09:14 UTCPeriod boundaries are cut in UTC.
- Named detail
- Open. This document names people.
What this period shows
- 11 of the 18 people listed are below the pass mark of 70, and 7 are at or above it.
- The weakest published category is access control, where 63% of what was planted there was found.
- 2 of the 20 assignments in this period were not finished.
- 51 people held a seat against 50 bought, so at least one seat was passed between people, and the results cover more people than the licence describes.
Every line above comes from the figures on this page. Nothing is said about a figure this report has withheld.
Withheld: 18 people finished an assessment in this period, and a median needs 20.
An aggregate is only published when at least 10 people are in it, and a median when at least 20 are, because with fewer than that you could work out who is who. Below that you get the organisation-wide figure, which is computed on a schedule and has not been produced for this organisation yet.
More people held a seat than were bought, so at least one seat was passed between people and the results cover more people than the licence describes.
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.
- Business logic70% caught28 found of 40 planted12 missed10 people
- Request forgery65% caught26 found of 40 planted14 missed10 people
- Access control63% caught19 found of 30 planted11 missed10 people
3 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.
- TypeScript66% caught73 found of 110 planted37 missed10 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. That median is for this table only; a published team figure needs a larger cohort before the report states one.
Showing 1 to 15 of 18
All 18 people assessed in this period.
Page 1 of 2
No retake was granted or sat in this period. Every figure above is a first sitting.
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 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 | 10 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 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.
4 of these 18 people scored level with the model, within 2 points either way. 9 scored above it and 5 below. The table opens with the closest first.
18 people are compared here. 9 scored above the model, 5 below it, and 4 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.
An aggregate is only published when at least 10 people are in it, and a median when at least 20 are, because with fewer than that you could work out who is who. Below that you get the organisation-wide figure, which is computed on a schedule and has not been produced for this organisation yet.
More people held a seat than were bought, so at least one seat was passed between people and the results cover more people than the licence describes.
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 18 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
- 2
- Assignments made
- 20
- Assignments completed
- 18
- Distinct people who held a seat in this period
- 51
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
- 51
More people held a seat than were bought, so at least one seat was passed between people and the results cover more people than the licence describes.
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.