FOR CIVIL AVIATION AUTHORITIES

The record is the product.

An examination system that registers the candidate, composes the paper, marks it the moment it is submitted, and writes the sitting into a record that enforces its own rules — attempt ceilings, sitting limits, one attempt per subject per sitting — inside the write itself. It runs in a browser, and it is built on machinery a flight school already runs its theory programme on.

Request a technical briefing

WHAT THIS IS

Pilot 100 runs examinations inside a training-organisation platform today. Candidates sit papers in the browser, the platform marks them, and every sitting is written into a permanent per-subject record under the attempt and sitting rules that govern it. That machinery is what we offer an authority, and the rest of this page describes it in the terms an examiner would use. What does not exist yet is an authority-branded front door — your own login, over your own candidates, in your own house style. That is scoped with the first authority we build it with, which is why this page ends in a conversation rather than a sign-up button.

THE SYSTEM

What an examination system has to do.

Eight jobs. Each one is machinery that runs today.

Registration and planning

Create a candidate account, place it in a class, and put the whole class in for an exam with its own date window. Three forms, and the new account receives its own activation mail without anyone chasing it.
Nothing to install

It runs in the browser. Nothing on a candidate machine, nothing on an examiner’s, nothing to update — everyone opens the same address and is already on the current version. The session clock is held on the server, so closing a tab buys no time.
Papers composed to your specification

Subject by subject, question counts are drawn from named lessons and sub-lessons and restricted to your country’s question set, with the pass mark, the duration and the paper length set per subject. Ten validation rules run before anything is saved, and a dry run reports them without persisting a thing.
The platform marks the paper

The score is computed from the recorded answers, measured against that paper’s own pass mark, and written as the result at the moment the candidate submits. Nothing is graded by hand and no score can be sent in from a browser.
One live view of the cohort

A grid, per candidate and per subject: how far each one landed from the pass line on the paper they last sat, alongside a standing list of windows about to close and exams still locked. States are distinguished on sight — not started, sitting now, graded — and the grid refreshes as results land.
Sitting rules enforced, not remembered

The rules that govern a candidate’s attempts are not left to whoever happens to be filing the result. They are conditions on the write itself, so a filing that would breach one does not quietly land — it is refused, and told which rule refused it. The section below sets out all six.
A record that keeps itself consistent

A per-subject, per-sitting row with the score, the attempt number, the result and the date it was sat. Pass or fail, the attempt number and the count of passed subjects are derived from the history — none of them can be typed in — and the rows are never purged.
Roles, isolation and an audit trail

Roles decide what each person can open. One organisation’s data is invisible to every other at the query layer, ahead of any ownership check. Requests are written to an audit trail carrying the account, the action and the address behind it, under a retention tier set per action.

THE RULE ENGINE

Seven sitting rules, enforced in the write.

Not validated in a form and not audited afterwards. Every result is written inside one transaction, under a row lock on the candidate’s record, so two people filing at the same moment cannot both slip past the counter.

Six sittings per candidate Sittings are counted across every subject and capped at six. A sitting is the examination session as your authority defines it — typically several consecutive days — and is configured per authority. Today the platform treats each distinct sitting date as one sitting; a multi-day session definition is part of what we configure with you.
An attempt ceiling per subject Four per subject. The ceiling is read from the candidate’s own record at enforcement time rather than compiled into the rule, and it is checked ahead of the sitting limit, so a refusal names the attempt ceiling before it names the sitting rule.
A passed subject is closed Once a subject is passed, nothing further can be filed against it. Ever.
A failed set freezes the record If one subject burns every attempt without a pass, the whole set is failed: the record goes read-only and every further write is refused. FCL.025 fails the set on two further grounds — the sittings used up, or the 18 months elapsed. The platform refuses a seventh sitting, but it does not close a record on those two grounds by itself, and the fresh record a retaken set needs after further training is scoped with you.
One attempt per subject per sitting A second attempt at the same subject within the same sitting is refused.
Sittings run forward A result cannot be dated before that subject’s most recent one. The rule is scoped per subject, so filing an older sitting for a different subject stays legal.
All subjects within 18 months The window runs from the end of the calendar month of the candidate’s first attempt (FCL.025(b)(1)). It is not enforced automatically today: the dates it is computed from are all on the record, so the window is readable, but no filing is refused with a named code on that ground yet. Enforcing it is scoped with the first authority we deploy with.

Every refusal returns its own named code rather than a generic error, so a rejected filing says which rule stopped it. Pass or fail, the attempt number and the count of passed subjects are all derived — none of the three can be entered by hand.

THE CASE

Six things the platform already does, in detail.

Each of these describes software behaviour you can have demonstrated on a call — not an approval, an endorsement, or a credential.

Authority scope is in the data model, not in a filter

Authority is not a report parameter that someone remembers to set. A training organisation carries a mandatory authority. A progress-test template can restrict which authorities’ questions are drawn from the bank, and that restriction is stamped onto each candidate’s test at the moment they start — so editing the template afterwards cannot retroactively change what was already sat. Real-exam sightings reported by candidates are recorded per authority as well, with a date and a confirmation count. The consequence is that “which authority does this belong to” is answerable for a question set, a sitting and a record without a join anyone has to remember, and without an administrator being trusted to tick a box correctly.

