Evidence

Provider Authenticity

Provider authority can be verified without transferring provider signing authority.

POC-002 moved provider authentication from shared-secret verification to Ed25519. The provider retained the private signing key. The Raspberry Pi verification boundary held only the public verification material.

Valid provider-signed authority was accepted. Modified, unsigned, stale, and improperly bound authority was denied. Provider unavailability failed closed. Replacing the configured trust anchor caused legitimate provider authority to fail verification; restoring the correct trust anchor restored acceptance.

Boundary: This does not establish security after arbitrary privileged compromise of the verification boundary or protection against privileged modification of its trust configuration.

Separate Provider

Physical provider separation did not require moving signing authority to the enforcement boundary.

SP-001 moved the provider and its Ed25519 private key onto separate infrastructure from the Raspberry Pi boundary. Provider outage prevented new provider-backed authority from being issued through the tested path, and restoration resumed operation without boundary restart or reprovisioning.

SP-002 replaced the legitimate provider with an unauthorized substitute occupying the expected service position. The substitute could reproduce the expected service representation, but authority signed with its unrelated key was not accepted by the unchanged boundary.

Boundary: These tests do not establish provider high availability, transport authentication, or security after arbitrary compromise of the enforcement boundary.

Disconnected and Persistent Authority

Disconnection, restart, power loss, crashes, and contention did not enlarge the tested authority.

The disconnected-authority series progressively added failure conditions to provider-issued single-use authority.

• POC-003: one provider-issued authority, one accepted use; replay and invalid variants denied.
• POC-004 / POC-004B: spent state survived process restart and tested abrupt power loss.
• POC-005: two overlapping spend attempts produced one acceptance and one denial.
• POC-006A: a crash after persistent spent-state commit but before the success response did not restore the consumed use after restart.
• WP2-T1: a crash before atomic replacement did not falsely consume the authority; retry completed and subsequent replay was denied.
• FLEET-017: two independently connected physical actuator endpoints contended for the same provider-issued single-use authority; one was accepted and one was replay-denied.

The common observed property was that adding the tested failure paths and competing requesters did not create additional uses of the provider-issued authority.

Boundary: These tests exercise documented fault points and configurations. They do not establish arbitrary distributed exactly-once execution, distributed consensus, or correctness across every possible storage and network race.

Physical Execution

Provider admissibility was carried into observable physical command paths.

ACT-001 through ACT-005 extended the software decision path to two XIAO ESP32-S3 servo endpoints. Each execution had a pre-declared expected outcome, with observed actuation or non-actuation used as the test oracle.

19/19 coordinated executions passed their defined oracle, covering accepted movement, denied non-actuation, mixed two-endpoint outcomes, dual acceptance, dual denial, shared-boundary outage, and restoration without endpoint resets.

Boundary: Software fields reporting actuator attempts or completion are telemetry, not independent mechanical sensors. Physical movement was separately observed during qualification, but these tests do not establish exactly-once mechanical execution. Later endpoint-local experiments add an independent electrical witness to the PWM command path.

Endpoint-Local Enforcement

Provider-established authority was verified and enforced at constrained endpoints without moving provider signing authority to them.

ESP-LOCAL-004 — Local Cryptographic Verification

A XIAO ESP32-S3 locally verified Ed25519 provider signatures before issuing the physical command. Altering signed device, context, action, nonce, or max_uses values caused verification failure. A valid signature produced by an unrelated provider key was rejected. An independent ESP32 witness observed the admitted PWM command.

The spent state in ESP-LOCAL-004 was volatile and did not survive reboot.

ESP-LOCAL-005 — Durable Local Consumption

Persistent single-use consumption moved onto the endpoint. The tested execution path required provider-signature verification and semantic checks, a matching usable persistent state, durable transition to SPENT, verification of that state, and only then physical command issuance.

At-most-once authority consumption was preserved across replay, reboot, full power loss, missing, corrupt, and truncated state, and the documented crash injections. Invalid persistent state failed closed rather than being interpreted as fresh authority.

An independent GPIO witness observed the electrical PWM command path.

The crash testing characterized behavior around the persistence and execution boundary. The published result does not treat the explicit nvs_commit() call itself as the universal persistence boundary.

ESP-LOCAL-006 — Hostile Intermediary

