ScenarioRecursive AI development change control

Self-Modifying System Verification Engineer

Also called Self-Modification Verification Specialist

A Self-Modifying System Verification Engineer would check that stated safety properties hold as AI systems change their own software. The role depends on how AI develops, and would only matter if automated research reaches consequential speed.

What they do

They would take a set of stated invariants, such as limits on permissions, oversight hooks and evaluation integrity, and design the checks that confirm those hold after each authorised change. They would combine formal methods with empirical testing, decide which changes need which level of scrutiny, and build gates into the release path. They would read diffs produced by automated systems, probe for ways a change could weaken a boundary, and write up findings for independent reviewers. They would also maintain the record of what was checked and why.

What a strong hire delivers

A strong hire would first turn vague safety intentions into a short list of invariants that can actually be tested. They would then deliver a working verification process for a changing system, with clear pass and fail criteria, a defined route for escalation, and evidence that reviewers outside the team can inspect and trust.

How you can tell they are good

Ask them to take one invariant and explain how they would verify it across a series of changes they cannot fully predict. Strong people state what the check cannot prove. They separate formal guarantees from empirical confidence, and they describe how the checker itself is protected from the system it checks.

Why it is hard to fill

If this role emerged, nobody would hold the title, so recruiters would be matching on adjacent experience. The work sits between release engineering, control research and governance, and few people have done more than one. Candidates who combine rigorous verification habits with real knowledge of AI failure modes would be scarce, and most would be happy where they are.

Where to find them

Today they would come from release engineering and reliability teams at companies running complex deployments, from distributed systems engineers used to reasoning about change under failure, and from AI control and evaluation groups. Others would come from frontier governance and assurance teams, and from formal methods groups in safety-critical software.

Interview questions for a Self-Modifying System Verification Engineer

  1. Describe a release gate you built or tightened. What did it catch, and what did it miss?

    Look for a concrete example with honest account of misses. A strong answer covers how they measured the gate's value and what they changed afterwards. Be wary of claims that the gate was complete or never failed.

  2. How would you decide which invariants are worth verifying when a system changes faster than humans can review?

    Strong answers rank invariants by consequence and by how checkable they are, and accept that some need human review. Worry if they try to verify everything or have no way of prioritising.

4 more questions, with what a strong answer covers, are in the Role Kit.

Job description you can post

We are building controls for AI systems that can change their own software. You would define what must stay true through those changes and build the verification that shows it does. You would work with engineering, safety and independent reviewers, and be honest about what the checks can and cannot show.

What you will do

  • Turn stated safety properties into testable invariants
  • Design formal and empirical checks for authorised system changes
  • Build verification into the release path with clear pass and fail criteria
  • Review automated changes for weakened boundaries
  • Document evidence for independent reviewers
  • Escalate and record decisions on uncertain changes

What you will bring

  • Demonstrated work on release gates, verification or change control for complex systems
  • Experience reasoning about distributed systems under change
  • Working knowledge of how AI systems fail or evade checks
  • Ability to state clearly what a check does not prove
  • Clear written communication with technical and non-technical reviewers

Nice to have

  • Experience with AI control or evaluation work
  • Background in formal methods
  • Exposure to frontier governance or assurance processes

Free to use and adapt. If it saves you time, a link back to this page is appreciated.

Depends on a scenario

Rapid automated AI research and recursive change

What AI would need to do
Automated AI research repeatedly improves systems at consequential speed and scale.
What organisations would need to decide
Developers retain controlled release, independent review and enforceable change boundaries.
What would rule it out
Compute, experiment, evaluation or integration bottlenecks prevent rapid compounding gains.

We give no date. The role becomes real if both conditions hold.

Skills that matter

  • AI controlAdvancedLimit harm from potentially untrusted AI behaviour
  • AI governance and assuranceAdvancedAssign accountability and verify lifecycle controls
  • Distributed systemsWorkingDesign reliable work across networked machines
  • Frontier scenario analysisWorkingExplore conditional outcomes without claiming predictions

Other roles in recursive AI development change control

ScenarioRecursive Improvement Change-Control ArchitectA Recursive Improvement Change-Control Architect would define enforceable limits on fast, automated changes to AI systems. The role depends on how…ScenarioAutomated AI Research Assurance LeadAn Automated AI Research Assurance Lead would challenge the evidence coming out of heavily automated AI development. The role depends on how AI…ScenarioCapability Acceleration Monitoring SpecialistA Capability Acceleration Monitoring Specialist would watch for evidence that AI systems are improving unusually fast through automated research. It…

Related roles in other families

ScenarioGeneral-Purpose Autonomy Assurance ArchitectGeneral-purpose autonomy assuranceA General-Purpose Autonomy Assurance Architect would design how an organisation gains justified confidence in systems given broad, consequential…ScenarioCross-Domain Capability Certification DesignerGeneral-purpose autonomy assuranceA Cross-Domain Capability Certification Designer would define what a general-purpose AI system can credibly be said to do across consequential…ScenarioAutonomous Delegation Accountability OfficerGeneral-purpose autonomy assuranceAn Autonomous Delegation Accountability Officer would keep track of who authorised what when AI systems carry out broad work. The role depends on…ScenarioGeneral-Purpose System Decommissioning PlannerGeneral-purpose autonomy assuranceA General-Purpose System Decommissioning Planner would prepare the controlled withdrawal of autonomous systems that run deeply inside an…

How we wrote this

Role definitions are our own editorial work, checked against occupational classifications, standards, research and employer pages. Titles vary by company, and this is a description of the work, not a job advert. Scenario roles describe responsibilities that depend on stated conditions; they are not forecasts.

← Recursive AI development change controlAll new job families

Start a search

Hiring a Self-Modifying System Verification Engineer?

Tell us the work. We find the people already doing it, whatever their job title says, and you meet them already interviewed for your role.