PhD Position: World Models for Software Architecture Synthesis

Constructor Labs; Bremen; On-site; EUR 48,000 - 60,000; Full time

Job summary

Constructor Knowledge Labs (CKL), in collaboration with Constructor Technology, invites applications for a PhD position in machine learning for software engineering and formal methods, on the Constructor Fabric project. You will work on turning informal knowledge into production software with gears and a World Model for architectural decisions.

The role emphasizes formal skeletons, DSL design, and architecture synthesis as inverse problems, with emphasis on rigorous experiments and explicit

Qualifications

• MSc in computer science, mathematics, or a mathematical natural science.
• Coursework in compilers, programming-language theory, language design or model-driven engineering is a strong positive signal.
• Evidence of finished projects: open-source repo, peer-reviewed publication, or notable competition result.
• Fluent technical English.
• Habit of stating assumptions explicitly and designing falsifiable experiments.

Responsibilities

• Formal skeleton and composition - GearSpec contracts and AppGraph.
• Architecture synthesis as an inverse problem with constraint solving and MCTS.
• DSL design and language engineering for the gear DSL and glue layer.
• Local transition models and pipeline surrogates for fast prediction.
• Data work reconstructing spec-to-architecture pairs from repositories and synthetic generation.

Skills

Fluent English

Probability and statistics

Model-driven engineering

Education

MSc in computer science or mathematics

Job description

Supervisor: Prof. Dr. Alexander Tormasov

About the Position

Constructor Knowledge Labs (CKL), in collaboration with Constructor Technology, invites applications for a PhD position in machine learning for software engineering and formal methods, on the Constructor Fabric project.

Constructor Fabric turns a company's informal knowledge into production software through a pipeline of composable capability units called gears: requirements -> architecture -> product fit -> framework (G1) -> application -> runtime. We are building a World Model over that pipeline - a model that does not just generate code, but predicts the consequences of an architectural decision: total cost of ownership, unintended side effects, latency and failure behaviour, and whether a proposed composition is even admissible.

The central object is not a digital twin of the application but its formal architectural skeleton: gear contracts (GearSpec), a typed attributed hypergraph of the application (AppGraph), a composition algebra that defines which assemblies are legal, and several semantic projections (types, protocols, resources, security) over which properties are proved, refuted by counterexample, or reported as an explainable gap. All of it is written in a domain-specific language whose syntax trees and graphs we keep in a projectional editor (JetBrains MPS) - so the DSL is not a convenience layer, it is the thing that defines the model's state space and the boundary of what the model is allowed to propose.

What you will work on

Depending on your background, one or two of:

Formal skeleton and composition - GearSpec as a contract $(Requires, Provides, State, Effects, Assumptions, Guarantees, Parameters)$; AppGraph as a typed attributed hypergraph; an algebra of assembly (sequential, parallel, feedback, refinement); semantic projections and system-level invariants over trajectories.

Architecture synthesis as an inverse problem - given a specification, load and constraints, find the composition of gears that realises it. Constraint solving and MCTS as the baseline; a learned transition/value model for ranking and pruning; LLM proposals treated strictly as candidate hypotheses that a DSL parser, type checker and property checks must then admit or reject.

DSL design and language engineering - the gear DSL and its glue layer decide which AppGraphs are expressible at all, and therefore where the search space ends. This thread covers the abstract syntax and static semantics of that DSL; the requirement that an architectural decision be unbypassable by construction (you must not be able to wire authentication around the Auth Resolver); what happens to the language when gear contracts change or a 201st gear is added; projectional representation of graphs with cycles; and the open hypothesis that a specialised G1-DSL is generated together with every G1.

Local transition models and pipeline surrogates - fast approximate predictors for single pipeline steps (spec change -> code quality, architecture -> product fit, app -> runtime outcome), with calibrated uncertainty, validated against real telemetry.

Data - reconstructing (specification -> architecture) pairs from open repositories at scale, plus synthetic project generation from a fixed gear set and DSL grammar to cover rare transitions, gaps and counterexamples.

Profile

MSc (or equivalent) in computer science, mathematics, or a mathematical natural science.

Coursework in compilers, programming-language theory, language design or model-driven engineering is a strong positive signal, half of this project is deciding what a formal architecture description is allowed to say.

Evidence that you finish things: a maintained open-source repository, a peer-reviewed publication, or a strong competition result.

Fluent technical English.

Most importantly: the habit of stating an assumption explicitly and designing an experiment that could falsify it.

Required mathematical background

Core skills:

Probability and statistics. Estimation, Bayesian inference, uncertainty quantification and calibration (proper scoring rules, reliability diagrams, ECE), experiment design and signifi