Skip to content
saneX
Get in touch

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.

Explore the conceptSee a mission unfold

Concept & architecture — to be validated through a simulation-first pilot

OBJECTIVEAssess the areaObserveMeasureAnalyseReportSatellite archiveDrone + operatorWeather APIChange detectionHuman reviewerHUMAN APPROVAL GATEEVIDENCE + AUDIT TRAIL
Conceptual illustration — synthetic mission, no live systems

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

21.1 billion connected IoT devices estimated worldwide by the end of 2025, growing 14% a year — and connected devices are only one slice of the capability the world already operates.IoT Analytics · State of IoT 2025

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

  1. Choose device
  2. Operate interface
  3. Collect output

The device defines what is possible. The human does the integration work.

saneX approach

  1. Define objective
  2. Derive capabilities
  3. Find resources
  4. Govern & execute

The objective defines what is needed. The system finds, compares, and coordinates the resources — under policy.

saneX builds no sensors and operates no fleet. It is the orchestration layer above the capability networks others build — not a competing supply network.

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

    Each requirement resolves to a node of the capability graph below. Platform marks a function the architecture layers provide — not something a resource is discovered for.

    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.

            Open a layer for its purpose, components, and trust boundary.

            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.

            1. First

              Enterprise deployment

              Organisations operate a private capability registry, mission planner, policy layer, and adapter environment inside their own boundary.

            2. Then

              Usage-based orchestration

              As missions run, pricing follows what is actually used — missions planned, resources orchestrated, and premium analysis performed.

            3. 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.

            1. 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.

            2. Phase 1 · Simulation-first mission planner

              Mission schema, small capability graph, fixed catalogue of simulated resources, explained plans.

              OutputWorking demonstrator and architecture baseline.

            3. 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.

            4. Phase 3 · Multi-provider capability network

              Onboard providers, add scheduling and commercial terms, introduce capability certification.

              OutputEarly network effects, provider portal, marketplace-like discovery.

            5. Phase 4 · Cross-domain expansion

              Satellite remote sensing, environmental networks, maritime, laboratories, industrial inspection, robotics.

              OutputCapability model proven across domains.

            6. 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.

            Design partners

            The first pilot (roadmap Phases 0–1) will be shaped with a small number of design partners, each around one bounded, real mission. This is a concept-stage collaboration — structured interviews and simulation-first modelling, not a product deployment.

            What a partner brings

            • One bounded, recurring mission they already run — a defined inspection, assessment, or monitoring task
            • The constraints that make it real: regulatory boundaries, safety rules, and data-handling requirements
            • A few hours of practitioner time for interviews and for reviewing mission models and simulated plans

            What a partner gets

            • A structured mission and capability model of their own workflow — reviewable, and useful beyond this pilot
            • Priority access to the simulation-first demonstrator as it takes shape, and to any later controlled pilot
            • Direct influence on the capability schema and policy model while both are still forming
            Build the first mission with us

            Looking for design partners for the first simulation-first pilot.