EBT Scenario Builder · the world's first of its kind
Great EBT starts with a great scenario.
We make EBT easy to build, use, and improve.
The EBT Scenario Builder is the world's first Scenario Builder for EBT and CBTA training, and where every AeroEBT programme begins. It runs on the Contextual Composition Protocol, SkyDynamics technology that holds the whole context of a scenario in memory, so the designer works on one simple screen while requirements, coverage and difficulty are checked as they write. AeroBrain drafts in minutes from your SMS safety data and your aircraft procedures, one designer reaches a checked scenario in about two hours instead of days, and the result goes straight to the AeroEBT instructor app.
Why scenarios come first
No EBT programme succeeds without its foundations.
Grading, concordance and reporting all measure what a scenario was designed to elicit. If the scenario is generic, unbalanced or written as an essay about competencies, everything downstream inherits the flaw. That is why AeroEBT starts here, with building the scenario, made simple.
Generic scenarios
Built from a textbook list instead of the risks your own operation reports, so the simulator never meets the threats your crews actually face.
Coverage found at the audit
Competency and observable-behaviour balance rebuilt in a spreadsheet after the cycle is written, when it is too late to change anything.
Tools only an expert can drive
Design software so complex that one person in the department can use it, and the programme stalls when they are away.
Contextual Composition Protocol · developed by SkyDynamics
One simple screen. The whole scenario held behind it.
An EBT scenario is simple to read and hard to design: every event touches the A/B/C specification, the competency framework, the aircraft procedure, the simulator's failure list and the balance of the whole semester. The Contextual Composition Protocol holds all of that in memory, behind the scenes, and correlates it with whatever the designer is working on at that moment. Place a malfunction in the approach and the builder already has its procedure, its malfunction cluster, the observable behaviours it elicits and what it does to coverage. The screen stays simple, and the scenario comes out clear.
- Holds the context of the task in memory: the scenario, its events and failures, the A/B/C specification, the competency framework and the scope of the programme
- Correlates each action with the data attached at that moment: an event placed, a failure changed, a question to AeroBrain about one phase
- Keeps the designer on the script, with no cross-referencing between manuals, matrices and spreadsheets
- The same protocol works in the instructor app during recording and assessment, so design and delivery share one context
- It works behind the scenes and decides nothing: the designer does
Five steps
From a safety finding to a scenario in the simulator
Brief
Start from a training need, from your SMS data, your programme or the regulatory topics for the period.
Phases
Lay out the flight phases of the session: the shape of the day, not a document template.
Events
Drop in procedures and malfunctions from the database for that aircraft type and that simulator, with difficulty set per event.
Competencies
Competencies and observable behaviours are mapped as you write, with coverage and complexity checked live.
Export & deploy
Export the scenario document for approval and push it to the instructor app for the session.
See it build
From topic list to compliant scenario. Every check runs while you write.
Coverage, balance and difficulty visible while you write. Illustrative session.
From days to one session
A first draft in minutes. A checked scenario in about two hours.
Traditionally a scenario takes days to reach the simulator: designers draft, meet, reconcile, check compliance, send it round by email and revise. In the EBT Scenario Builder, AeroBrain writes a first draft from your specification and your aircraft catalogue in minutes, and the checks that used to need a meeting run while the designer edits. One trained designer takes a scenario from specification to checked in about two hours.
- Start from a four-hour session skeleton, a blank part or an AeroBrain draft
- First draft in minutes: evaluation phase first, catalogue events only, A/B/C topics covered
- Coverage, malfunction equivalency and load checked on every edit, not in a review round
- One draft instead of three, and no rework loop after a late compliance check
- SkyDynamics' figures for one trained designer; they vary with scenario complexity
Enhanced EBT · from your SMS
Your safety data in. A tailored EBT programme out.
Connect the safety management system you already run. Occurrence reports, FDM / FOQA trends, LOSA and audit findings are ingested, grouped into signals and translated into training needs: each mapped to the threats, errors, undesired aircraft states and competencies it points at. The builder proposes where in the programme each need belongs, and the next cycle shows whether the risk moved. Enhanced EBT with high clarity: every scenario can answer "why is this in our programme?"
- Ingests SMS reports and FDM / FOQA exports (CSV, JSON or paste) including from SkyDynamics FSMS
- Findings become prioritised training needs, tied to TEM and the ICAO competencies
- A "Why training?" check before any need enters the programme, not every safety issue is a training issue
- Proposals for the next period, approved by the training team, never pushed automatically
- Traceable from safety finding to scenario to grade, as ORO.FC.231 and ICAO Doc 9995 intend
AeroBrain AI assistant
Simple commands. Enhanced EBT. None of the complexity.
AeroBrain, our aviation AI, sits beside the scenario as a co-designer that checks everything and suggests the next step. Nobody has to learn the tool: you say what you want. Draft writes a scenario from your aircraft database, Fill gaps adds beats for missing competencies and ORO.FC.232 topics, Coverage explains the balance, QA reviews regulatory and CBTA wording against the reference. Every draft shows its coverage, complexity and difficulty per phase before you decide to apply it, and Undo is one click away.
- Draft · Fill gaps · Coverage · QA, plus Ask on any single flight phase
- Aircraft-aware: drafts use only events from the database for that type; competency prose is rejected and rewritten as instructor beats
- Checked while it drafts: evaluation phase first, catalogue events only, regulatory topics covered
- Per-phase coverage, complexity and difficulty on every draft, before it touches the timeline
- Apply to timeline, keep current, or undo: the author always decides
What a scenario actually is
An instructor script, not an essay about competencies.
Scenarios are written the way instructors run them: short, imperative beats a colleague could pick up and fly. SET, INSERT, OBSERVE, NOTE, ADVISE, REPOSITION: each event pulled from the malfunction and procedure catalogue for that aircraft, tagged as normal, abnormal or supplementary.
- SET START VALVE FAULT: failed closed or open
- INSERT A/P FAILURE: difficulty 3
- SET NW STEERING FAULT + SLIPPERY SURFACE on the landing roll
- TCAS EVENT in the climb, then XBLEED FAULT
- Competency tags sit as metadata on the phase, where they belong
Three ways to work
Assist, semi-agentic, agentic: you choose how much it does
The same engine, with the amount of autonomy your training standards team is comfortable granting. Change it per author, per fleet or per programme.
Assist
You write; the tool suggests events from the catalogue, flags gaps and checks coverage as you type. Nothing is written without you.
Semi-agentic
You set the objective; it drafts phases and proposes the events. You keep or discard, phase by phase, and it explains why each one is there.
Agentic
You set the cycle goals and constraints; it builds the scenario group, balances coverage across sessions and presents the whole cycle for approval, as a proposal, never a publication.
Real-time requirement checking
Requirements checked as you write, not discovered at the audit.
Every event you place updates the picture: which observable behaviours this scenario elicits, how competencies are distributed across it, and what that does to the balance of the whole cycle. The manual coverage matrix, the spreadsheet someone rebuilds before every programme review, stops being a job.
- Observable behaviour coverage per scenario, live as you edit
- Requirements checked as you write: evaluation phase first, ORO.FC.232 A/B/C topics, malfunction equivalency under ORO.FC.231(f)
- Smooth distribution of competencies and observable behaviours across phases: no clusters, no blind spots
- Competency distribution shown as a balance, not a checklist
- Cycle and scenario-group view: what is over-trained, what is never seen
- Gaps flagged against your programme requirements while there is still time to fix them
- Coverage evidence exportable for the programme review
Beyond one scenario
A cycle is the unit that has to be compliant
A perfectly designed session inside an unbalanced cycle still fails a programme review. The tool works at all three levels.
Scenario
Events, phases, competency tags and the observable behaviours the session is designed to elicit.
Scenario group
Evaluation, manoeuvres and scenario-based phases balanced against each other rather than written in isolation.
Cycle
Coverage across the training cycle, so a competency is not trained four times in one cycle and never in the next.
Fleet and programme
The same view across fleets, with each type keeping its own catalogue.
Recurrence and freshness
What each pilot population has already seen, so the cycle develops rather than repeats.
Evidence for approval
The coverage picture exported as part of the programme submission.
Complexity and difficulty monitoring
Know how hard the session is before a crew does.
Load, difficulty and complexity are measured per flight phase and for the whole scenario while you build it. A descent that stacks three failures on a new-hire crew shows amber against the target for that population; a cruise with nothing to elicit shows up too. Competency × phase shows where each competency is exercised, so the distribution stays smooth instead of clustering in one phase.
- Difficulty per event and per phase; load against Light, Nominal or Dense targets
- Whole-scenario gauges: event load, session complexity, input completeness, competency concentration
- Competency × phase heatmap and left / right seat demand, so both pilots are tested
- Time pressure, concurrent conflicts and surprise / startle markers made visible
- Clearly labelled design aids for the author: never a crew grade
Tailored to the trainee group
One programme, adjusted for the crews who need it.
Not every group needs the same session. Choose the intended trainee population (new hire or early command, typical line crews, experienced recurrent) and the load and demand targets move with it. Where AeroEBT grading shows a group struggling with specific competencies, make those the primary design focus: coverage is weighted toward them, and the builder flags when the scenario drifts away. Tailor-made adjustments without writing a new programme.
- Population targets: new hire / early command, line (typical), experienced / recurrent
- Primary and supporting design focus per competency and observable behaviour
- Grading trends from AeroEBT show where a group needs more exposure
- Warnings when load or demand exceeds the target for that group
- Design focus shapes the scenario; it never limits what the instructor observes or grades (AMC8 ORO.FC.232(e))
Aircraft procedures database
Your fleet is already in it, from day one.
Scenarios are only as real as their events. The builder ships with a large database of aircraft procedures (normal, abnormal and emergency, structured the way QRH and FCOM are) already mapped to ICAO competencies, observable behaviours, malfunction clusters and resolving time. Day-one implementation for B777, B787, A320, A220, A330, A350, Q400 and ATR 72. And because every simulator is different, each FSTD keeps its own failure list: a scenario only uses the failures that device can actually insert.
- Day one: Boeing 777 and 787; Airbus A320, A220, A330 and A350; Dash 8-400 (Q400); ATR 72
- Normal, abnormal and emergency procedures with duration, steps and competency mapping
- Malfunction clusters and equivalency (ORO.FC.231(f)) worked out from the database
- Failure list per simulator: design for the device in front of you, full flight simulator or FNPT II (FNPT 2)
- Your own manuals and company procedures added on top; AeroBrain suggests the competency mapping for review
Day-one implementation
Aircraft procedure database
Procedures and malfunctions ready to build with from the first day, each mapped to competencies and observable behaviours. Other types are added with you.
Boeing
- B777Boeing 777
- B787Boeing 787
Airbus
- A320Airbus A320
- A220Airbus A220
- A330Airbus A330
- A350Airbus A350
De Havilland Canada
- Q400Dash 8-400
ATR
- ATR 72
Governed AI
An aviation model, with its homework done
AeroBrain is the engine behind the assist and agentic modes: a retrieval-grounded aviation model built and documented as a regulated AI system rather than a general chatbot pointed at a manual.
Grounded in your documents
Retrieval over your own manuals, programme, catalogue and regulatory references, with the source shown, not generated from general knowledge.
Classified as human cognitive assistance
Assessed as a Level 1B system under the EASA AI framework: it assists the author and never holds the decision.
Documented requirement by requirement
Compliance tracked against EASA NPA 2025-07 DS.AI, SC-AI-01, the AI Concept Paper and the EU AI Act, with status and evidence per requirement. We publish what is implemented, what is partial and what is planned.
Explainable by design
Every suggestion carries its reasoning and its source, so an author can disagree on evidence.
Logged and reversible
What was proposed, what was accepted and what was overridden, recorded for the programme file.
Your data stays yours
Customer scenarios and records are not used to train models for anyone else.
For a team of scenario designers
Several designers. One library, one review path.
Most EBT programmes are written by more than one person. Every designer works from the same organisation scenario library, including scenarios saved from the instructor app or the web administration panel, and each scenario carries a status from Draft to Published so everyone can see where it stands. When two designers change the same scenario, the second to publish is shown exactly what changed and nothing is overwritten. Live co-editing, where designers see each other working in the same scenario, is in development.
- One organisation library: preview any scenario, then import it or fork it as your own draft
- A status on every scenario: Draft, In review, Approved, Published, Retired
- Publishing never overwrites a colleague silently: the changed fields and phases are shown, then reload and reapply
- Version history for each scenario on the designer's workstation
- Retired scenarios stay readable and cannot be edited
- In development: live co-editing, with designers visible to each other in the same scenario
The pair that matters
The scenario you wrote is the screen the instructor flies.
The instructor app opens the same scenario in the simulator: the script on one side, grading and notes on the other, offline, with the debrief captured as it happens. No re-typing, no paper, no second system between design and delivery.
- Same scenario, same events, same order: design to delivery with nothing lost
- Grading against your framework in three taps or fewer
- Works offline in the device; syncs afterwards
- Signatures and paper-parity PDF for the record
One system, three applications
Connected to the instructor app and the web administration panel.
The Scenario Builder is one of three AeroEBT applications that share the same organisation data. Publishing sends the scenario through the web administration panel to the instructor app on every iPad, the same version at every base, after the builder has checked that the iPad can open it. In the other direction, aggregated grading analytics and instructor concordance return to the designer, so the next scenario is written with evidence from the last.
- Publish to iPads from the builder, with a confirmation step
- Instructor preview and an iPad compatibility check before publishing
- Organisation settings shared with web administration: grading scales, fleets and AI governance
- Grading analytics return as aggregates only: no individual grading record reaches the builder
- Instructor concordance shown beside the programme it belongs to
- Publishing needs a connection; the instructor app then runs the session offline
Coverage and reuse
What makes a scenario library survive an audit
Competency coverage visible while writing
See which competencies a session actually elicits before it reaches the simulator, not after the cycle.
Templates and clusters
Reusable patterns for evaluation, manoeuvres and scenario-based phases.
Multi-fleet reuse
One scenario adapted across types, with each type keeping its own catalogue.
Difficulty on the event
Difficulty recorded per event so a session can be tuned rather than rewritten.
Versioned and traceable
Who changed what, when: the question an inspector asks about a training programme.
Export for approval
A scenario document formatted for your programme and your authority.
Questions about the Scenario Builder
How long does it take to build an EBT scenario?
AeroBrain produces a first draft in minutes. One trained designer takes a scenario from the approved specification to a checked scenario in about two hours, because coverage, equivalency and load are checked while it is written rather than in review rounds. These are SkyDynamics' figures and they vary with scenario complexity.
What does the Contextual Composition Protocol do in the Scenario Builder?
It holds the context of the scenario in memory (the A/B/C specification, the competency framework, the aircraft and simulator catalogue, the programme's coverage) and correlates it with what the designer is doing at that moment. The designer works on a simple script screen and the context is already there. It is SkyDynamics technology, it runs behind the scenes, and it makes no decisions.
Can several designers work on the same programme?
Yes. Designers share one organisation scenario library, each scenario carries a status from Draft to Published, and publishing never overwrites a colleague's change: the builder shows what changed and asks the designer to reload and reapply. Live co-editing, with designers visible to each other inside the same scenario, is in development.
How is it connected to the instructor app and the web administration panel?
A published scenario goes through the web administration panel to the instructor app on every iPad. Organisation settings such as grading scales and fleets are managed in web administration, and aggregated grading analytics and instructor concordance come back into the builder for the next design cycle.
Can it use data from our safety management system?
Yes. Occurrence reports and FDM / FOQA exports are ingested by CSV, JSON or paste, including from SkyDynamics FSMS, grouped into signals and translated into prioritised training needs. A "Why training?" check runs before a need enters the programme, and the training team approves every proposal.
Which aircraft are ready from day one?
B777, B787, A320, A220, A330, A350, Q400 and ATR 72, with procedures mapped to competencies and observable behaviours. Other types are built with you, and your own manuals and company procedures sit on top.
Does it know what our simulator can do?
Each simulator keeps its own failure list, so a scenario only uses failures that device can insert. With FCS++ the programme also sees which devices can credit the session.
Can we tailor a scenario for a group that struggles on specific competencies?
Yes. Set the intended trainee population and make the weaker competencies the primary design focus; coverage is weighted toward them and load warnings follow the population targets. Design focus never limits what the instructor observes or grades.
Does the AI write our training programme?
No. It drafts phases from your objective and your aircraft catalogue, and flags its own output when it drifts into generic prose. The author keeps or discards each phase.
Where do the malfunctions come from?
From the malfunction and procedure catalogue for that aircraft type. If we do not hold a catalogue for your fleet, we build it with you.
Can we keep writing scenarios by hand?
Yes. The editor is the primary path: type an event, pick from the catalogue, done. AI assist is optional.
How does it reach the simulator?
The same scenario opens in the instructor app on iPad, offline, with grading and notes alongside the script.
Can we export for our authority?
Yes: a scenario document for approval, the coverage picture behind it, and the session records afterwards.
How does the agentic mode differ from AI assist?
Assist suggests while you write. Semi-agentic drafts phases you keep or discard. Agentic builds a whole scenario group against your cycle goals and presents it for approval. In every mode the output is a proposal until a person accepts it.
What does "real-time compliance monitoring" actually check?
Observable behaviour coverage and competency distribution for the scenario you are editing, and what that does to the balance of the scenario group and the training cycle, measured against your programme requirements, updated as you type.
Is your AI compliant with the EASA rules?
The EASA framework for AI is still developing, so nobody can hold a finished certificate today. What we can show you is the work: AeroBrain is classified as a Level 1B human cognitive assistance system and tracked requirement by requirement against NPA 2025-07 DS.AI, SC-AI-01, the AI Concept Paper and the EU AI Act, with implemented, partial and planned status and evidence for each. Ask and we will send it.
See a scenario built in the time this page took to read.
A live demonstration: your aircraft type, one training objective, from blank phase to instructor app.
We respond within one business day.