Strategic analysis for Spanda as an autonomous systems platform with a safety-first language at its core. This document defines positioning, priorities, and release scope. It complements vision.md (aspiration), platform-overview.md (architecture), and feature-status.md (implementation truth).
Last updated: 2026-07-04 (v0.6.3 evaluation/beta; Next horizon phase; organizational gates)
Spanda should not compete as a general-purpose language, Python replacement, Rust replacement, or ROS replacement. It wins as the coordination and verification platform where:
ActionProposal → SafeAction)spanda verify)Official positioning: Spanda is an Autonomous Systems Platform with a safety-first programming language at its core. The pulse of autonomous intelligence.
Short form: The Autonomous Systems Platform.
Sharpened tagline: Build. Verify. Simulate. Deploy. Operate. — for autonomous systems.
Beyond core language features, Spanda prioritizes adoption, trust, and operations — see
platform-maturity-roadmap.md,
enterprise-operations-roadmap.md, and
differentiation-roadmap.md. Planned areas compose existing engines
(spanda-readiness, spanda-assurance, spanda-security) rather than replacing them.
Shipped (v0.6.3 evaluation/beta): release-hardening CI suite (CI Integration), honest mock-default labeling, closed code blockers — release-readiness.md. PR gate: ci-architecture.md.
NOW (Next horizon, P1): differentiation signature capabilities (mission contracts, explainability, decision audit trail); Control Center Stable promotion.
P0 (organizational, parallel): 30-day field soak + third-party security audit — organizational-gates.md · #51.
Shipped (Stable, E1–E4): Control Center (spanda control-center serve), REST v1 API, remote CLI
with --version, official SDKs 0.4.2, Tauri desktop 0.6.3 (auto desktop-v* on labeled CC
PRs), WebSocket/OTLP observability, compliance/digital-thread/executive reporting — see
control-center.md ·
control-center-versioning.md ·
stable-hardening-enterprise-ops.md.
Deferred: VS Code Marketplace publish (needs VSCE_PAT).
Hardware is the body.
Sensors are the senses.
AI models are the mind.
Actuators are the muscles.
Spanda is the intelligent pulse that transforms perception, intent, and safety into action.
Spanda (Pronounced SPUN-duh (/ˈspʌndə/)) is a Sanskrit term meaning the divine pulse — the creative vibration of consciousness and energy that manifests as expansion and contraction in all entities, bridging stillness and movement within consciousness; and the first stir of awareness that creates and sustains the universe.
Six capabilities define Spanda’s market identity. Protect them in every release decision.
| # | Capability | What it means | Status |
|---|---|---|---|
| 1 | Safety-Typed AI | ActionProposal cannot reach actuators; only SafeAction from safety.validate() can. |
Stable |
| 2 | Mission Contracts | Missions as verifiable entities with guarantees, constraints, assumptions, invariants, objectives. | Planned (NOW) |
| 3 | Readiness Engine | Weighted go/no-go across health, verify, safety, trust, mission achievability. | Stable |
| 4 | Continuity & Takeover | Checkpoint resume, delegation, succession, safety-gated fleet handoff. | Stable |
| 5 | Trust Framework | Composite trust across packages, hardware, config, identity, safety integrity. | Stable |
| 6 | Explainability & Audit Trail | Decision → evidence → safety check → action; trace replay. | Planned (NOW) |
| Question | Answered by |
|---|---|
| Can this mission run? | Mission Contracts + Readiness + spanda verify |
| Can this robot safely perform this mission? | Safety-Typed AI + Safety Coverage + safety { } |
| Does the hardware satisfy the required capabilities? | spanda verify + capability traceability |
| Is the system healthy enough to deploy? | Readiness Engine + Health Framework |
| Can it run safely? | Safety-Typed AI + Safety Coverage |
| Can it recover? | Recovery Coverage + Recovery Framework |
| Can it continue? | Continuity & Takeover |
| Who can take over when a robot or fleet member fails mid-mission? | Continuity & Takeover + Succession Planning |
| Can it be trusted? | Trust Framework + Certification Packs |
| Why should this deployment be trusted? | Trust Framework + Readiness + Assurance evidence |
| Why did it behave this way? | Explainability + Decision Audit Trail |
| What happened when something failed? | Diagnosis Engine + Replay + Decision Audit Trail |
| What evidence supports deployment? | Certification Packs + Assurance Cases |
Full roadmap: differentiation-roadmap.md.
Foundational pillars that support the signature capabilities above.
| # | Pillar | What it means |
|---|---|---|
| 1 | Safety-Typed AI | ActionProposal cannot reach actuators; only SafeAction from safety.validate() can. Enforced at compile time and runtime. |
| 2 | Hardware Compatibility Verification | spanda verify checks memory, sensors, actuators, timing, battery, network, and AI model requirements against hardware profiles. |
| 3 | Simulation-First Development | spanda check → spanda verify → spanda sim as the default dev loop before hardware exists. |
| 4 | Autonomous Systems Primitives | robot, sensor, actuator, task, agent, safety are language keywords — not framework imports. |
| 5 | Safe Deployment Validation | deploy, requires_hardware, verify { }, mission duration, and task budgets encode the ship checklist in source. |
| Capability | vs Python/Rust/C++ | vs ROS2/Dora-RS | vs Agentic AI frameworks |
|---|---|---|---|
| AI safety as types | Convention only | Not addressed | Runtime filters only |
| Pre-deploy hardware verify | Manual CI/scripts | URDF + launch files | Not addressed |
| Units in robot syntax | Libraries | Not native | Not addressed |
| Unified design→verify→sim | Fragmented toolchain | Runtime graph only | No hardware/deploy model |
| Area | Incumbent | Spanda stance |
|---|---|---|
| ML training | Python/PyTorch | Orchestrate via extern python |
| Real-time drivers | C++/Rust | Call via FFI; don’t rewrite |
| Communication at scale | ROS2 | Bridge, don’t replace |
| Physics simulation | Gazebo/Isaac/Mujoco | Physics-lite sim for safety testing only |
| Package ecosystem | PyPI/crates.io/ROS | Hosted index + in-repo mirror via spanda publish; 38 official packages |
| Native performance | Rust/C++ | Interpreter first; LLVM deferred |
| Feature | Rating | Notes |
|---|---|---|
ActionProposal / SafeAction |
Highly differentiated | No mainstream language enforces this natively |
spanda verify |
Highly differentiated | Closest analog is manual checklists, not a language primitive |
| Physical units | Somewhat unique | Libraries exist elsewhere; integration with robot syntax is the value |
| Robot-native syntax | Somewhat unique | ROS2/Dora are runtime graphs, not unified typed languages |
verify { } assertions |
Somewhat unique | Between unit tests and formal methods |
| Built-in simulation | Already common | Adequate for alpha; not a Gazebo replacement |
| Communication model | Already common | ROS2 owns production transport |
| AI agents / goals / memory | Already common | Structural value; live OpenAI/Anthropic/ONNX when configured |
| Blockchain / provenance | Already common | Optional; stub only — remove from core narrative |
| World models | Minimal runtime | world_model { } + belief hook; not full knowledge graphs |
| LLVM / self-hosting | Already common | Premature for current adoption stage |
Every major feature is classified for prioritization. See feature-status.md for implementation status.
| Feature | Classification |
|---|---|
| ActionProposal / SafeAction | Core Identity |
Safety validation (safety { }, zones, stop_if) |
Core Identity |
| Physical units | Core Identity |
Hardware profiles + deploy |
Core Identity |
Compatibility verification (spanda verify) |
Core Identity |
| Autonomous primitives (robot/sensor/actuator/task) | Core Identity |
| Battery estimation | Important |
| Timing verification | Important |
| Simulation | Important |
verify { } behavioral assertions |
Important |
| AI agents (goal, memory, skill) | Important |
| Communication model | Important |
| Deployment targets | Core Identity |
| observe / fusion | Important |
| Package ecosystem | Important |
| Security (capabilities, signed comm) | Important |
| Python integration | Important |
| ROS2 integration | Important |
| Digital twins (local replay) | Nice To Have |
| Replay buffer | Nice To Have |
| Provenance / audit (local) | Nice To Have |
| C++ integration | Nice To Have |
| Concurrency (spawn/select) | Nice To Have |
| Generics / async / traits | Nice To Have |
| Digital twin cloud sync | Experimental (Twin Cloud SaaS + legacy upload) |
| Multi-agent distributed runtime | Future |
| World models | Future |
| LLVM production backend | Future |
| Self-hosting compiler | Future |
| Blockchain support | Future (community packages only) |
Promoted from deferred to experimental with minimal runtimes and golden paths. See tier-3-experimental.md. Execution order: tier-3-priority-plan.md.
spanda compile-native, scripts/llvm_golden_path.sh)spanda-ledger → MockLedgerBackend)world_model.update / belief runtime)SPANDA_CLOUD_UPLOAD_URL)cpp-native feature)examples/self_host/)Still future: LLVM as primary path, production chain adapters, full world-model semantics,
hosted Twin Cloud product GA (billing, multi-region SLA — OSS /v1/twins/* is Stable), full
fleet planning, full DDS middleware, ROS replacement, complete self-hosted compiler.
A robotics team writes a .sd program, runs spanda verify against their hardware profile,
simulates it, connects one real AI provider and one real transport (Python + ROS2), and deploys
coordination logic to edge hardware — with unsafe AI blocked at compile time.
| Must have | Status |
|---|---|
| Interpreter + type checker | Done |
| ActionProposal → SafeAction | Done |
spanda verify |
Done |
| Physics-lite sim | Done |
| Showcase examples + CI | Done |
Optional (present): live AI/IoT when configured, experimental LLVM, hosted registry + publish mirror. Not needed: blockchain, self-hosting, fleet runtime.
| Must have | Status |
|---|---|
| Published VS Code extension with LSP | VSIX CI + local install; only open blocker — Marketplace pending VSCE_PAT |
| One live AI path (OpenAI or local ONNX via Python bridge) | Done — OpenAI, Anthropic, ONNX (Phase 33–35) |
| One documented ROS2 golden path | Done — ros2_golden_path.sh |
spanda verify CI integration guide |
Done — ci-verify.md |
Curated killer demo (examples/showcase/killer_demo.sd) |
Done |
| Package install from remote registry (small, curated) | Done — 38 packages; hosted index + spanda publish mirror |
| Differentiation NOW (contracts, explain, audit trail, coverage) | Planned — topic guides shipped; crates not started |
P1 adoption enablers (CI verify, PyO3, LSP deploy hints, showcase trim, adoption quickstart) are complete — see tier-3-priority-plan.md.
| Must have | |
|---|---|
| Production-quality verify on 5+ hardware profiles | |
| Real deploy to one edge target (Jetson or Pi) | |
| Python + ROS2 interop documented and tested in CI | |
| Stable language subset with migration guide | |
| Security capabilities in production comm examples |
Optional: LLVM for hot paths, twin replay export, fleet examples.
Not needed: self-hosting, full blockchain suite, Gazebo parity.
Use these as GitHub issue titles. Order reflects dependency and adoption impact.
| # | Issue | Acceptance criteria |
|---|---|---|
| 1 | Publish VS Code extension to marketplace | Install from marketplace; LSP diagnostics for check and verify work out of the box |
| 2 | Curate killer demo program | Single .sd file: compile-time AI block + verify pass + sim with emergency stop; documented in docs/killer-demo.md |
| 3 | One live AI provider path | extern python or package calls real OpenAI/ONNX when configured; mock fallback when not |
| 4 | One ROS2 golden path | ros2-golden-path.md — rclpy bridge; /cmd_vel or /scan manual validation |
| 5 | Remote package registry (minimal) | spanda install fetches from a hosted registry; at least 2 curated packages (spanda-openai, spanda-ros2) |
| # | Issue | Acceptance criteria |
|---|---|---|
| 6 | CI integration guide for spanda verify |
ci-verify.md — GitHub Actions + GitLab; --json parsed in CI |
| 7 | In-process Python FFI (PyO3) as default when built | Document build flags; subprocess remains fallback — see ffi-and-ecosystem.md |
| 8 | Hardware profile picker in LSP/VS Code | Deploy target hints or autocomplete for built-in profiles |
| 9 | Trim showcase to 3 flagship examples | examples/showcase/README.md — safety, verify, sim |
| 10 | Adoption quickstart: wrap existing Python stack | adoption-path.md — 1-sprint integration guide |
| # | Issue | Acceptance criteria |
|---|---|---|
| 11 | Digital twin replay export (JSON) | Export replay buffer for post-incident review |
| 12 | DAP debugger polish | Step through task every loops in VS Code |
| 13 | Web playground: killer demo preset | WASM run of killer demo without local Rust build |
compile-native as primary runtimePython (AI, glue) + ROS2 (comm) + C++ (drivers) + manual safety monitors + deploy checklists
Spanda (.sd) — coordination, safety gate, verify
↳ extern python — PyTorch, OpenCV, existing nodes
↳ ROS2 bridge — existing drivers unchanged
spanda check my_robot.sd
spanda verify my_robot.sd --target JetsonOrin
spanda sim my_robot.sd
Week 1: CI with check + verify.
Week 2: one extern python call to existing model.
Week 3: ROS2 bridge for a single topic.
Guides: adoption-path.md · ci-verify.md · ros2-golden-path.md
Positioning: Spanda is a 2–5k LOC coordination layer above existing stacks, not a rewrite.
Duration: under 5 minutes
Message: Unsafe AI is blocked at compile time; hardware fit is verified; safe execution is
simulated.
| Step | Action | Audience sees |
|---|---|---|
| 1 | Show .sd with ai_model, safety { }, deploy |
Readable robot program |
| 2 | spanda check (unsafe version) |
Compile error: ActionProposal cannot reach actuators |
| 3 | Add safety.validate(proposal) |
check passes |
| 4 | spanda verify --json |
Memory, sensors, timing, battery report |
| 5 | spanda sim |
Robot drives; stop_if triggers near obstacle |
| 6 | simulate_compatibility { fault ... } |
Verify warns before deploy |
Implementation: merge examples/showcase/ai_safety_violation.sd and
examples/showcase/hardware_compatibility.sd into examples/showcase/killer_demo.sd; add
docs/killer-demo.md.
Do not show blockchain, world models, LLVM, or fleet comm in this demo.
| Feature | Reason |
|---|---|
| Blockchain / crypto ledger packages | Stub only; distracts from safety story |
| Self-hosting compiler | No adoption value before v1 |
| Production LLVM backend | Verify + sim loop not proven in field |
| World models runtime | No implementation exists |
| Digital twin cloud sync | Local replay sufficient |
| Distributed fleet runtime | Single-process examples enough |
| MQTT/DDS live adapters | ROS2 first |
| Full ROS replacement | Guaranteed failure vs incumbents |
| Advanced power models | Heuristic battery check is enough |
| Expanding GP language surface | Rust/Go win on GP; Spanda wins on domain |
Exception: maintain existing LLVM/security/audit code if tests pass — but allocate no new engineering until Tier 1 is adoption-proven.
Spanda becomes the standard coordination layer for autonomous systems: the .sd file between
Python AI pipelines and ROS2/C++ hardware, with verify-as-CI and safety-typed AI as industry
expectation.
Not a general-purpose language. Not a ROS fork. The deploy-verified, safety-gated orchestration language for robots, drones, and edge agents.