A Raspberry Pi relay was allowed to observe, alter, substitute, delay, forward, and replay authority-bearing requests while lacking the trusted provider private key.

Signed-field mutation was rejected. A wrong-provider Ed25519 signature over the same canonical authority bytes was rejected while the trusted-provider signature was accepted. Untouched legitimate authority was accepted once, replay was denied, and rejected invalid submissions did not consume the legitimate unused authority.

Observed property: Control of the intermediary request path did not become greater executable provider authority in the tested architecture.

ESP-LOCAL-007 — Concurrent Requesters

Two requesters presented the same valid provider-issued authority with max_uses = 1 to the same ESP32-S3 endpoint.

Exactly one request was accepted and one was denied. The endpoint crossed the PWM execution boundary once, the independent hardware witness observed one servo-like pulse burst, and the authority finished durably SPENT.

The scored R003 run used two requester connections with a measured release send-start skew of 42.7 microseconds.

Boundary: This establishes at-most-once physical execution for the tested two-requester contention condition. It does not establish behavior for arbitrary numbers of simultaneous requesters, availability under contention, or correctness across arbitrary hardware, storage, firmware, or scheduler implementations.

ESP-LOCAL-008 — Signed Endpoint Directionality

Valid provider-signed authority scoped to Servo1 was presented to Servo2, and valid authority scoped to Servo2 was presented to Servo1.

Both wrong-target presentations passed provider-signature verification and semantic admissibility, then were denied at the signed target-identity gate. In both cases, the unintended endpoint's persistent authority state remained unchanged and the independent witness observed zero target-line control bursts.

Positive controls then presented correctly scoped authority to each endpoint. Both were accepted, durably consumed before PWM execution, and independently observed as one physical control-signal burst.

Final matrix: 2/2 wrong-target denials with unchanged target state and zero physical bursts; 2/2 correct-target acceptances with durable spends and independently observed physical bursts.

Boundary: This establishes signed endpoint target binding for the tested two-endpoint configuration. It does not establish arbitrary multi-endpoint routing, resistance to complete endpoint compromise or provider-key theft, mechanical movement independent of the electrical signal, or independently re-establish the persistence, crash, hostile-relay, or concurrency properties tested in the preceding experiments.

Endpoint-Local Claim Boundary

The endpoint-local series does not establish secure boot, resistance to complete endpoint compromise, resistance to provider-private-key compromise, trusted time, tamper-resistant storage, guaranteed mechanical movement, or exactly-once mechanical execution.

Each experiment adds a specific tested condition. Results from one experiment are not silently extended to conditions tested separately in another.

Fleet Operation

Bounded-authority behavior was exercised across multiple constrained endpoints, not only a single request path.

Fleet testing progressed through three-endpoint and five-endpoint operation, mixed outcomes, endpoint isolation and restoration, noisy-endpoint and load conditions, endurance operation, and physical endpoint contention.

The fleet work also produced a useful failure investigation.

A synchronized approximately 900 ms degradation appeared across endpoints during testing on one wireless path. Re-running the same tests over a different wireless path produced 13/13 PASS and 39/39 correct endpoint transactions, with the synchronized degradation not reproduced.

That comparison isolated the condition to the access-point-specific wireless path at the fault-domain level. The exact internal mechanism within that access point remained unresolved and is recorded as such.

Boundary: The fleet implementation used endpoints that trusted the Raspberry Pi boundary result rather than independently verifying the provider signature. A compromised boundary could therefore fabricate a downstream result to those trusting endpoints. The fleet results do not establish arbitrary endpoint scale or production readiness.

How to Read This Evidence

A test result supports only the property that test exercised.

• PASS does not mean production ready.
• A cryptographic manifest verifies the published bytes, not the experimental conclusion.
• An independent electrical witness is independent of the enforcing endpoint; it is not an independent third-party laboratory.
• Provider admission, command issuance, electrical observation, and mechanical completion are different observations.
• Withheld implementation material, reproduction limits, failures, anomalies, and unresolved conditions remain part of the individual test records.

The evidence packages are intentionally more detailed than this page. They contain the configuration, procedures, results, provenance, artifacts, limitations, and integrity information needed to evaluate what each experiment actually supports.

Claims follow the evidence. The repository carries the record.