# #020 artifact verification record

Date: 2026-09-22. Artifact: **RTS Group Orders Lab 1.0.0**. Article: [RTS crowd movement in Godot](https://vav-labs.com/blog/rts-crowd-movement-in-godot/).

## Result

**31 named checks passed in each of three canonical PathForge runs, and again after clean extraction of the source ZIP.** One named check exhaustively compares all 512 three-by-three bipartite graphs with a brute-force oracle. It is counted once, not as 512 extra tests.

The source ZIP is a standalone Godot project. Verification uses real NavigationAgent2D movement and separate state reporting.

## Runtime protocol

Engine: official Windows Godot **4.7.2 stable**, build `ed1daf0bf`. Rendering capture: Compatibility OpenGL, NVIDIA GeForce RTX 3060. No hardware performance comparison was conducted.

```sh
godot --headless --path . --fixed-fps 60 --script res://tools/verify_rts_group_orders.gd
godot --path . --fixed-fps 60 --rendering-method gl_compatibility --script res://tools/capture_rts_group_orders.gd
godot --path . --fixed-fps 60 --rendering-method gl_compatibility --script res://tools/capture_rts_group_orders.gd -- --baseline
```

The executable is the Godot console binary on Windows. The tests need no editor import, plugins or network access. `--fixed-fps 60` supplies fixed simulation steps and can execute faster than real time. Tick counts are observations, not benchmark timings.

| Setting | Value |
| --- | --- |
| Physics steps | 60 per simulated second |
| Body radius / navigation bake radius / avoidance radius | 10 / 12 / 11 |
| Maximum requested speed | 150 |
| Near-goal speed cap | `distance * 6.0` |
| Arrival tolerance | 3 |
| Settling condition | Observed speed below 2 for 0.15 seconds |
| Candidate spacing | 30, from radius, tolerance and margin |
| Default candidate count | 25 before projection/filtering |
| Maximum projection distance | 18 |
| Progress threshold / stall time | 0.5 route-distance units / 3 seconds |
| Runtime observation limit | 1,500 ticks |
| Default validation-query cap | 4 per physics tick |
| Target-write cap | 2 per physics tick |
| Planning retries | At most 2 |

The low-budget fixture sets validation queries to one per tick. A maximum of one validation query and two target writes was observed. Agent-internal searches are not instrumented. There is no claim about total engine query count or milliseconds per tick.

## Observed outcomes

All three canonical runs produced four arrivals in the open-yard fixture and four in the parked-group fixture. The wall-detour member arrived. The disconnected shared-target member reported `BLOCKED`, despite its navigation being finished. The forced nonprogress fixture reported `STALLED`.

Two opposing groups at the narrow gate produced **three arrivals and one stalled member** in each canonical run. This check passes when terminal states report what actually happened. It doesn't require or claim guaranteed throughput.

The screenshot capture is a separate eight-body run. The supplied allocation image records eight arrivals. The supplied shared-target image records eight stalls and no arrivals. Earlier development captures also produced one arrival and seven stalls. Counts from those older images aren't substituted into the final screenshot or draft. Avoidance is sensitive to execution details, and this comparison isn't a statistical experiment.

## Mapping the original proof plan

| Plan IDs | Evidence / implemented scope |
| --- | --- |
| P01, P02 | Finite candidate spacing, real four-body arrival tolerance, retained separated claims, post-projection boundary deduplication |
| P03, P10 | A real nonempty disconnected path ends 162 units short, validation rejects it, baseline agent reports blocked rather than arrived |
| P04 | Constrained-pair example plus exhaustive three-by-three matching oracle |
| P05 | Four members and one candidate produce one claim and three waiting states |
| P06, P09 | Concurrent plans share the spatial registry, parked first group retains claims while the second arrives, differing IDs cannot bypass spatial exclusion |
| P07, P08 | Stale plan and queued target are rejected, removed member releases its claim and surviving member is replanned |
| P11 | Pending pairs remain planning when budget is exhausted, validation queries and target writes are counted separately |
| P12 | Route-distance helper and real wall detour avoid a false straight-line-distance stall |
| P13, P14 | Fresh unsynchronized map produces no projected candidates, readiness fence prevents commit, real region disable changes map iteration and rejects stale plan, physical occupancy is rechecked |
| P15 | Actual arrival tolerance is checked, inactive and replacement-time callbacks cannot move the body, forced nonprogress cannot become arrival |
| P16 | Two groups approach the narrow gate from opposite sides, observed stalls remain stalls |

P15 does **not** claim support for externally displacing an already-arrived member. Arrival is latched in this static fixture. P11 was narrowed from the v1 proposal's “execution queries” to the instrumentable target writes. The implementation doesn't count automatic agent repaths. Both limits are stated in v2.

The visual display shows bodies, accepted claims, active paths and state counts. It doesn't implement a complete per-candidate projection inspector or a separate cancelled-state panel. Replaced work is invalidated with revisions and covered by the verifier.

## Implementation findings used in v2

- A nonempty route was insufficient evidence of pair feasibility on the disconnected map.
- Full-speed approach produced near-slot oscillation during development. Proportional approach speed removed the observed open-yard failure.
- The matching helper now tries an unowned edge before moving an existing assignment. It still supports augmenting paths and passed the exhaustive cardinality check.
- Valid destinations didn't eliminate a narrow-gate stall. The draft treats traffic policy as separate work.
- Callback tests are fault injection at the engine-loop boundary, not proof of arbitrary asynchronous response ordering.


## Downloads and receipts

- [rts-group-orders-v1.0.0.zip](rts-group-orders-v1.0.0.zip)
- [canonical-run-1.json](canonical-run-1.json)
- [canonical-run-2.json](canonical-run-2.json)
- [canonical-run-3.json](canonical-run-3.json)
- [clean-extraction-verification.json](clean-extraction-verification.json)
- [rts-group-orders-proof-capture.json](rts-group-orders-proof-capture.json)
- [rts-group-orders-baseline-capture.json](rts-group-orders-baseline-capture.json)
- [README.md](README.md)

[SHA-256 manifest](manifest.json)
