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, operates no fleet, and trains no perception models. It is the orchestration layer above the capability networks others build — not a competing supply network.

What this layer is not

Sensor & platform networks
Build and operate the physical supply — satellite constellations, drone fleets, monitoring and camera networks.
SupplyDiscovered and booked as resources that provide a capability.
Perception & analysis models
Turn raw signals into meaning — imagery, time series, and multimodal streams read by a model rather than a person.
SupplyBooked against a capability node like any other resource.
Device control & robotics middleware
Command individual machines reliably and safely at the device level.
SupplyReached only through a certified adapter, never driven directly.
Enterprise data & agent platforms
Integrate business data, or plan and execute workflows over software tools.
AdjacentThe same planning instinct, applied to records and APIs rather than physical capability.

The layer would begin where these stop: deciding which capability an objective actually requires, which resource should provide it, and under whose policy and approval it may run.

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.

    Constraints evaluated

      Candidate resources — and why each was chosen or not

        Availability and selection are two different questions. Where two resources answer the same requirement, the trade-off between them is what decides — being eligible is not, and a blocked resource has to be routed around rather than merely labelled.

        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.

            Concept stage · nothing accumulated yet

            Models improve and become commoditised. Defensibility would come from what accumulates around them: verified knowledge, trusted integrations, and operational history. None of it can be bought in one move — each asset is earned mission by mission, adapter by adapter, provider by provider.

            Capability graph
            A high-quality semantic model of which resources provide which capabilities under which conditions.
            How it would be earnedGrows whenever a real mission forces a capability to be described precisely enough to be matched, priced, and governed.
            Verified adapter network
            Integrations into real systems and providers — tested, versioned, and cleared for a defined scope.
            How it would be earnedOne adapter at a time: sandbox, simulation, human or provider verification, then certification limited to that scope.
            Policy & trust layer
            Reusable governance patterns for lawful, safe cross-organisational execution.
            How it would be earnedAccumulates from each approval negotiated with a real legal, safety, or compliance owner — and reused on the next mission.
            Execution history
            Knowledge of how resources actually perform across conditions, missions, and locations.
            How it would be earnedOnly from missions that ran. This one cannot be licensed, scraped, or generated — it is the slowest asset on the list.
            Provider network
            Relationships with sensor owners, operators, data providers, and service companies.
            How it would be earnedBuilt provider by provider, each with commercial terms and a capability description someone is willing to stand behind.
            Mission templates
            Proven decomposition and planning patterns for specific mission types.
            How it would be earnedDistilled from missions that ran end to end — including the ones that failed, and the reason they did.

            None of these assets exist today. What can be judged at concept stage is whether they are the right ones to accumulate, and whether the initial wedge is the cheapest honest way to start.

            “Certified” on this site means one thing only: the concept’s own onboarding path has cleared a specific adapter for a named capability scope, and can revoke that clearance. It is not a regulatory or third-party safety certification, and none is claimed. Capability certification sits in roadmap Phase 3, after the controlled pilot.

            Where this sits

            Adjacent markets, not a market size.

            A top-down market number at concept stage is a guess presented as a forecast. What can be stated honestly is where this work is already being done and paid for, and which seam a capability layer would attach to. These are the six markets the concept sits adjacent to.

            Industrial inspection
            TodayRecurring — and often legally mandated — condition assessments of built assets: structures, plants, energy and transport infrastructure. Each round is scoped, scheduled, and evidenced largely by hand.
            The seamA repeating objective compiled into a governed plan, with the evidence trail produced by execution rather than assembled after it.
            Remote sensing & earth observation
            TodayImagery and derived data sold as archive scenes, new tasking, or subscriptions. The buyer picks sensor, resolution, and product before the question is answered.
            The seamA request stated as a capability and a quality bar, with the product selected to satisfy it instead of chosen up front.
            Drone operations & services
            TodayLicensed operators fly bounded missions under an authorisation tied to that specific operation, its risk assessment, and the remote pilot’s training.
            The seamOperators as bookable capability providers, with authorisation and approval carried as mission constraints — never routed around them.
            IoT & robotics orchestration
            TodayFleets, devices, and machines are managed per vendor and per platform, each with its own control plane, data model, and permissions.
            The seamOne capability abstraction above those control planes, so a mission can combine several without an integration project per pair.
            Environmental monitoring
            TodayAgencies, utilities, and consultancies run repeat measurement programmes where comparability across seasons and years matters more than any single reading.
            The seamMission templates that record which resource was used under which conditions, so a later run stays comparable to an earlier one.
            Mission & field-operations software
            TodayPlanning, dispatch, and reporting tools organise the people and jobs of a single organisation, around resources it already owns.
            The seamThe same workflow composed across organisations and providers, and grounded in what a resource can actually do.

            The initial wedge sits where the first three overlap: a documented visual and thermal assessment of a defined, authorised area is one bounded mission whose supply chain already exists — an operator, a sensor, an analysis step, a report — which is what makes it the cheapest honest test of the abstraction.

            Adjacency says where the concept would compete for a budget that already exists. It is not evidence that anyone wants it — that is what the pilot is for.

            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 sensor networks, analysis models, operational data platforms, robotics middleware, or AI-agent frameworks?

            Each of those categories solves an important part of the problem: sensor and platform networks build the physical supply, perception and analysis models turn raw signals into meaning, operational platforms integrate enterprise data and govern decisions, robotics middleware handles device-level control, and agent frameworks plan workflows over software tools. saneX does none of those things. It would sit above them as the layer that decides which capability an objective requires, which resource should provide it, and under what policy it may run — capability-first discovery and governed mission composition across heterogeneous real-world resources and providers. Most of those categories are therefore supply it would book, not competition.

            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.