NH Applied / ACE K2 / Governed Autonomous Engineering System

ACE K2 - Governed Autonomous Engineering on Local Hardware

Most AI agents are allowed to mark their own homework. We built one that isn’t.

ACE K2 is a governed autonomous engineering system developed by NH Applied. Give it an engineering goal and its local AI foreman works out how to achieve it on real hardware.

The important difference: the AI doing the work is not the authority that decides whether the work passes.

Latest validated engineering result

Microsoft WSL #40988 / ROCm WSLC causal validation

ACE K2 independently tested AMD ROCm GPU access for Windows Subsystem for Linux Containers on physical AMD Ryzen AI MAX+ 395 / Radeon 8060S (gfx1151) hardware.

GPU projection: PASS 3/3 With matched WSL-aware ROCm userspace, --gpus all produced successful HIP compute; the no-projection control failed HIP initialisation 3/3.
DXG backend: PASS 3/3 With /dev/dxg present, enabling the DXG backend succeeded 3/3; disabling DXG backend detection failed 3/3.
WSLC GPU projection -> /dev/dxg -> ROCDXG/HSA/HIP userspace -> real HIP compute -> controlled A/B isolation

The evidence supports /dev/dxg with WSL-aware ROCDXG/HSA/HIP userspace as the working path for the tested Strix Halo configuration. Native Linux /dev/kfd passthrough was not required, and no Microsoft source patch was required by the tested configuration.

Scope: tested Strix Halo / gfx1151 environment only. This is not a claim of universal compatibility across AMD GPUs or application workloads.

NH Applied Technical Summary Permanent Evidence Record Microsoft WSL #40988

Earlier validated engineering result

ROCm Windows #12571 - physical gfx1151 validation

ACE investigated ROCm/rocm-systems issue #12571 on a physical AMD Ryzen AI Max+ 395 / Radeon 8060S (gfx1151) Windows system. It recovered matched TheRock / rocm-systems source provenance, built pristine and patched Windows HIP runtimes, produced a patched amdhip64_7.dll, and executed a controlled six-cell A/B test with SDMA still enabled.

Pristine: STALE 50/50 The failing read cell reproduced deterministically; the five controls remained clean.
Patched: 6/6 clean All six cells were clean 50/50, including the previously failing read path.
public defect -> source provenance -> source modification -> Windows runtime build -> physical silicon A/B test -> independent evaluation -> reproducible evidence

Scope: Windows / Radeon 8060S / gfx1151 / matched TheRock 7.13-era runtime / governed #12571 reproducer. AMD has subsequently reported independent end-to-end validation of its upstream implementation on gfx1201.

Read the #12571 Case Study ROCm Issue #12571 AMD Upstream PR #12952
ACE K2 Capabilities Paper Project Overview

What ACE K2 does

1

Understands the goal

The local AI foreman researches the problem, plans the work and chooses how to proceed.

2

Finds or builds capabilities

It can use existing tools, identify what is missing, and create or acquire new tools when required.

3

Independent controls check it

Separate controls qualify tools, validate outputs, preserve evidence and decide whether the work is acceptable.

4

Recovers or escalates

ACE attempts bounded local recovery first. If that fails, it can escalate for cloud supervision and continue locally.

The result: the AI is free to solve problems, but it is not free to mark its own homework.

Demonstrated, not hypothetical

6 / 6 governed-autonomy core demonstrations
88 / 88 autonomous KiCad validation checks, with zero ERC violations
23 / 23 checks in an AMD-focused research and engineering project
26 / 26 current-web discovery checks

ACE K2 has also demonstrated exact paged reconstruction of a 1.6 MB artifact, long-running orchestration, bounded recovery and capability creation followed by qualification before use.

Why separate the AI from acceptance?

A capable model is useful because it can reason creatively about an unfamiliar problem. The same flexibility is a poor substitute for engineering authority. ACE therefore separates the system that proposes actions from the controls that determine whether tools are trusted, evidence is sufficient and the final result has actually passed.

Public disclosure boundary. The white paper describes the architecture and demonstrated capabilities without publishing reconstruction-enabling implementation details such as complete schemas, prompts, state-machine logic, recovery triggers, transport bindings or executable build sequences.

Read the current capabilities paper

ACE K2 White Paper v1.2 — Current Capabilities Edition
Nigel Hutchinson / NH Applied · September 2026

Open on Zenodo NH Applied ACE K2