You don't need to be a part of any particular domain to effectively audit code.
It can be difficult to critique choices, specially in system architecture, when domain requirements are presented or falsely asserted as 'dictating the choice', but this can be addressed by directing conversations with stakeholders to nail down the conceptual model that has been implemented in architecture style x, and then the conversation is on more equal footing.
Auditing language usage, libraries, development process, etc. are much less domain specific.
They wouldn't have to understand any of it, just be able to identify where and when changes occurred, for later review for any last minute shenanigans.
I'm not personally convinced this whole incident even happened, but if it did, this is what I think would make sense.