ACE K2 / Governed autonomous local AI

The AI proposes. The system decides.

ACE K2 is a governed autonomous local engineering system from NH Applied. A local AI foreman can research, plan, use tools and build missing capabilities, while separate controls retain authority over qualification, validation, recovery and acceptance.

Local-first
core operation without a per-token cloud API requirement
6 / 6
governed-autonomy core demonstrations
88 / 88
autonomous KiCad validation checks, 0 ERC violations
Strix Halo
AMD Ryzen AI MAX+ 395 demonstrated platform

A governed autonomous engineering system

ACE K2 is designed around a simple separation of authority: the model doing the work is not the authority that decides whether the work passes. The local foreman can investigate a goal, select tools, recover from bounded failures and escalate when necessary, but independent controls qualify capabilities and evaluate results.

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

What ACE K2 does

  • Understands a human goal, researches the problem and plans the work.
  • Uses existing tools or creates/acquires missing capabilities inside governed boundaries.
  • Requires qualification before a newly created capability is trusted operationally.
  • Separates execution from evaluation and final acceptance.
  • Attempts bounded local recovery before escalating for cloud supervision when needed.

Architecture in one view

Goal

A human supplies the engineering objective and success boundary.

Foreman

The local model researches, plans and proposes actions.

Tools

Qualified capabilities perform bounded work and preserve evidence.

Evaluation

Independent controls decide pass, recovery, escalation or terminal outcome.

Microsoft WSL #40988 / ROCm WSLC causal validation

ACE K2 independently validated AMD ROCm GPU access for Windows Subsystem for Linux containers on physical Strix Halo gfx1151 hardware. In controlled A/B testing with matched WSL-aware ROCm userspace, GPU projection using --gpus all produced successful HIP execution in 3/3 runs, while the corresponding no-projection control failed HIP initialisation in 3/3.

A second A/B isolated the backend path: with /dev/dxg present, DXG backend enabled succeeded in 3/3 runs, while disabling DXG backend detection failed in 3/3. The evidence supports /dev/dxg with ROCDXG/HSA/HIP userspace as the validated WSL GPU path rather than native Linux /dev/kfd passthrough. No Microsoft source patch was required by the tested configuration.

The claim is bounded to the tested Strix Halo gfx1151 environment and does not claim universal compatibility across AMD GPUs or application workloads.

Read the Microsoft WSL #40988 causal validation report DOI 10.5281/zenodo.23469296

AMD ROCm #12571 validation case study

ACE K2 independently built and physically validated a source-level correction for ROCm/rocm-systems #12571 on Windows gfx1151 / Radeon 8060S. Using matched TheRock/rocm-systems source provenance and the same build route, a forced-pristine build reproduced the targeted stale-read failure at 50/50, while the forced-patched build returned all six test cells clean at 50/50 with SDMA enabled.

The result is deliberately bounded to the tested Windows gfx1151 environment, matched source/runtime revision and governed #12571 reproducer matrix; it is not a claim of universal correctness across ROCm platforms or releases.

Read the ROCm #12571 validation report DOI 10.5281/zenodo.23267518

AMD Strix Halo / MIOpen case study

ACE K2 was applied to the existing public Windows/gfx1151 MIOpen Conv3d issue tracked as ROCm/TheRock #5845. The investigation reproduced a size-dependent failure boundary, isolated the failing backend path and produced a scoped experimental workaround candidate. ACE still terminated the formal evaluation as INCONCLUSIVE because repeated validation and numerical-equivalence testing against a declared tolerance were not completed.

This is a useful example of the intended governance model: a technically interesting result can be retained and published without allowing the system to promote it beyond the evidence available.

Read the MIOpen Conv3d technical white paper