SPP v0.3.0 Experimental Preview

SPP v0.3.0 Experimental Preview

Operational Interoperability

Overview

SPP v0.3.0 Experimental Preview is release-ready for independent
implementation and bounded operational integration. It strengthens
the interoperability boundaries around Place Packages, requirement semantics,
conformance providers, decision traces, profile lifecycle, trust, and
place-side/runtime integration. The normative protocol specification remains
SPP 0.1.

Interoperability contracts

• Decision trace 0.1: schema-defined, deterministic trace output that
  independent tooling can consume. A trace explains a decision; it is not
  authorization.
• Versioned requirement vocabulary: dotted IDs, explicit versions,
  canonical units, comparison semantics, and x-<organization>.<requirement>
  extension conventions. Unknown or incompatible versions fail closed or remain
  unresolved.
• Place Package 0.1: canonical versioned requirement entries, exact
  version/unit validation, deterministic signed single-file JSON, and
  fail-closed unknown extensions.
• Conformance-provider contract: provider ID/version, requirement
  ID/version, embodiment, assurance, evidence-type compatibility,
  deterministic selection, and provider-result validation.

Runtime / integration validation

• ROS 2 Humble / Nav2: evidence-backed operating profiles changed the
  commanded speed of a running Nav2 robot from 1.0 m/s to 0.5 m/s under the
  same active FollowPath goal. The validated path used
  nav2_msgs/msg/SpeedLimit, ControllerServer, and stock Regulated Pure
  Pursuit.
• Open-RMF Humble: using RMF fleet adapter Python 2.1.8, a real Adapter,
  FleetUpdateHandle, one stationary registered test robot, and real ROS
  delivery bids, four delivery-consideration callback invocations were
  exercised. ADMITTED produced a bid proposal; DENIED produced no proposal
  with admission_denied. DEGRADED was not runtime-validated.
• Facility access: a bounded generic facility-side adapter grants a
  matching-place ADMITTED profile; a DEGRADED profile grants only when every
  restriction is explicitly accepted; denied, wrong-place, stale, or revoked
  profiles fail closed.

Trust and lifecycle

• Separate local Ed25519 trust roles verify signed evidence issuers and signed
  place-policy authorities. There is no PKI or federation claim.
• AdmissionProfiles have explicit VALID, REVALIDATE, REQUALIFY, and
  INVALID lifecycle states, including local revocation and invalidation on
  policy, evidence, binding, or trust changes.

Developer / implementation tooling

The independent implementation guide documents the
path from Place Package through vocabulary, provider, evidence, admission,
lifecycle, and trace without relying on the Python reference implementation.

Validation status

The dependency-free reference suite reports 255 passed, 5 skipped, 1
unrelated Windows pytest-cache warning. The Test workflow succeeded on the
release-ready commit. The ROS 2 Nav2 and Open-RMF Runtime GitHub Actions
workflows succeeded on the latest relevant runtime-code commit; the
release-ready documentation/version commit does not alter runtime code.

Known limitations

• Experimental and pre-standardization; not an adopted standard, production
  security system, or certification program.
• No physical-robot safety claim, functional-safety certification, or guaranteed
  stopping behavior.
• Open-RMF validation does not establish physical dispatch execution, traffic
  negotiation, fleet-wide production integration, or physical motion.
• Facility validation does not establish a physical door, vendor system,
  BACnet, MQTT, or building-system integration.
• No PKI, remote trust discovery, production key management, HSM protection,
  certificate lifecycle, distributed revocation, or physical trust in evidence
  generation.

Upgrade / compatibility notes

• The normative protocol specification remains SPP 0.1.
• Place Package remains 0.1 and explain trace remains 0.1.
• Existing v0.2 tags and history are unchanged.
• Newly emitted Place Packages carry explicit requirement versions and canonical
  units. Legacy built-ins have only documented deterministic compatibility
  handling; unknown extensions require explicit local registration.
• Provider compatibility now requires exact requirement-version compatibility.

License / status

