ScenarioRecursive AI development change control

Recursive Improvement Change-Control Architect

Also called Recursive AI Change Controller

A Recursive Improvement Change-Control Architect would define enforceable limits on fast, automated changes to AI systems. The role depends on how AI develops, and only matters if automated research speeds up at consequential scale.

What they do

The work would start from one question: if automated research were changing a system many times faster than people can read the changes, what must stop and wait for review? They would map where changes enter the pipeline and where checks could be bypassed. They would write boundaries that are enforceable in code and process, not just in policy. They would specify which capability changes need independent verification before release. They would define intervention requirements, such as pausing, rolling back or freezing a cycle. They would test those controls with engineers, evaluators and governance staff, and revise them as the automated process changed.

What a strong hire delivers

In the first months, a strong hire would deliver a clear change-control architecture for the conditions in the scenario. That means a map of change paths, a short list of consequential change types, and written intervention requirements engineers can build against. They would also agree who verifies what, independently of the team making the change, and show where today's release gates fall short.

How you can tell they are good

Ask them to take a fast automated improvement loop and show where they would place hard stops. Strong candidates separate routine changes from consequential ones and explain how verification stays independent. They know how controls get bypassed. Be wary of answers that rely on trust, speed-ignoring review steps, or policy documents with no enforcement mechanism behind them.

Why it is hard to fill

If this role appeared, people would be very scarce. Nobody holds this title, and the work sits between release engineering, control research and governance. Most candidates are strong in one area and thin in the others. Fewer still have worked on anything resembling automated, compounding change. We would expect to assess evidence of adjacent work rather than matching titles, and to accept that no one has done this exact job.

Where to find them

Today the likely sources are release engineers and infrastructure leads who have run gated deployments in distributed systems. Others come from AI control and evaluation teams at frontier labs or safety organisations. A third group works in frontier governance and assurance, in policy teams, auditors or standards bodies. Scenario analysts who stress-test how AI might develop would add useful range.

Interview questions for a Recursive Improvement Change-Control Architect

  1. Describe a release gate you built or tightened. What did it block, and how did you know it worked?

    Look for a real gate, a clear failure it prevented and evidence of testing it. Strong answers admit weaknesses and bypass routes. Worry if they describe only process documents or cannot say how the gate was verified.

  2. How would you decide which automated changes to an AI system count as consequential?

    A strong answer links consequence to capability, scope and reversibility, and admits uncertainty. It proposes criteria that can be checked. Worry about a single fixed threshold or reliance on the changing system's own judgement.

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

Job description you can post

We are building controls for a future in which automated research may change our AI systems faster than people can review them. We need someone to define enforceable boundaries, verification requirements and intervention points, so consequential changes are independently checked before release.

What you will do

  • Map how changes enter and move through our automated development pipeline
  • Define which changes are consequential and need independent verification
  • Specify enforceable change boundaries that engineers can implement
  • Write intervention requirements for pausing, rolling back or freezing cycles
  • Test controls against bypass and failure scenarios with engineering and evaluation teams
  • Work with governance staff to keep review independent
  • Report where current release gates fall short

What you will bring

  • Demonstrated work designing or running gated release or deployment controls
  • Strong grounding in distributed systems
  • Experience with AI control, evaluation or assurance work
  • Ability to turn policy intent into technical requirements
  • Clear written communication of risk to engineers and leaders
  • Evidence of adversarial thinking about how controls fail

Nice to have

  • Experience in frontier AI governance or standards work
  • Scenario analysis or forecasting experience
  • Background in auditing or independent verification

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

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…ScenarioSelf-Modifying System Verification EngineerA Self-Modifying System Verification Engineer would check that stated safety properties hold as AI systems change their own software. The role…

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 Recursive Improvement Change-Control Architect?

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.