THE CAPABILITY OPERATING SYSTEM
Describe the outcome.
Orchestrate the capabilities.
saneX translates real-world objectives into governed missions, discovers the sensors, systems, services, and operators required, and coordinates them through one capability layer.
Concept & architecture — validated through a simulation-first pilot
The fragmentation problem
The capabilities already exist. Access to them does not.
Sensors, platforms, APIs, operators, and analytical services are distributed across incompatible systems and organisational boundaries. Completing one mission often requires specialist knowledge, manual coordination, and multiple interfaces.
What the world already has
- Cameras & telescopes
- Satellites & remote sensing
- Drones & robots
- Ships & aircraft
- Weather & environmental sensors
- Laboratories & instruments
- Industrial & inspection systems
- Specialist human operators
- Data services & analytical APIs
What one mission demands of you
- Knowing which systems exist
- Knowing who owns or operates them
- Knowing how to access them
- Knowing which interfaces they expose
- Knowing whether they are currently available
- Knowing which regulations and permissions apply
- Knowing how to combine several systems
- Knowing how to evaluate mission success
The inversion
Start with the mission, not the machine.
Current automation starts with a known system and asks what can be done with it. saneX reverses that model: start with the objective, derive the capabilities, then identify and orchestrate the resources.
Traditional approach
- Choose device
- Operate interface
- Collect output
The device defines what is possible. The human does the integration work.
saneX approach
- Define objective
- Derive capabilities
- Find resources
- Govern & execute
The objective defines what is needed. The system finds, compares, and coordinates the resources — under policy.
Interactive mission
See a mission unfold.
Choose an objective and watch it become capabilities, candidate resources, a governed plan — and evidence.
Conceptual demo · synthetic data · no live devices
What outcome do you need?
Required capabilities
Available providers and systems
Constraints evaluated
Proposed plan
⏸ Human checkpoint — approval required before execution
Evidence captured
Capability graph
The core abstraction is the capability — not the device.
Multiple resources can provide the same capability with different trade-offs. The capability graph describes what a resource can do, what it requires, what it produces, where and when it is available, which policies apply, and how its output can be verified. saneX reasons about the required capability first and the concrete resource second.
Example resources providing it
Product architecture
Seven layers between intent and evidence.
Each layer has a distinct trust boundary. Planning never equals permission; permission never equals execution; execution never equals success — until the evidence layer proves it.
1Human intent & mission interface
Where people describe outcomes, set constraints, approve plans, and receive results.
- Natural-language objective
- Structured mission form
- Approval interaction
- Result presentation
Trust boundary
Humans define the mission and retain final authority.
Key question
“What outcome do you need — and under which constraints?”
2Mission compiler
Turns an objective into a structured, verifiable mission specification.
- Intent extraction
- Ambiguity resolution
- Task decomposition
- Dependency graph
- Success conditions
Trust boundary
Plans are proposals — nothing here executes anything.
Key question
“What exactly must be achieved, and how will we know it was?”
3Capability graph
The core semantic model of capabilities, resources, constraints, quality, cost, and trust.
- Capabilities
- Resources & providers
- Availability & quality
- Cost & trust
- Dependencies
Trust boundary
Only verified attributes enter the graph.
Key question
“Who or what can provide this capability, under which conditions?”
4Discovery & marketplace
Finds and matches resources across internal registries, catalogues, and providers.
- Internal registry
- External catalogues
- Capability matching
- Availability checks
- Provider onboarding
Trust boundary
Discovery proposes candidates; it grants no permissions.
Key question
“What is actually available right now, at what cost and quality?”
5Policy, trust & safety
Decides whether a proposed action is eligible for execution at all.
- Identity & access
- Policy evaluation
- Legal & geographic constraints
- Confidence thresholds
- Human approvals
Trust boundary
The planner proposes; policy decides. No bypass.
Key question
“Is this action lawful, authorised, safe — and approved?”
6Adapters & execution plane
Executes approved actions exclusively through verified, certified interfaces.
- Verified APIs
- Device adapters
- Robotics middleware
- Simulation environments
- Abort & rollback
Trust boundary
Only certified adapters touch real systems — least privilege, always.
Key question
“Can this action be executed exactly as approved — and stopped at any time?”
7Observation, validation & learning
Verifies outputs, captures provenance, and feeds performance back into the graph.
- Telemetry & mission state
- Output verification
- Provenance
- Incident logging
- Performance history
Trust boundary
Every claim about success must be backed by evidence.
Key question
“Did the mission actually achieve the objective — and can we prove it?”
Initial wedge
A universal vision, tested through one bounded mission.
The universal vision is deliberately broad — the first product is deliberately narrow: a simulation-first, civilian drone observation and inspection pilot. Users specify an objective; saneX derives the sensing and planning capabilities, selects from a known resource catalogue, generates a governed mission proposal, and produces an auditable result using simulation or authorised operations.
Pilot mission
“Create a documented visual and thermal assessment of a defined, authorised area.”
First prototype — in scope
- Structured mission objective as input
- Small set of derived capabilities
- Catalogue of simulated or preconfigured resources
- Explained resource selection
- Mission plan and checklist generation
- Simulated execution or historical data
- Provenance-rich report
- Human approval before any real-world action
Explicitly out of scope
- Unrestricted autonomous flight
- Arbitrary device discovery on the public internet
- Control of unknown hardware
- Removal of licensed human operators
- Universal multi-domain orchestration
- High-risk surveillance, weapons, or targeting functions
Why now
AI is the catalyst. Architecture and trust are the foundation.
Several developments make capability orchestration newly plausible — but AI progress alone does not solve the product. The hard problems are architectural, legal, and commercial.
What has changed
- Foundation models interpret natural-language objectives
- Agentic systems plan and select tools
- Multimodal models analyse sensor outputs
- Structure can be extracted from API documentation
- Digital twins and simulators allow safer testing
- Robotics & IoT ecosystems expose ever more interfaces
- Policy engines and identity systems govern machine actions
- Marketplaces exist for data, compute, imagery, and services
What stays hard
- Trusted capability descriptions
- Reliable, verified adapters
- Permissions and ownership
- Safety and legal constraints
- Data quality and availability
- Commercial agreements
- Verification of real-world outcomes
Trust & autonomy
AI proposes. Policy constrains. Humans remain accountable.
Real-world orchestration requires more than intelligent planning. saneX separates recommendation, approval, execution, and verification so that autonomy can increase gradually without sacrificing accountability.
Progressive autonomy levels
Default: prepare for approval — never maximum autonomy
Human authority
Humans remain accountable for high-impact missions and physical actions.
Least privilege
Every adapter and mission receives only the permissions required for its approved scope.
Progressive autonomy
Autonomy increases only after simulation, testing, certification, and operational evidence.
Provenance by default
Every relevant input, decision, action, and output is attributable.
Policy before action
The planner may propose actions; the policy layer decides whether they may execute.
Safe failure
Prefer pause, degrade, or abort over improvising outside the authorised scope.
Simulation-first
Unknown missions, adapters, and resources are tested in sandboxes before real-world execution.
Civilian & lawful use
Civilian, authorised, safety-conscious applications — no weapons, no indiscriminate surveillance.
Defensibility
The moat is not the language model.
Models improve and become commoditised. Defensibility comes from what accumulates around them: verified knowledge, trusted integrations, and operational history.
Capability graph
A high-quality semantic model of which resources provide which capabilities under which conditions.
Verified adapter network
Trusted, tested, versioned, and certified integrations into real systems and providers.
Policy & trust layer
Reusable governance patterns for lawful, safe cross-organisational execution.
Execution history
Knowledge of how resources actually perform across conditions, missions, and locations.
Provider network
Relationships with sensor owners, operators, data providers, and service companies.
Mission templates
Proven decomposition and planning patterns for specific mission types.
Business model
Enterprise deployments first. Network economics later.
These are hypotheses to validate, not commitments. The earliest realistic revenue is a paid discovery engagement and a narrow pilot — marketplace economics only once verified supply exists.
First
Enterprise deployment
Organisations operate a private capability registry, mission planner, policy layer, and adapter environment inside their own boundary.
Then
Usage-based orchestration
As missions run, pricing follows what is actually used — missions planned, resources orchestrated, and premium analysis performed.
Later
Provider-network economics
Once verified supply exists, an orchestration fee applies when a third-party capability is booked through the network, alongside adapter certification.
Roadmap
From one bounded mission to a capability economy.
One mission → one capability model → a small verified resource catalogue → simulation-first planning → controlled real-world execution → multiple providers → a cross-domain capability network.
Phase 0 · Thesis validation
Interview operators, asset owners, and mission planners; select one concrete mission type; define regulatory boundaries.
OutputValidated problem statement, initial domain model, first design partners, go/no-go.
Phase 1 · Simulation-first mission planner
Mission schema, small capability graph, fixed catalogue of simulated resources, explained plans.
OutputWorking demonstrator and architecture baseline.
Phase 2 · Controlled real-world pilot
One or two verified drone/sensor platforms, licensed operators, approved missions only, full audit.
OutputNarrow operational pilot, adapter framework, governance model.
Phase 3 · Multi-provider capability network
Onboard providers, add scheduling and commercial terms, introduce capability certification.
OutputEarly network effects, provider portal, marketplace-like discovery.
Phase 4 · Cross-domain expansion
Satellites & telescopes, environmental networks, maritime, laboratories, industrial inspection, robotics.
OutputCapability model proven across domains.
Phase 5 · Capability economy
A trusted network where organisations expose verified capabilities through standard contracts.
OutputGoverned missions assembled across organisational and technical boundaries.
FAQ
Direct answers to fair questions.
Is saneX an autonomous AI agent?
saneX is better understood as a governed mission-orchestration architecture. AI can interpret objectives, suggest plans, and analyse results, but physical actions are constrained by policy, verified adapters, approvals, and explicit autonomy levels.
Does saneX replace device-control systems?
No. Existing control systems, APIs, robotics frameworks, and operator tools remain responsible for device-level execution. saneX sits above them as an intent, capability, policy, and orchestration layer.
Can saneX use resources it has never seen before?
The long-term vision includes assisted capability discovery and onboarding. Unknown resources would first need to be described, mapped, tested, verified, and authorised. An LLM reading documentation is not sufficient for safe physical control.
Why focus on capabilities instead of devices?
A mission is defined by what must be achieved, not by one specific machine. Capability-based modelling allows different resources to be compared and composed according to quality, availability, location, policy, and cost.
Why start with drones?
A bounded civilian drone mission combines planning, sensors, constraints, execution, analysis, and human oversight in one understandable workflow. It is complex enough to validate the architecture but narrow enough for a simulation-first pilot.
How is saneX different from operational data platforms, robotics middleware, or AI-agent frameworks?
Each of those categories solves an important part of the problem: operational platforms integrate enterprise data and govern decisions, robotics middleware handles device-level control, and agent frameworks plan workflows over software tools. saneX is differentiated by combining them around one abstraction — capability-first discovery and governed mission composition across heterogeneous real-world resources and providers.
What is the long-term opportunity?
A trusted capability network where organisations can expose verified sensors, systems, services, and operators through common contracts, allowing governed missions to be assembled across organisational and technical boundaries.
Founder vision
“The next generation of AI should not stop at answering questions. It should help people coordinate the capabilities already present in the world — safely, transparently, and across system boundaries.”
Today, accomplishing a real-world mission means knowing the individual tools, providers, and interfaces involved. The vision is to invert that relationship: describe the outcome you need, and let the system determine which capabilities are required, where they are available, how they combine, and which controls must govern their use. The goal is not uncontrolled autonomy — it is a trusted architecture for moving from intent to coordinated action.
The long-term vision
Every capability, discoverable.
Every mission, governable.
A trusted operating layer through which organisations can describe outcomes and securely coordinate the real-world capabilities needed to achieve them.
Looking for design partners for the first simulation-first pilot.