Licensed under Apache-2.0. Certain technologies described by PlaceAuth are
patent pending. This release-ready preview remains experimental and
pre-standardization.

SPP v0.2.0 Experimental Preview

Summary

SPP v0.2.0 Experimental Preview advances the PlaceAuth reference implementation while the normative protocol specification remains SPP 0.1.

What changed

• Evidence sufficiency and selective requalification across spatial transitions.
• Admission-boundary evidence revalidation with explicit TOCTOU rejection.
• Local Ed25519 signed evidence and trusted-issuer verification.
• Experimental ROS 2/Nav2 SpeedLimit adapter with real ROS 2 Humble runtime validation.
• Nav2 ControllerServer-to-controller-plugin boundary validation.
• Stock Regulated Pure Pursuit command output changed from 1.0 m/s to 0.5 m/s under one active FollowPath goal.
• Open-RMF task-eligibility adapter targeting Humble Python FleetUpdateHandle.consider_delivery_requests; adapter-boundary validation only, with no Open-RMF runtime test.
• Deterministic mobile-base and humanoid conformance mapping.
• spp-explain, a deterministic decision trace.
• Policy-server root discovery response at GET /.

Validation and limits

• Dependency-free suite: 186 passed, 4 skipped.
• Experimental and pre-standardization. No physical-robot safety, guaranteed-stopping, production PKI, distributed replay-service, or Open-RMF runtime claim.

SPP 0.1.0 Experimental Preview

SPP 0.1.0 Experimental Preview

Purpose

This release candidate presents the Spatial Policy Protocol (SPP) as an experimental open interoperability layer between autonomous systems and physical environments. A place publishes machine-readable requirements, a machine demonstrates conformance, and the resulting evidence supports a spatially scoped operating profile.

SPP is developed under the PlaceAuth project. The robot application remains unchanged while the place requirements determine which actions are permitted, conditional, or denied.

Current architecture

• SPP Core — place requirements, hierarchical spaces, inherited policy, action families, and permit / deny / conditional decisions.
• SPP Conformance (experimental) — deterministic conformance plans, requirement-to-proof mapping, evidence, and assurance levels.
• SPP Admission (experimental) — evidence verification, ADMITTED / DEGRADED / DENIED profiles, RequirementDelta, and selective requalification.

Implemented capabilities

• JSON Schemas and YAML examples for common physical environments.
• Local Python and OPA/Rego policy evaluation.
• Hierarchical policy inheritance with deny-by-default behavior.
• Deterministic evidence generation and binding.
• Evidence digest, freshness, policy/environment binding, and reference replay checks.
• Explicit degraded restrictions and essential-safety denial.
• ROS 2 enforcement-point stub and Docker Compose reference stack.

Four admission scenarios

python demo/admission/run_demo.py a  # full conformance -> ADMITTED
python demo/admission/run_demo.py b  # video-retention failure -> DEGRADED
python demo/admission/run_demo.py c  # essential safety failure -> DENIED
python demo/admission/run_demo.py d  # transition, reuse, and selective requalification

Scenario D reuses the lobby movement guarantee and runs only the three unresolved patient-wing checks before issuing ADMITTED.

Test status

The reference environment reports 35 passed, 1 skipped, 0 failed with the full pytest suite.

Limitations and security disclaimer

This is an experimental preview, not an adopted standard or production security system. SPP does not itself force a malicious autonomous system to obey an operating profile. Trust depends on evidence assurance, enforcement-point integrity, robot/runtime integrity, site infrastructure, hardware guarantees, and any attestation or independent observation mechanisms used by a deployment.

Not production-ready: hardware attestation, distributed replay protection, production ROS 2/Nav2 or Open-RMF integration, certification infrastructure, discovery, production identity/PKI, physical enforcement guarantees, and broad vendor interoperability testing.

Contributing

See CONTRIBUTING.md, SECURITY.md, and ROADMAP.md. Reproduce the demos, review the schemas, report implementation bugs, and propose interoperability improvements with focused tests where possible.

Licensed under Apache-2.0. Certain technologies described in this project are patent pending.