Six-day instructor-led course · five participants · 42 hours
Requirements, independent checks and honest evidence
Garuda AI Learning Lab is the practical workbench for a course on AI-assisted software engineering in safety-critical settings. Whoever or whatever writes the code, learners practise the same discipline: state requirements precisely, write expected results independently, run real checks and keep an evidence record that holds up under review.
How the exercise works
Requirements
Eight numbered requirements define what the validator must accept and reject.
Inspect a candidate
Choose a revision or adjust its bounded settings, and read the pseudocode derived from them.
Run checks
Authored tests run against the candidate. Expected outcomes never change with the candidate.
Record evidence
Record a review conclusion and export a JSON report that re-checks its own contents.
Course outline
Proposed six-day structure. This public demo contains one exercise; the full course, instructor-led sessions and assessment remain to be developed and delivered.
| Day | Hours | Topic | Practice in this workbench |
|---|---|---|---|
| 1 | 7 | AI fundamentals for safety-critical software: capabilities, failure modes, where assistance fits and where it does not | Limits page; note N-06 on tool results versus explanations |
| 2 | 7 | Retrieval over standards and guidance documents, with citations that can be checked | Evidence library: local text retrieval with links to official sources |
| 3 | 7 | Tool calling and requirements engineering | Lab steps 1–2 and the Traceability view |
| 4 | 7 | Code generation and coding-standard (MISRA C) concepts | Illustrative source view only. Coding-standard analysis is taught by the instructor with licensed tools and material |
| 5 | 7 | Verification and validation: boundary cases, independent expected results, coverage concepts | Lab steps 3–4: run checks, review failures, export evidence |
| 6 | 5 + 2 | Capstone workflow and practical assessment | Faulty-candidate diagnosis as a warm-up; assessment is not part of this demo |
| Total | 42 | Five participants, instructor-led | |
Exercise EX-01
Inventory-record validator
A validator accepts or rejects synthetic records describing classroom lab equipment. Two candidate revisions exist and one contains defects. Read the requirements, inspect a candidate, run the independent checks and record what the evidence shows.
Requirements
Each requirement names the error codes a rejection must report. Tests are written from this text alone.
Inspect a candidate
Validation settings
Bounded settings used by the fixed validator function. Editing them creates custom settings; nothing you enter is executed as code.
Illustrative pseudocode
Generated from the settings on the left for reading. It is not compiled or executed; the checks run as JavaScript in lib/validator.js.
Run the checks
Record the evidence
Recorded separately from the results. A conclusion cannot change a failing check.
Report self-check
Preview report JSON
Exercise EX-01
Traceability
Every requirement links to the tests that check it, and every test to its result. Links are authored by the course team and reviewed by the instructor; the workbench does not infer them.
Test catalogue
Expected outcomes are authored from the requirements and are identical for every candidate.
Local text retrieval · 13 authored notes
Evidence library
Search short teaching notes written by the course team. Matching is literal: results are ranked by how many of your words appear, then how often. No language model reads, ranks or rewrites anything, and when nothing matches the library says so.
What this demo is, and is not
A public educational demonstration of one exercise from a proposed course. It is intended for engineers and instructors reviewing how the course teaches traceability and independent checking.
Functional limits
- No AI model is connected. Nothing on this site generates code or text. The evidence library is literal text matching over authored notes.
- Synthetic data only. The inventory records are invented and have no operational meaning.
- Checks run in your browser as JavaScript. The pseudocode view is derived from the settings for reading; it is not compiled or executed C.
- Not certified or qualified software. Not flight software, and not evidence of compliance with any standard.
- Not the full course. Course materials, instructor-led sessions, assessment and certificates remain to be developed and delivered.
- Nothing is stored. There are no accounts. State lives in this page only; reloading or Reset clears it. An exported report is saved only where you choose.
- No external requests. The page loads only its own files. Links to official sources open only when you follow them.
Planned, not present
A local model integration for course workstations is planned for future work. If added, its output would be labelled as a suggestion requiring review and would never change a check result. It is not part of this demo.
Source material
Teaching notes are paraphrased by the course team. They link to public official pages (FAA, RTCA, EASA and the KLEE project) and reproduce no text from licensed standards.