A synthetic probe stand for customer-written declarations: the pre-written criterion failed, a revised one passed
Under the pre-written criterion, 23 of 25 mandatory rows were exercised and both declarations were blocked; 25 of 25 only under a criterion revised after the first run, which added an owner control and a path-binding check.
Prediction failedHow we measureWorking note
- Designed for
- To test whether a synthetic provider generated from a guard declaration, driven through the real HTTP gateway, exercises every mandatory protection probe of each action with zero rows not exercised.
What was tested
For two shipped gateway declarations with 25 mandatory rows, a test-only stand built an in-process provider from each declaration and drove it through the real HTTP gateway. Each action got a positive control and four kinds of negative probe: no reads, an invented id, a foreign root, a foreign-owner object. Success meant the exact journal reason code. The criterion was written before the prototype; a Codex agent did the work.
What we observed
The pre-written criterion failed. In run 1, 4 controls reached the provider, 19 negative probes worked, 2 were not exercised and 0 passed through, so both declarations were blocked. With an owner control, a path-binding check and a revised criterion, 25 of 25 rows met it. A composite weakening reached the provider and the decision table blocked it.
What this means for Heimdall
The stand caught a protection switched off. Its failed criterion means two intended protections went unshown, not that a request got through: another rule refused first. This bears on the delegate’s declaration.
Limits
The revised criterion came after run 1, for exactly the failing rows. One foreign-owner row shows read isolation, not ownership. Two of eight gateway domains; not wired into product connection.
What remains open
Cover other domains and GraphQL; wire the probes into connection.