A DTU Inside a DTU

how Reality-Check learned to test itself

The Frame

Agents say “done” when it isn’t — Reality-Check closes that gap.

Amplifier’s Reality-Check bundle captures what the user actually wanted, derives verifiable criteria, and “tests the result in a Digital Twin Universe environment so that ‘done’ means done.”

So the promise is real testing in a disposable sandbox. Is it actually shipped?

The Proof

It isn’t a mock — it’s a shipped bundle built ON DTU sandboxes.

Reality-Check depends transitively on the Digital Twin Universe bundle (which itself depends on Gitea) — a real testing tool standing on real disposable sandboxes, present in main.

Real, and in main. So what was the one thing it couldn’t test?

reality-check → digital-twin-universe → gitea
Repo created 2026-04-14, last pushed 2026-07-09
Also pulls browser-tester + terminal-tester

The Tension

The one thing it couldn’t test was itself.

Reality-Check’s own stack IS a container full of containers — Incus as the inner container runtime, Docker Engine for inner Gitea and sidecars — and a plain container can’t cleanly launch the containers it needs to test.

A testing tool with a self-referential blind spot. So how do you point it inward?

Incus — inner container runtime
Docker Engine — inner Gitea + mock sidecars
To test itself, this stack must run inside a DTU

The Mechanism · 1 of 2

The fix: let a DTU host its own DTU.

The reality-check-in-incus profile sets security.nesting: "true" and makes the inner default profile privileged, so the outer DTU can itself launch inner DTUs and run the reality-check pipeline.

The blocker is gone. But can you actually see the nested loop working?

# profile base.config
security.nesting: "true"

# provision
incus admin init --minimal
incus profile set default \
  security.privileged=true

# header: "the DTU can itself launch
# inner DTUs (DTU-in-DTU)"

The Mechanism · 2 of 2

The loop closes when the inner UI is proxied up to the host.

The inner DTU binds its chat UI on port 8410 to the outer DTU’s localhost, and an access.ports block forwards it up to the host — validation you can actually see from outside the nest.

The nested loop is now observable end-to-end. Now make it repeatable.

# access.ports (outer DTU -> host)
- host:      ${HOST_PORT}
  container: 8410
  label:     "Inner Chat UI"
  path:      /chat/
  verify:    false

The Turn

One script drives the whole self-validation, launch to artifacts.

run-reality-check-validation.sh — added in commit 0800490 (2026-04-22) — turns the manual blocker into a single automated, repeatable run.

A manual dead-end becomes one repeatable command. So what does that unlock?

Launch the outer DTU
Wait for readiness
Run the reality-check-pipeline recipe inside
Pull out /root/home + /root/.amplifier/projects

The Payoff

It now validates itself — and that self-test is a loop you can aim at anything.

Because the same reality-check-pipeline checks any software via browser, cli, or other validators, once it can validate itself it can be pointed at anything.

Self-validation proves the loop; the loop generalizes.

4

software types: web_app · cli_tool · api_service · library

3

validator types: browser · cli · other

5

agents in the bundle

3

recipes, incl. reality-check-pipeline

The Takeaway

A tool that can honestly test itself is one you can trust to test everything else.

Self-validation isn’t a stunt — it’s the proof that the testing loop actually holds. Prove it on itself first; then aim it at the rest.

Sources

Research Methodology

Data as of: 2026-07-21 (independently verified by fresh git clone + gh repo view)

Feature status: Shipped / present in main

Primary sources: microsoft/amplifier-bundle-reality-check, microsoft/amplifier-bundle-digital-twin-universe, bkrabach/reality-check-greeting-app

Commands run:

gh repo view microsoft/amplifier-bundle-reality-check --json createdAt,description,pushedAt (created 2026-04-14, pushed 2026-07-09)
git show 0800490 --stat — “feat: add local validation workflow for reality-check” (2026-04-22; 5 files, 676 insertions)
cat profiles/reality-check-in-incus.yaml — confirmed security.nesting:"true", privileged default, port-8410 access.ports
head scripts/run-reality-check-validation.sh — launch → readiness → amplifier run → file-pull
cat README.md && ls agents recipes — 4 software types, 3 validator types, 5 agents, 3 recipes

Primary contributors: DavidKoleczek (reality-check bundle + self-validation workflow, commit 0800490); bkrabach (greeting-app fixture, PRs #8/#7/#6)

Gaps / scope: No live end-to-end run was executed (profiles require Incus/Docker + provisioning + an API key). All claims are grounded in source/commit inspection. The causal phrase “a container can’t cleanly launch the containers it needs to test” is an editorial summary of why nesting/privileged are required, not a literal commit message.