Rule enforcement lives in the write

The rules set out above are not a validation layer sitting in front of a database that would have accepted anything. A filing is admitted only inside the transaction that writes it, under a row lock on the record header, so two people filing at the same moment cannot both slip past the counter. The checks run in a fixed order — record still open, subject not already passed, attempt ceiling, same-sitting repeat, back-dating, then the sitting limit — so a refusal names the first of those a filing breaks rather than a generic failure. The 18-month window is not in that chain yet; it is scoped with the first authority we deploy with. The derived fields are closed off at the boundary too: pass or fail, the attempt number and the count of passed subjects are computed from the score and the history, and a request that tries to send any of the three in is rejected before it reaches the service at all. There is no route through the API that writes a state the record did not earn.

The record is permanent by design

An authority exam result is a per-subject, per-sitting row carrying the score, the attempt number, the result and the date it was sat. Deleting a template, a classroom or an assignment retains history, and authority exam results are never purged. That is a deliberate design position rather than a retention setting: the record is the thing the rest of the system exists to protect, and the audit value of a record that can be tidied away is zero. The practical effect is that the sequence of sittings behind any candidate’s status can be reconstructed after the fact, in order, with the score that produced each state change.

Question integrity and the sitting environment

The exam runner keeps its clock on the server, so closing a tab does not buy time, and a session can be resumed without resetting it. Alongside that, the platform runs a signal-based session-integrity engine: eleven categories of probe, an exponentially decaying score, a graduated response from observe through warn and throttle to lock, and administrator-tunable thresholds with an observe-only mode that changes nothing while you calibrate. This protects question-bank integrity and session validity. It is explicitly not supervision: there is no camera, no screen recording, and no identity verification, and we will not describe it as any of those.

Audit at the request level

Every request against the platform can be logged with a retention tier — skipped, 48 hours, 30 days or 90 days — applied by a global interceptor, with a separate interceptor for administrative actions and a nightly job that enforces the tiers. This is infrastructure rather than a reporting feature, and we would rather describe it accurately than dress it up: it means the question “who touched this, and when” has an answer for the window that tier allows, and it means the retention policy is a configuration you can inspect rather than a promise in a brochure.

What we scope with you before a deployment

Four things are deliberately not decided in advance, because deciding them without you would be guessing. Who sees which candidate, at what granularity, and through what front door — there is no authority-branded login today, and the examination machinery is reached through the training organisation’s platform. Whether records ever leave the platform, in what form and to whom — today they are read on screen and nowhere else. The attempt ceiling and the subject count your authority works to — the ceiling already sits on each candidate record and is read there at enforcement time, but nothing writes it away from its default today, so setting it to your figure is work we would do with you. And the hosting, processing and retention arrangements, which we put in writing per deployment rather than as a badge on a page. We would rather settle those four once, with a named authority, than publish a screenshot of something nobody has agreed to. Two time limits sit in the same bucket: the 18-month window for passing the set (FCL.025(b)(1)) and the 36-month validity of passed examinations for licence issue (FCL.025(c)) are both derivable from the recorded sitting dates, and neither is enforced by the platform today.

GOVERNANCE

What we can say about how the data behaves.

Behaviour, not a badge. Where something is still to be agreed per deployment, it says so.

Retention is tiered and enforced

Request logs sit in one of four retention tiers, enforced by a scheduled job rather than by intent.

Exam records are exempt from tidying

Authority exam results are outside the retention sweep. They are kept.

Isolation is a guard, not a query

Tenant scope is checked ahead of ownership on every route, so a cross-boundary request returns nothing rather than the wrong record.

Hosting and residency: EU today, confirmed in writing per deployment

The platform is hosted in the EU. For an authority deployment we state the hosting region, the processors and the retention arrangements in writing as part of the briefing — not as a badge on a marketing page.

ALREADY RUNNING

This is not a prototype.

The engine described above is the platform a flight school runs its theory programme on today, with further schools in conversation. What this page describes is machinery in service, not a mock-up.

Multi-tenant, in production

A school tenant, classrooms, roles and a fixed guard chain on every route.

Thirteen-subject records

Every candidate carries a 13-subject authority record with attempts, dates and derived state.

Cohort analytics

A pass-trend line, first-time pass, average sittings to pass, and per-subject breakdowns.

See the flight-school platform

HOW AN EVALUATION WORKS

How an evaluation runs.

A technical briefing

We walk the data model, the rule enforcement and the audit posture with your technical people. No sales deck.
Your requirements, written down

Who sees what, at what granularity, in what format, retained how long, and who is accountable.
A scoped pilot

One authority, one subject set, one cohort, against agreed acceptance criteria.
A decision with evidence

You judge it on the records it produced, not on a demo.

TALK TO US

Tell us what your authority actually needs.

Write to us with the shape of the problem — the candidate volume, the subjects, the record you have to be able to produce and who has to be able to produce it. We will come back with what the system does today, what we would build with you, and what that would take. If the answer is that we are not the right fit, we will say so.

Request a technical briefing

We use what you send only to answer you. Nothing else.

OTHER AUDIENCES