I’m working on an experimental open protocol called PlaceAuth / Spatial Policy Protocol (SPP) for expressing machine-readable requirements that originate from physical places rather than from the robot fleet itself.
The specific architectural question I’d like feedback on is narrow:
Should place-originated spatial requirements remain declarative, while Open-RMF evaluates whether a specific candidate robot, route, and task sequence can satisfy them?
During review of the current request-level consideration model, a key limitation became clear: task acceptability can depend on more than the task description itself. It may depend on the candidate robot, its starting state, the route it would take, and task ordering.
For example:
- A robot may be asked to move to a destination while recording.
- The task could be valid for a robot whose route does not cross a no-recording zone.
- The same task could be invalid for another robot starting elsewhere if every viable route crosses that zone.
- Task ordering may also matter if earlier tasks change the robot’s state or location.
That pushed the experiment away from treating spatial policy as a simple request-level permit/deny decision.
The current model is:
Place policy:
- declares spatial requirements
- identifies governed places/scopes
- remains independent of fleet organization
Open-RMF / planner:
- evaluates a candidate robot
- evaluates its starting state
- evaluates candidate routes
- evaluates task ordering
- determines whether the resulting plan satisfies the place-originated requirements
The intent is to keep SPP declarative rather than turning it into a planner.
I’d especially value feedback on the following:
- Boundary correctness
Does it make architectural sense to keep place-originated policy separate from fleet/group taxonomy?
My current thinking is that fleet/group hierarchy describes machine organization, while place policy represents an independent source of constraints originating from the environment being entered.
- Planner responsibility
Should feasibility against spatial constraints be evaluated inside the task planner rather than at the initial request-consideration boundary?
- Candidate-specific feasibility
Is it reasonable for the same task to be considered feasible for one robot and infeasible for another based on:
- initial location
- available route
- task sequence
- robot capability/state
- Integration point
Where would this best enter a next-generation Open-RMF architecture?
Possibilities I’ve considered include:
- request consideration
- planner feasibility evaluation
- assignment
- execution-time validation
- a combination of these
- Existing abstraction / prior art
Does Open-RMF already have, or is it already moving toward, an abstraction that handles this problem more cleanly?
I’m very interested in being told that this boundary is wrong, redundant, or over-engineered if there is a better existing model.
Supporting material:
Architecture note:
Peer-review entry point:
Planner-aware experiment:
The planner experiment is intentionally small. It demonstrates:
- Robot A can complete a recording task because its route avoids a restricted scope.
- Robot B cannot complete the same task because its route crosses a no-recording scope.
- Robot B becomes feasible when recording suppression is mapped as an explicit restriction.
The experiment does not propose normative Open-RMF APIs.
What I am NOT asking for review on here:
- cryptographic admission-envelope details
- PKI / issuer federation
- patentability
- commercialization
- whether SPP should become a formal standard
- normative SPP 0.2 wording
This is specifically an architecture question about where place-originated constraints belong in the planning and assignment model.
The most useful feedback would be:
- architectural flaw
- missing Open-RMF concept
- unnecessary complexity
- better integration point
- existing mechanism or standard I should study
Even a short “this belongs in X instead” would be extremely useful.