Skip to content

Commit 16c5a3e

Browse files
BryceWDesignBryceWDesign
authored
Create ROADMAP.md
1 parent 1bf501a commit 16c5a3e

1 file changed

Lines changed: 253 additions & 0 deletions

File tree

‎ROADMAP.md‎

Lines changed: 253 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,253 @@
1+
# IX-HapticSight Roadmap
2+
3+
This roadmap defines the planned upgrade path from the current reference implementation toward a stronger, more auditable, and more runtime-oriented safety stack for bounded optical-haptic interaction.
4+
5+
It is intentionally conservative.
6+
7+
The project is not represented as certified, clinically validated, production deployed, or regulator-approved. The roadmap describes engineering intent and repository milestones, not real-world deployment approval.
8+
9+
---
10+
11+
## Repository Mission
12+
13+
IX-HapticSight is being developed as a safety-first optical-haptic interaction architecture for bounded human-facing robot behavior.
14+
15+
The core project mission is to make these behaviors explicit, testable, and reviewable:
16+
17+
- approach
18+
- pre-contact verification
19+
- bounded contact
20+
- retreat
21+
- safe hold
22+
- consent-aware interaction gating
23+
- hazard-aware veto behavior
24+
- auditable runtime policy evaluation
25+
26+
The long-term direction is not broad social robotics.
27+
28+
The long-term direction is a measurable interaction-governance stack with deterministic safety constraints.
29+
30+
---
31+
32+
## Current Baseline
33+
34+
The current repository already contains:
35+
36+
- protocol schemas
37+
- consent logic
38+
- nudge scheduling logic
39+
- rest-pose generation
40+
- contact planning logic
41+
- safety gating logic
42+
- configuration files
43+
- example usage
44+
- baseline unit tests
45+
46+
That is enough for a reference implementation, but not enough for a runtime-grade or evidence-backed package.
47+
48+
---
49+
50+
## Upgrade Goals
51+
52+
The upgrade campaign is designed to produce a stronger repository in the following areas:
53+
54+
1. **Repository credibility**
55+
- cleaner project structure
56+
- clearer scope and non-claims
57+
- stronger contribution and review rules
58+
- more disciplined release notes and artifacts
59+
60+
2. **Runtime architecture**
61+
- package separation by responsibility
62+
- runtime coordinator structure
63+
- ROS 2-compatible package layout
64+
- explicit interfaces and message models
65+
66+
3. **Safety behavior**
67+
- stronger veto architecture
68+
- explicit fault handling
69+
- retreat semantics
70+
- stale-consent rejection
71+
- independent policy enforcement paths
72+
73+
4. **Physical sensing interfaces**
74+
- force-torque input abstraction
75+
- tactile sensor input abstraction
76+
- proximity input abstraction
77+
- thermal input abstraction
78+
- contact-state fusion hooks
79+
80+
5. **Evidence and replay**
81+
- structured logs
82+
- replay tooling
83+
- deterministic benchmark scenarios
84+
- simulation scene packs
85+
- hardware-in-the-loop scaffolding
86+
87+
6. **Governance**
88+
- threat model artifacts
89+
- privacy and data handling docs
90+
- safety invariant traceability
91+
- standards crosswalk
92+
- safety-case starter materials
93+
94+
---
95+
96+
## Planned Maturity Levels
97+
98+
### M0 — Reference Prototype
99+
Status: approximately current state
100+
101+
Characteristics:
102+
- pure Python reference modules
103+
- documentation-first posture
104+
- baseline configs and tests
105+
- no real runtime messaging layer
106+
- no tactile or hardware abstraction layer
107+
- no benchmark suite
108+
- no HIL scaffolding
109+
110+
### M1 — Structured Repository
111+
Planned outcome:
112+
- stronger packaging
113+
- contribution and release hygiene
114+
- clarified roadmap, non-claims, and project boundaries
115+
- expanded project documentation
116+
117+
Exit criteria:
118+
- repository structure is stable
119+
- upgrade plan is documented
120+
- contribution rules and release notes exist
121+
- package metadata is present
122+
123+
### M2 — Modular Runtime Foundation
124+
Planned outcome:
125+
- logical package separation
126+
- runtime coordination interfaces
127+
- ROS 2 workspace and node scaffolding
128+
- message and service definitions
129+
- launch and configuration layering
130+
131+
Exit criteria:
132+
- runtime module boundaries are explicit
133+
- state ownership is clearer
134+
- node lifecycle assumptions are documented
135+
- configuration loading is centralized
136+
137+
### M3 — Safety-Grade Execution Layer
138+
Planned outcome:
139+
- motion execution adapter interfaces
140+
- collision and zone gating
141+
- retreat/abort logic
142+
- watchdog behavior
143+
- dual-path veto design
144+
- stronger fault handling tests
145+
146+
Exit criteria:
147+
- execution boundaries are explicit
148+
- abort and retreat semantics are testable
149+
- safety behavior is separated from convenience behavior
150+
151+
### M4 — Physical Signal Integration
152+
Planned outcome:
153+
- force-torque interfaces
154+
- tactile interfaces
155+
- proximity interfaces
156+
- thermal interfaces
157+
- contact-state fusion logic
158+
- simulated sensor fixtures
159+
160+
Exit criteria:
161+
- the codebase can represent measured contact-related inputs
162+
- the planner and safety logic can consume those inputs without hidden assumptions
163+
164+
### M5 — Evidence, Replay, and Benchmarking
165+
Planned outcome:
166+
- structured event logs
167+
- replay tooling
168+
- benchmark schemas
169+
- canonical scenarios
170+
- metrics reports
171+
- deterministic result packages
172+
173+
Exit criteria:
174+
- behavior changes can be replayed
175+
- benchmark outputs are comparable
176+
- metrics are documented and reproducible
177+
178+
### M6 — HIL and Safety Case Readiness
179+
Planned outcome:
180+
- hardware-in-the-loop scaffolding
181+
- calibration templates
182+
- fault injection templates
183+
- standards crosswalk
184+
- privacy and governance docs
185+
- safety invariant traceability matrix
186+
- safety-case starter pack
187+
188+
Exit criteria:
189+
- the repository supports disciplined evidence collection
190+
- traceability exists between requirements, tests, and claims
191+
- governance artifacts exist for future review
192+
193+
---
194+
195+
## What This Project Is Not
196+
197+
The repository should not drift into claims it cannot support.
198+
199+
It is not:
200+
201+
- a certified collaborative robot package
202+
- a medical device
203+
- a therapy robot
204+
- a proven emotion-recognition engine
205+
- a production deployment stack
206+
- a substitute for hardware safety engineering
207+
- a substitute for legal, regulatory, or IRB review
208+
- a claim of socially correct behavior in all settings
209+
210+
---
211+
212+
## Evidence Philosophy
213+
214+
The strongest form of this project will rely on:
215+
216+
- explicit requirements
217+
- deterministic safety behavior
218+
- replayable logs
219+
- bounded contact semantics
220+
- benchmark scenarios
221+
- hardware-in-the-loop evidence
222+
- traceable documentation
223+
224+
Preference is always given to measured evidence over narrative claims.
225+
226+
---
227+
228+
## Release Philosophy
229+
230+
The planned release direction is:
231+
232+
- v0.1.x: reference implementation baseline
233+
- v0.2.x: repository restructuring and modularization
234+
- v0.3.x: runtime and ROS 2 scaffolding
235+
- v0.4.x: sensing interfaces and execution safety expansion
236+
- v0.5.x: replay and benchmark package
237+
- v0.6.x: HIL scaffolding and safety-case preparation
238+
- v1.0.0: strong repository milestone, still bounded by explicit non-claims unless real evidence justifies more
239+
240+
---
241+
242+
## Final Roadmap Rule
243+
244+
Every major upgrade should improve at least one of these:
245+
246+
- safety
247+
- clarity
248+
- testability
249+
- traceability
250+
- replayability
251+
- boundedness
252+
253+
If it does not improve one of those, it should be treated as optional, not core.

0 commit comments

Comments
 (0)