Modernizing Our Engineering Governance for the Age of AI

The Shadow on the Moon (TSoM) has always worked under defined engineering rules for how changes are planned, recorded, reviewed and released. This month we completed and released a major update to that governance, modernizing it for a world in which AI tools are part of everyday firmware development and hardware analysis. The complete standard is published openly in the TSoM governance repository, and its adoption across our projects is under way.

Why we updated it

AI tools now assist our engineers in drafting and reviewing firmware, checking schematics and board layouts, and above all in the surrounding work: documentation, change records, versioning and releases. That brings real speed, and it also raises new questions: who owns a change an AI helped make, who signs it off, and how do we keep a reliable record when work moves this fast? Our existing practices were built for people working alone. Rather than start over or leave the gaps to habit, we extended what already worked to cover AI explicitly.

The engineer remains the engineer

To be clear: AI-aided does not mean AI-made. System architecture, hardware design, firmware design and the decisions behind them are, and remain, the work of TSoM engineers. They set the direction, write and own the code, and answer for the result. AI does not replace the engineer or the developer; it is a tool in their hands, much like a compiler, a simulator or a test bench, only more flexible.

Where AI contributes most is in the work around the engineering: drafting documentation, keeping change records and the project wiki current, preparing commit descriptions, running checks, and supporting the versioning and release routine. That is time engineers get back to spend on design, problem-solving and validation.

What the completed standard adds

• AI under the same rules as the engineer. A dedicated guide sets out what an AI tool may do on its own, what it must ask about first, and what it may never decide. Nothing is relaxed because a machine helped.
• Full traceability. Every change belongs to a tracked task, a version and a build. A defined ticket model records where each piece of work stands, from idea to release, and what happened to it.
• Automation of the paperwork. Versions, builds, dates, delivery status and change records are captured or drafted automatically. Scheduled checks flag work that has gone quiet or records that contradict each other, so problems surface early.
• Honest handling of exceptions. Rules are backed by warnings, not roadblocks. If a rule is deliberately bypassed, the system records it and raises an alert instead of stopping the work.
• Procedures for the whole life of a product, including releases, urgent fixes to shipped versions, and retiring old work, plus a worked example that follows one change from ticket to release.
• A live status view. A shared board shows what is in progress, what awaits a decision and what needs attention, without status meetings or manual reports.

Bringing existing projects on board

The biggest addition is a method for projects that already exist. Most of our work has a history, and that history should not be rewritten to look tidy. The new guide and a set of audit tools measure how closely a project follows the standard, change nothing, and produce a prioritized plan of what to fix, what to convert and what to accept as history. The standard applies from an agreed starting point; earlier differences are recorded openly, with the reason.

First results on uSense

The uSense wireless sensor platform was the first project to be brought under the updated governance. More than 150 existing tickets, its change history, version tags and project board were migrated without rewriting any history, and the differences that remain are documented with reasons. Its first release under the new process was versioned and recorded by the automation. The migration was planned and carried out step by step, with an AI tool assisting and the engineer reviewing and approving each step.

On the hardware side, AI-assisted analysis has also shortened several investigations of the sensor board. It produced a first-pass design review, helped narrow down the cause of a communication fault between on-board sensors, and listed likely causes of lower-than-expected radio range, together with the measurement needed to confirm them. The communication fault was confirmed on the bench, and the range analysis is awaiting measurement. In each case, AI shortened the path to a hypothesis, and engineers and bench tests make the final call.

What's next

We will bring our other projects onto the updated standard, and the standard will keep evolving through the same ticket process it describes. We welcome feedback on the published guides.