The contract defines the desired topology and never the observed one: what the permutation suite compares, and when it has looked long enough, are undefined

[stephrobert]

The milestone's invariant says two API histories reaching the same desired topology must leave "the same observable runtime". #728 implements the comparison and states, in its own "Not established", that the sentence it compares by does not exist yet:

Observable equivalence needs a definition before the suite compares. Two guests with the same routes and different metrics, or the same resolver set in a different order: equivalent or not is ADR-0004's sentence, and the suite implements the sentence.

That sentence has no owner, no acceptance criterion and no file. #723 writes ADR-0004 on the desired side, "topology outranks event order". The observed side is a different decision, and it decides what the permutation suite is allowed to call a difference.

Without it the suite has two failure modes, and both look like success:

• too sensitive: an Incus-generated UUID, a route listing order or an interface name moves, the witness differs, and a green runtime reds. The suite gets weakened by hand, scenario by scenario, until it compares nothing;
• too normalised: metrics, resolver order and route counts get flattened to make the first problem go away, and a real divergence, exactly the shape of A private machine gets no way out when push_default_route is enabled after the attachment, only when it is set at creation #678, passes.

What this issue delivers

A normative section, cited by ADR-0004 rather than restating it, that answers three questions.

1. What the witness carries. Per effect of the Runtime Contract table, the fields that are semantic:

machine        exists · running · usable when usability is claimed
interface      role · addresses · segment membership
route          destination · gateway · interface · metric where significant
resolver       effective resolver set · resolution actually works
reachability   source · destination · protocol · port · allow/deny
firewall       enforcement observed, not rule text
balancer       VIP · accepted backends · traffic delivered
ownership      feint-owned objects · foreign objects untouched

2. What is normalised away, and named. Incidental detail that must never make a witness differ. The list is normative, not illustrative, and anything absent from it is semantic by default:

object identifiers the runtime generates
JSON key ordering
route listing order
interface names where the role is what matters
timestamps

The default matters more than the list: a field nobody classified is compared, so a new field cannot become invisible by being forgotten.

3. When the observation is taken. The contract must not contain a fixed sleep N. With OVN, DHCP, cloud-init and systemd-networkd in the path, a duration is a guess about a machine, and the guess is what four red nights were made of.

act
  ↓
poll an observable condition
  ↓
stable for a stated window   →  settled
or deadline reached          →  did-not-converge

The three verdicts are distinct, and the suite must never collapse them:

verdict	means	what it is not
deny	the effect was observed to block	not a timeout
did-not-converge	the deadline passed without a stable reading	not deny
unreadable	the observation itself failed	not absence

This is the difference that makes a firewall witness worth anything. A TCP connection that times out because the guest has not finished booting proves nothing about a rule, and today nothing in the suite separates the two.

Why it is its own issue and not a paragraph in #723

ADR-0004 answers "which side wins when the event order and the desired topology disagree". This answers "when are two runtimes the same, and when have we looked long enough". They cite each other; neither contains the other. #728 implements what this one defines, and its "Not established" bullet is what this issue closes.

Not established

• The stability window and the deadline per effect. They are measured, not chosen: the first runs of No suite drives the same desired topology in two orders, so an order-dependent runtime is green everywhere: tools/runtime-conformance/ and the permutation property #728 and Every runtime witness is taken once, after creation: a property proved at Day-0 is never re-proved after stop/start, reboot, a Day-2 change or destroy #729 give them, and this issue records the numbers rather than proposing them.
• Whether metric is semantic in every mode. Two guests with the same default route and different metrics may or may not behave the same, and the answer may differ between incus and incus-ovn. The section states the rule per mode, and an unmeasured mode says so.
• The cost of polling against the runtime leg's current 32 minutes (2026-09-07). Polling is cheaper than a fixed sleep on the happy path and more expensive on the failure path; No suite drives the same desired topology in two orders, so an order-dependent runtime is green everywhere: tools/runtime-conformance/ and the permutation property #728 measures it.