How it’s engineered
The tools are small, but each is built the way a system is built: a stated need, requirements traced to a source, verification against those requirements, and an honest record of what was not checked.
From need to evidence
Each tool starts from a stated need, gets requirements traced to a published source, is verified against those requirements and validated with the person who asked for it. This section maps that work to the life cycle processes of ISO/IEC/IEEE 15288:2023, using only facts from the tools on this site.
The Vee, applied
Select a stage to see what I do there and which tools show it. Dashed lines join each design stage to the stage that checks it (after Forsberg & Mooz, 1991).
Practice to evidence traceability
Each row is a systems engineering practice, the 15288 process it belongs to, the evidence in my own work, and how that evidence was verified. Select a tool name to open its card.
| Practice | 15288 process | Evidence in my work | Method |
|---|
ASTERIX Feed Suite through the life cycle
A transmitter and receiver for surveillance data feeds, built for Windows, Linux and 2 single-board computer cards. All figures come from its own test and defect records. Test data is simulated.
What this is not
- These are independent and prototype tools. None is certified, and none forms part of a formal safety case.
- Verification is by my own tests and reviews. No independent body has assessed them.
- I control the requirements, the tests and the acceptance. A passing test is evidence, not proof.
- All radar, radio and network data shown is simulated. No operational data is used.
- Where a requirement value was unknown, the tools hold a placeholder rather than an invented limit.
Sources
- Forsberg, K., & Mooz, H. (1991, October 21–23). The relationship of system engineering to the project cycle [Conference paper]. Joint conference of the National Council on Systems Engineering and the American Society for Engineering Management, Chattanooga, TN, United States.
- INCOSE. (2023). INCOSE systems engineering handbook: A guide for system life cycle processes and activities (5th ed.). Wiley.
- International Organization for Standardization. (2018). Systems and software engineering: Life cycle processes: Requirements engineering (ISO/IEC/IEEE Standard No. 29148:2018).
- International Organization for Standardization. (2023). Systems and software engineering: System life cycle processes (ISO/IEC/IEEE Standard No. 15288:2023).
- National Aeronautics and Space Administration. (2016). NASA systems engineering handbook (NASA/SP-2016-6105 Rev2).
AI Types. I Engineer.
“AI writes the code” does not mean the engineering is done for me. The model is the programmer. I am the systems engineer who decides what to build, how it is checked and whether it is right.
What I do on every tool
- Define the problem and the interfacesInputs, outputs and formats, traced to a published standard where one exists.
- Write the requirements before any codeEach one gets a test or check that will show it is met.
- Investigate how the format really behavesThen turn that into made-up test data that still exercises the awkward cases.
- Choose the verification methodInspection, analysis, demonstration or test, chosen per requirement.
- Review every failureTrace it to a cause, number it and keep it in a defect record.
- Challenge the generated codeAsk for the edge cases and reject answers that look right but are not.
- Decide if each requirement is metAnd say plainly when it is not, or has not been checked.
What the AI does
- Writes and refactors the code from my brief.
- Drafts test scaffolding, which I then check.
- Explains code and options when I ask.
What it never does: decide what correct looks like, or sign off a result.
Example: in the Feed Suite, most faults sat at the seam between 2 parts that had each passed their own tests. An end-to-end check found them.
Working with AI
I’ve spent over 35 years in engineering: defence, air traffic, medical imaging, networks and field service. Since June 2026 I’ve used AI as the programmer while I work as the systems engineer, all of it in my own time, on my own kit. The AI projects page has a build timeline, a game where you catch the AI out, and lessons learned.
The loop
- Real problemSomeone brings a repetitive job and a made-up example file.
- RequirementsI trace them to a published standard, with a test for each.
- AI buildsI brief the model like a contractor: purpose, inputs, standard, good result.
- I verifyAgainst the standard and against real files, because the code can look fine and still be wrong.
- FeedbackThey tell me what’s wrong.
Then round again. The best fixes start with “that’s not how we actually do it.”
What I can do with AI, and the proof
| Skill | What I actually do | See it in |
|---|
Timeline
- First build: one HTML file that encodes every plot as real ASTERIX and decodes the same bytes back.
- Within days it was decoding large recorded files at full speed.
- The toolkit replayed long recordings in a 3D airspace view.
- A 15-minute talk on how it was built and checked.
- A cited knowledge base design, a brand system and this collection of apps.
- This page rebuilt with Claude Code and audited with Lighthouse.
What I’ve learned
- Knowing what correct looks like is now the hardest part of the job.
- AI gets things wrong with total confidence. Engineering discipline makes the output trustworthy.
- Be careful what data you demonstrate with. Anything shared uses made-up values.
- Design for the operator. Most of these run in a browser, in one file, with no install.
- The human keeps the decision. The tools take the drudge work and show their reasoning.