Presenting the Quantum Core Architecture at DevConf 2026

AI systems are exceptionally good at making a first impression. A well-chosen generation, a fluid conversation or an asset produced in seconds demonstrates potential immediately. Engineering work begins when that capability has to be repeated by dozens of people, integrated into existing tools, audited, versioned and executed again weeks later without depending on the memory of the person who assembled the demonstration.

That second problem is what the Quantum Core architecture aims to place at the centre of the presentation. In production, value does not come only from the maximum quality of an output. It comes from the relationship between quality, time, cost, predictability and the ability to intervene. An excellent model that cannot preserve visual identity, trace sources, reproduce a decision or fit an approval pipeline may be less useful than a technically more modest system that remains controllable.

The session is therefore a discussion about systems. Models remain important, but they cease to be the entire architecture. Work queues, context storage, approval rules, versioning, observability, security policies, quality metrics and interfaces simple enough for artists and designers to use without understanding the full underlying infrastructure all become part of the picture.

The central principle is to decouple a creative request from any specific provider or model. A user describes a task — review a localisation, generate a variant, analyse an asset, produce a code suggestion — and the system transforms that intent into a structured job. The job carries context, authorised assets, parameters, workflow version and output criteria. Only then does a routing policy decide which tool or model should execute each stage.

That separation reduces technological dependency. Models can change quickly; studio pipelines should not need to be redesigned with every release. If the interface between production and inference remains stable, a component can be replaced, compared or executed on different hardware without changing the way the team works.

It also enables mixed approaches. A single task may use computer vision to classify an asset, a language model to structure recommendations and deterministic tools to validate dimensions, naming or formats. Calling all of this simply 'AI' obscures the most important point: each component has different guarantees, costs and failure modes.

As AI-assisted content enters production, teams need to answer basic questions: which files were used as references, which model produced the current version, which prompt or configuration was applied, who approved the result and what manual changes happened afterwards. Without that chain, content becomes difficult to reproduce and even harder to audit.

The proposed architecture treats provenance as first-class metadata. An output is not merely an image, a piece of text or a clip; it is an artefact accompanied by a minimal production history. That history can remain connected to the system even when the final file is exported to Unity, Unreal, a DCC or another internal repository.

The benefit is not only legal or administrative. Provenance improves engineering. When a regression appears, workflows can be compared. When a result is particularly strong, the team knows which configuration produced it. And when a model has to be retired, it becomes possible to identify which assets depend on it.

It is easy to say that a system includes human oversight. The challenge is specifying where that oversight occurs. Not every task needs the same approval. A naming suggestion may be applied automatically; a change to main dialogue may require a writer; a facial modification may require art direction; a code change may need review and tests before reaching the main branch.

The workflow should therefore carry explicit risk levels and gates. The system can allow automatic execution for reversible, low-impact tasks, request approval for significant visual transformations and block operations that exceed permissions. The policy should be configurable per project, because the same model may be suitable for prototyping and unacceptable for a final asset.

The purpose is not to create digital bureaucracy. It is to make visible where human judgement forms part of the definition of quality. Once that is encoded, teams can increase automation without losing responsibility.

Models change, drivers change, dependencies change and prompts are adjusted. In non-deterministic systems, a small modification can improve one group of cases while degrading another. Without reference datasets and repeatable metrics, organisations discover regressions only when an artist notices that 'things feel different'.

Quantum Core's proposal is to treat evaluation as part of deployment. Relevant workflows maintain reference examples, acceptance thresholds and comparisons between versions. For visual tasks, that can involve structural, quality and consistency metrics combined with human review. For text, it can include terminology, format, instruction adherence and adversarial cases. For code, compilation, tests and static analysis continue to take precedence over any subjective model assessment.

No single metric defines artistic or editorial quality. The role of the system is to detect change, make deviations visible and reduce the volume of work that has to be reviewed blindly. The final decision remains tied to the purpose of the asset.

Studios have years of investment in version control, DCCs, engines, naming, scripts, approval processes and internal tools. An architecture that requires replacing all of that before AI can be adopted creates unnecessary risk. The strategy presented favours modules that enter at points where there is measurable benefit and return results to the systems the team already uses.

That means working with adapters and clear contracts. One module may receive assets from a watched folder, an API or a DCC extension; another may send results to a review queue; a third may only produce metrics. Adoption stops being a single migration and becomes a sequence of small integrations that can be evaluated independently.

This approach is especially important in an area where technology moves faster than game-production cycles. Infrastructure needs to outlive individual models. Otherwise, every technological improvement restarts the integration curve.

Rather than presenting a feature list, the session is intended to discuss architectural choices that remain open across the industry: when local inference justifies its hardware cost; how privacy and observability should be balanced; which data should be retained to reproduce a generation; how models can be compared without turning benchmarks into artificial objectives; and how far automation can be introduced without impoverishing authorship.

There is an organisational question as well. AI crosses disciplines that have historically worked with different tools and metrics. Art, narrative, localisation, engineering and production need a common language for discussing quality, risk and approval. An orchestration platform is useful only if it makes that communication clearer rather than adding another opaque layer between teams.

This is where a technical conference has the greatest value: not as a stage on which to declare problems solved, but as an environment in which implementation decisions can be tested against teams working under different constraints. The maturity of an architecture is also measured by the quality of the questions it is capable of supporting.