From 614d55c555920fdd95ff8ef5470803a21c8163f5 Mon Sep 17 00:00:00 2001 From: Braden Date: Tue, 22 Sep 2026 08:53:48 -0400 Subject: [PATCH] Add IEEE P1872.3 presentation preparation materials --- .../ieee-1872-3-presentation-outline.md | 130 ++++++++++++++++++ docs/research/ieee-1872-3-question-sheet.md | 42 ++++++ docs/research/ieee-1872-3-speaker-notes.md | 105 ++++++++++++++ 3 files changed, 277 insertions(+) create mode 100644 docs/research/ieee-1872-3-presentation-outline.md create mode 100644 docs/research/ieee-1872-3-question-sheet.md create mode 100644 docs/research/ieee-1872-3-speaker-notes.md diff --git a/docs/research/ieee-1872-3-presentation-outline.md b/docs/research/ieee-1872-3-presentation-outline.md new file mode 100644 index 0000000..de8a383 --- /dev/null +++ b/docs/research/ieee-1872-3-presentation-outline.md @@ -0,0 +1,130 @@ +# Place-Originated Requirements and Robotics Ontology Interoperability + +**Purpose:** Non-normative presentation preparation for an IEEE P1872.3 discussion. SPP is experimental and pre-standardization; SPP 0.1 remains the project's normative specification. This is an interoperability and vocabulary-review discussion, not an adoption proposal or a claim of IEEE endorsement, adoption, or conformance. + +## Slide 1 — Why I’m here + +**On-slide content** + +- **Place-Originated Requirements and Robotics Ontology Interoperability** +- PlaceAuth / Spatial Policy Protocol (SPP): an experimental place-policy project +- SPP 0.1 is normative within the project; ontology mapping is non-normative research +- Objective: reuse and critique established concepts, not propose adoption + +**Speaker notes:** Thank the group and state the boundary immediately: “I’m not here to propose that P1872.3 adopt SPP. I’m here because SPP has reached a point where ontology alignment matters, and I’d rather reuse established concepts than accidentally create a parallel vocabulary.” PlaceAuth does not claim IEEE endorsement, P1872.3 adoption, or conformance with IEEE 1872, IEEE 1872.2, DUL, DOLCE, SUMO, or P1872.3. Ask the group to correct terminology and point to existing constructs. + +**Approximate speaking time:** 0:55 + +## Slide 2 — The interoperability problem + +**On-slide content** + +- A physical environment may impose machine-operational requirements +- Those requirements can cross robot vendors, fleets, planners, applications, and infrastructure +- Example concerns: movement, sensing, data handling, access to infrastructure, human interaction +- More than ordinary geofencing or application-local configuration + +**Speaker notes:** The problem is not that a map needs another polygon layer. A governed environment may need to state conditions that apply to an action in a named scope and context, independently of a visiting robot vendor or fleet. A local configuration can solve this in a closed deployment. The interoperability question arises when the place authority, robot operator, planner, and enforcement point are separate. SPP is an experiment in making that policy-facing exchange explicit; it does not establish deployment maturity or replace those systems. + +**Approximate speaking time:** 1:05 + +## Slide 3 — The narrow SPP boundary + +**On-slide content / diagram** + +```text +PLACE AUTHORITY + ↓ +GOVERNED SCOPE + REQUIREMENTS + ↓ +SUBJECT + ACTION + CONTEXT + ↓ +PERMIT / DENY / CONDITIONAL +``` + +- SPP 0.1 asks whether an actor may perform an action in a space under context +- Core inputs: actor, action, hierarchical space, context +- A policy decision is separate from its enforcement point + +**Speaker notes:** This is deliberately a small place-policy boundary, not a universal robotics architecture. In SPP 0.1, a policy authority supplies rules scoped through hierarchical opaque space identifiers. A request supplies actor, action, space, and context; evaluation returns `permit`, `deny`, or `conditional`. The core does not say what a robot is, create a world model, or prove an action occurred. “Governed scope” is useful shorthand for the applicability context, but it is not an asserted IEEE ontology mapping and it is more than a geometric region. + +**Approximate speaking time:** 1:00 + +## Slide 4 — What SPP should not own + +**On-slide content** + +- Geometry and maps +- Robot identity infrastructure and PKI +- Fleet taxonomy; route, task, and resource planning +- Universal capability ontology +- Physical enforcement and safety certification + +**Speaker notes:** These exclusions are as important as the policy model. SPP space IDs are policy keys, not geometry or topology. A deployment must supply identity, trust, and transport mechanisms. A fleet or planner owns candidate generation, assignment, routes, sequences, and final plan feasibility. The robot runtime, fleet adapter, building controller, or another deployment component owns enforcement. Safety systems remain independently authoritative. Keeping this boundary small reduces accidental semantic duplication and lets SPP exchange place-originated conditions without claiming ownership of the surrounding robotics stack. + +**Approximate speaking time:** 0:55 + +## Slide 5 — Semantic distinctions + +**On-slide content** + +```text +Requirement ≠ Capability ≠ Evidence ≠ Conformance + ≠ Admission ≠ Task Feasibility ≠ Enforcement +``` + +- Requirement: a place-originated, scope-bound condition +- Capability: what a subject may be able to do +- Evidence / conformance: support and conclusion about satisfying a requirement +- Admission / feasibility / enforcement: successive, distinct operational questions + +**Speaker notes:** A requirement is not a capability. A capability declaration is not evidence. Evidence is information supporting a conclusion; conformance is the relation or conclusion produced by evaluating it. The experimental reference admission layer then produces a scoped `ADMITTED`, `DEGRADED`, or `DENIED` operating conclusion with guarantees, restrictions, unresolved requirements, and reasons. That is not permission under SPP 0.1, safety certification, or task allocation. A planner still decides whether a particular route and task sequence can satisfy all constraints, and an enforcement point must actually block or permit behavior. “I’m more interested in discovering which SPP concepts we should delete or reuse than in defending every term we currently have.” + +**Approximate speaking time:** 1:25 + +## Slide 6 — Requirement versus affordance + +**On-slide content** + +- Example: **“Recording is prohibited in this zone.”** +- SPP currently treats this as a place-originated requirement / restriction +- It does not assert that the place affords recording or that the robot can record +- Questions: existing representation? independent restriction? reusable relation? + +**Speaker notes:** This example is intended to expose a possible modeling seam. The statement is normative: the place says what must not happen in the governed scope. It is not a claim about physical possibility, function, or subject-environment interaction. A robot might have recording capability; it might lack it; the environment might make recording useful or possible. Those facts may matter to a candidate plan, but none changes the meaning of the place restriction. Ask whether IEEE robotics ontology work already models this distinction cleanly, whether a restriction should be represented independently of affordance, and whether there is an existing relation SPP should reuse. Do not assume an answer or describe preliminary P1872.3 concepts as finalized semantics. + +**Approximate speaking time:** 1:05 + +## Slide 7 — Policy versus planning + +**On-slide content / diagram** + +```text +Robot A: route avoids restricted recording region → candidate may remain feasible +Robot B: route crosses region while recording → candidate is infeasible +Robot B: recording disabled → candidate becomes potentially feasible +``` + +- **Policy:** “What requirements apply?” +- **Planner:** “Can this candidate satisfy them?” +- “The place declares the constraint. The planner evaluates the candidate.” + +**Speaker notes:** The example is conceptual, not a claim about P1872.3 or Open-RMF adoption. The planner needs facts SPP Core does not own: selected subject, initial state, candidate route, task order, active behaviors, resources, and current environment. SPP can express or supply the place-facing constraint; a planner determines whether the particular candidate avoids the scope, crosses it while recording, or can satisfy a restriction such as disabling recording. A positive policy or admission result must not be misrepresented as route feasibility, dispatch approval, or physical enforcement. + +**Approximate speaking time:** 1:10 + +## Slide 8 — Questions for P1872.3 + +**On-slide content** + +- Which concepts already have appropriate representations, and which should collapse into them? +- Are place-originated operational requirements best a class, relation, or existing construct? +- How should scoped admission remain distinct from capability, permission, certification, and task feasibility? +- How should candidate feasibility depend on subject state, place constraints, and planned actions? +- Where is SPP conflating concepts; which gaps are ontology gaps versus profile concerns? + +**Speaker notes:** Close with an invitation to critique, not adoption. Ask for established terms and relations, especially around applicability, affordance, capability, constraint or requirement, evidence, conformance, permission, feasibility, and spatial or environmental context. Ask which distinctions are useful enough to preserve, which are redundant, and what should remain profile- or deployment-level rather than ontology-level. The next step is not changing SPP in this meeting; it is documenting corrections and deciding whether any future non-normative ontology work is justified. + +**Approximate speaking time:** 1:05 + +**Estimated total:** approximately 8 minutes 40 seconds, leaving time for interruption or discussion in an 8–10 minute slot. diff --git a/docs/research/ieee-1872-3-question-sheet.md b/docs/research/ieee-1872-3-question-sheet.md new file mode 100644 index 0000000..68da152 --- /dev/null +++ b/docs/research/ieee-1872-3-question-sheet.md @@ -0,0 +1,42 @@ +# IEEE P1872.3 Discussion Sheet — PlaceAuth / SPP + +**Meeting boundary:** SPP is experimental and pre-standardization. SPP 0.1 remains normative within the project. This discussion is non-normative ontology research and interoperability preparation, not an adoption proposal. + +## A. Five highest-priority questions + +1. Which SPP concepts already have appropriate representations in IEEE robotics ontology work or related established vocabularies? +2. Which SPP distinctions should collapse into existing concepts, rather than remain separate terms? +3. Are place-originated operational requirements best represented as their own class, a relation, or an existing construct with a specific profile? +4. How should scoped admission remain distinct from capability, permission, certification, and task or route feasibility? +5. How should candidate-task or candidate-route feasibility be modeled when it depends jointly on subject state, place-originated constraints, and planned actions? + +## B. Concepts to listen for + +- Existing ontology terms equivalent to SPP concepts +- Applicability relations and scoped context +- Affordance +- Capability +- Constraint / requirement +- Evidence +- Conformance +- Permission +- Task feasibility +- Environmental or spatial context + +## C. Do not accidentally claim + +- IEEE endorsement +- P1872.3 adoption +- Conformance with IEEE 1872, IEEE 1872.2, DUL, DOLCE, SUMO, or P1872.3 +- Finalized P1872.3 semantics + +## D. Live meeting notes + +- +- +- +- +- +- +- +- diff --git a/docs/research/ieee-1872-3-speaker-notes.md b/docs/research/ieee-1872-3-speaker-notes.md new file mode 100644 index 0000000..d06fe68 --- /dev/null +++ b/docs/research/ieee-1872-3-speaker-notes.md @@ -0,0 +1,105 @@ +# IEEE P1872.3 Discussion Speaker Notes + +**Status:** Non-normative meeting preparation. SPP is experimental and pre-standardization. SPP 0.1 remains normative within the project; the ontology mapping research does not change it. + +## Slide 1 — Why I’m here + +Thanks for having me. I’m here from PlaceAuth, which is working on the Spatial Policy Protocol, or SPP. The narrow problem we are exploring is how a physical place can communicate machine-operational requirements to autonomous systems operating there. + +I want to set the boundary clearly at the start. I’m not here to propose that P1872.3 adopt SPP. I’m here because SPP has reached a point where ontology alignment matters, and I’d rather reuse established concepts than accidentally create a parallel vocabulary. + +SPP is experimental and pre-standardization. Within the project, SPP 0.1 is the normative policy specification. The conformance, evidence, admission, lifecycle, planner-aware, and ontology-mapping material is research or reference work around that core. PlaceAuth does not claim IEEE endorsement, P1872.3 adoption, or conformance with IEEE 1872, IEEE 1872.2, DUL, DOLCE, SUMO, or P1872.3. + +So I am asking for correction. If the terminology is redundant, poorly separated, or already represented by a better-established concept, that is useful feedback. + +## Slide 2 — The interoperability problem + +The motivating problem is simple to state: a physical environment may need to communicate machine-operational requirements. Think of a hospital room, a warehouse aisle, a secure area, or a loading zone. The requirements might concern movement, sensing, data retention, use of a door or elevator, or a human interaction. + +The difficult part is that the place authority, robot vendor, fleet operator, planner, application, and facility infrastructure may not be the same system or organization. In a closed deployment, ordinary geofencing or an application-specific configuration may be entirely sufficient. We do not want to overstate the need for another layer. + +The interoperability question appears when a place wants to express a condition in a way that does not assume one robot vendor, one fleet stack, or one application owns the meaning. SPP is an experiment in making that exchange explicit. It does not claim that the exchange is mature, broadly deployed, or sufficient on its own. + +That brings me to the small boundary SPP is trying to keep. + +## Slide 3 — The narrow SPP boundary + +SPP 0.1 starts with a policy question: may an actor perform an action in a space under a supplied context? + +The place authority authors policy. The request brings together a subject or actor, an action, a named space, and context. The decision is `permit`, `deny`, or `conditional`. A conditional outcome is not a weak permit; the action must remain blocked until its stated conditions are satisfied and the request is evaluated again. + +The diagram says “governed scope plus requirements.” That is presentation shorthand, not a claimed ontology mapping. In the existing SPP research, governed scope means the applicable context that can include place and space, and sometimes action, actor, policy, evidence, or time. It is not merely a geometric region. + +Also, SPP 0.1 space identifiers are hierarchical policy keys. They are opaque strings with explicit parent relationships. They do not represent geometry, topology, maps, or a complete physical-world model. + +Most importantly, a policy decision is separate from enforcement. The decision point evaluates the rule; a robot runtime, fleet adapter, building controller, or other deployment component has to prevent or allow the real action. + +That division motivates the exclusions on the next slide. + +## Slide 4 — What SPP should not own + +For interoperability, I think the most useful thing SPP can do is remain narrow. + +It should not own geometry or maps. It should not become robot identity infrastructure, a PKI, a fleet taxonomy, a task model, a route planner, or a universal capability ontology. It should not claim to certify safety. And it cannot itself physically enforce anything. + +Those are not just implementation omissions. They are different authorities and different semantic domains. A deployment supplies its own identity, trust, transport, localization, and authentication mechanisms. A fleet or planner generates candidates, assigns robots, builds routes and sequences, and decides whether a task actually fits. A runtime or facility control is responsible for enforcement. Safety systems can remain independently authoritative and override an SPP permit. + +The benefit of holding the line is that a place can state a condition without SPP claiming to model the entire robot, the environment, or the planner. The cost is that the boundaries have to be named accurately. That is the semantic issue I most want help with. + +## Slide 5 — Semantic distinctions + +SPP currently preserves a sequence of distinctions that can easily collapse in casual discussion. + +First, a requirement is a place-originated, scope-bound condition. It is not a claim about what a robot can do. + +A capability is what a subject may be able to do or demonstrate. But a capability declaration is not evidence that the subject currently meets a particular requirement, under this place’s current conditions. + +Evidence is information supporting a conclusion: for example, a test result with bindings to relevant actor, build, controller, environment, plan, and challenge state. Conformance is the evaluation or relation between requirements, tests, results, and a conclusion. Evidence is not the conclusion itself, and neither is the capability. + +The experimental reference layer then derives an admission profile: `ADMITTED`, `DEGRADED`, or `DENIED`, with guarantees, restrictions, unresolved requirements, and reasons. Admission is a scoped operating conclusion. It is not the SPP 0.1 policy decision, not access control in the general sense, not safety certification, and not task allocation. + +Then there is task or route feasibility. A planner may need to decide whether a selected robot, its current state, a route, task order, resources, and applicable place constraints are jointly satisfiable. That is still separate from whether a runtime or facility controller actually enforces the resulting restriction. + +I’m more interested in discovering which SPP concepts we should delete or reuse than in defending every term we currently have. If this chain contains distinctions that an established ontology already expresses better, I want to know that. + +## Slide 6 — Requirement versus affordance + +Here is one concrete test case: “Recording is prohibited in this zone.” + +SPP currently treats that as a place-originated requirement, or as an explicit restriction on a degraded operating result. The statement is normative: the place says what must not happen in the governed scope. + +It does not say the place affords recording. It does not say the robot is capable of recording. It does not say whether recording is physically possible, useful, safe, or enforceable in that situation. Those might be related facts, and they can matter to a candidate plan, but they are not the same claim. + +The current mapping research deliberately does not assert a P1872.3 affordance definition or relation. Public material reviewed in that work was not enough to support one. So the questions are genuine questions: is this distinction already modeled cleanly in IEEE robotics ontology work? Should a restriction be independently represented from affordance? Is there an existing relation that a future SPP-oriented profile should reuse? + +I would welcome a correction if the example misses an established modeling pattern. + +## Slide 7 — Policy versus planning + +The next distinction is policy versus planning. + +Suppose Robot A has a candidate route that avoids a restricted recording region. Its candidate may remain feasible, subject to all the other planning constraints. + +Robot B has a candidate route that crosses the same region while recording. That candidate is infeasible under the place requirement. + +If Robot B disables recording, the candidate becomes potentially feasible. Potentially is important: it still needs to satisfy every other route, resource, safety, authorization, and enforcement condition. + +The shorthand is: policy asks, “What requirements apply?” The planner asks, “Can this candidate satisfy them?” The place declares the constraint. The planner evaluates the candidate. + +This is only a conceptual boundary. It does not claim that P1872.3 or Open-RMF has adopted it. The planner needs inputs that SPP Core does not own: selected robot identity, initial state, route, task sequence, active behaviors, resources, and current environment. A policy or admission result must not be promoted into a promise of route feasibility, dispatch approval, or physical enforcement. + +This boundary is also where an affordance-related relation might be relevant: a subject, an environment or place state, and an action or capability may jointly determine what is possible. The place restriction adds a different question about what is allowed. + +## Slide 8 — Questions for P1872.3 + +I’ll close with the questions I hope will make this useful. + +Which of these concepts already have appropriate representations in the 1872 family or related ontology work? Which distinctions should collapse into existing concepts rather than becoming SPP vocabulary? + +Are place-originated operational requirements best treated as a class, a relation, or an existing construct with a profile-specific interpretation? How should scoped admission remain distinct from capability, permission, certification, and task feasibility? + +For candidate routes or tasks, what is the right way to represent a conclusion that depends jointly on subject state, place-originated constraints, and planned actions? And which apparent gaps are actually ontology gaps, versus details that should remain in a deployment profile, policy model, or planner interface? + +Finally, where do you see conceptual conflation in SPP today? I am especially interested in terms or relations that SPP should stop using before they harden into unnecessary vocabulary. + +The short version is: I’m trying to determine which concepts SPP should reuse, which distinctions are actually useful, and which terms we should remove before they harden into unnecessary vocabulary. Criticism and pointers to established concepts are the desired outcome; adoption is not the ask.