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.
THE CAPABILITY OPERATING SYSTEM
Describe the outcome.
Orchestrate the capabilities.
Tilfang is designed to translate real-world objectives into governed missions, discover the sensors, systems, services, and operators required, and coordinate them through one capability layer.
Concept & architecture — to be 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
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. Tilfang 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.
Tilfang 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.
Tilfang 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
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
A constraint that merely holds decided nothing. The ones marked → did the deciding, and ○ can only be checked during the mission — and can abort it.
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. Tilfang reasons about the required capability first and the concrete resource second.
Example resources providing it — and what separates them
Three attributes, declared the same way by every resource, are what let a plan choose between two of them: where it can get to, how soon, and who must consent. That comparison is what the mission demo’s rationales rest on — and the values are declarations, checked at onboarding, not measurements taken from a named provider.
Required by the mission demo
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?”
Capability onboarding
How an unknown resource would become a bookable capability.
Proposed path · nothing onboarded yet
Discovery can only offer what someone has described, and the execution plane only ever reaches interfaces that have been cleared. A safe onboarding path would run once per resource, in four gates — and any gate can end it.
- Gate 1 of 4
Describe it well enough to match
- 01Discover a candidate resource or service
- 02Retrieve its technical documentation and metadata
- 03Extract a proposed capability description
- 04Map inputs and outputs to the capability schema
Trust boundaryNothing proceeds on prose. A resource whose behaviour cannot be written down as inputs, outputs and conditions is not yet a capability — however well its documentation reads.
- Gate 2 of 4
Constrain it, then build in a sandbox
- 05Identify authentication, policy, cost and safety constraints
- 06Generate a candidate adapter in a sandbox
- 07Test against simulation or non-production endpoints
Trust boundaryThe constraints are recorded before the adapter is written, because they decide what it is allowed to be. Until it has passed simulation, it has talked to nothing real.
- Gate 3 of 4
Have a person clear one named scope
- 08Require human or provider verification
- 09Certify the adapter for a limited capability scope
Trust boundarySomeone signs — the operator or the provider — and what they sign names one capability scope. Anything outside it is a new onboarding, not a wider permission.
- Gate 4 of 4
Keep watching, and be able to revoke
- 10Monitor actual performance and revoke trust if necessary
Trust boundaryCertification is a lease, not a property right. Measured performance is compared with what was claimed, and clearance is withdrawn when the two part company.
“AI may propose a new integration, but unknown physical systems must not be controlled merely because an LLM believes it understands their documentation.”
This path is what the phrase “certified adapter” refers to everywhere else on this page — in layer 6’s trust boundary, in the autonomy levels, in the moat. It is a design, not a running process: no adapter has been through 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; Tilfang 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
The pilot will be shaped with a handful of design partners, each around one bounded, real mission. What that involves
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
Sources · 8
Each enabler is a general statement about the state of the technology, not a claim about this concept. The source given is one current primary example that the development is real — not an exhaustive survey.
- Foundation models interpret natural-language objectivesOpenAI · Function calling guide
- Agentic systems plan and select toolsarXiv · TRAJECT-Bench, an agentic tool-use benchmark
- Multimodal models analyse sensor outputsNASA · Prithvi, a geospatial foundation model in orbit
- Structure can be extracted from API documentationSpeakeasy · Generating MCP tools from OpenAPI
- Digital twins and simulators allow safer testingNVIDIA · Isaac Sim robotics simulation
- Robotics & IoT ecosystems expose ever more interfacesIoT Analytics · State of IoT 2025
- Policy engines and identity systems govern machine actionsCNCF · Open Policy Agent
- Marketplaces exist for data, compute, imagery, and servicesSnowflake · Marketplace
Trust & autonomy
AI proposes. Policy constrains. Humans remain accountable.
Real-world orchestration requires more than intelligent planning. Tilfang 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.
Safe failure
Prefer pause, degrade, or abort over improvising outside the authorised scope.
Civilian & lawful use
Civilian, authorised, safety-conscious applications — no weapons, no indiscriminate surveillance.
The remaining guarantees are already on this page as boundaries: policy decides before anything acts, every claim of success needs evidence, nothing unknown skips the sandbox, and autonomy rises only as operational history accumulates.
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 — most of it is earned mission by mission, adapter by adapter, provider by provider, and the rest depends on people outside the company entirely.
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.
Two that would compound elsewhere
The six above accumulate inside the platform, mission by mission. Two further forms of defensibility would form outside it, on mechanisms worth naming separately rather than filing under the same heading.
Workflow embed
Not a dataset but a position: the capability layer wired into one organisation’s identity system, its approval chains, and the audit record its auditors already read.
What it depends onDeepens per customer rather than per mission, and only with customers willing to let a new layer near those three things. It is also the shallowest of the eight — an incumbent can build the same integration — so depth here buys a lead, not a lock.
Standard-setting potential
If the way a capability and a mission contract are described here becomes a vocabulary other people reuse, the schema carries weight even where the platform is absent.
What it depends onAdoption by parties with no stake in this concept — the only item on this page that cannot be earned alone. It is also the one testable before any platform exists: publish the capability schema, and see whether an operator can describe a real asset in it, or argues with it.
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 granted by the national aviation authority, tied to that specific operation and the risk it carries.
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.
Sources · 3
Three of the six describe regulation or commercial practice that can be checked; the rest describe how tooling is organised today. Sources are given for the first three. None of them says anything about demand for this concept.
- Periodic condition assessment of built assets is in places legally mandated, not merely good practice.EU · Road Infrastructure Safety Management Directive (2019/1936)
- Earth-observation imagery is sold as archive scenes, new tasking, or subscriptions.Geoawesome · Demystifying satellite data pricing
- A commercial drone mission in the ‘specific’ category runs under an authorisation from the national aviation authority, tied to that operation and its assessed risk.EASA · Operational authorisation, ‘specific’ category
Business model
Enterprise deployments first. Network economics later.
Concept stage · nothing priced, nothing sold
These are hypotheses to validate, not commitments, and no price appears anywhere on this page — at concept stage a number would be a guess wearing a decimal point. What can be stated is the unit the money would attach to, and what has to be true before each stage is reachable.
First
Enterprise deployment
One organisation runs the registry, planner, policy layer, and adapter environment inside its own boundary — against its own resources, its own approval chains, and the audit record its auditors already read.
What it would be charged againstThe deployed environment, sized by the scope it governs: how many capability classes are registered, how many adapters are cleared to act. Not per seat — the people who approve a mission are not the ones who plan it, and per-seat pricing keeps the compliance owner out of the room.
What has to be true firstOne customer whose compliance owner will sign one narrow scope. It sells into a budget line that already exists — inspection, monitoring, operations — which is why it can be first. Its weakness: it compounds nothing unless each deployment leaves a reusable capability description and a cleared adapter behind.
Then
Usage-based orchestration
Once missions repeat, part of the price follows what is used rather than what is installed: missions compiled, resources orchestrated, analysis performed.
What it would be charged againstThe mission — what the customer asks for, what the plan is bounded by, what the evidence record is filed under. Resources booked and analyses run sit beneath it as second-order units.
What has to be true firstEnough missions per customer that the line means something other than a licence in instalments. Its weakness is structural: usage pricing taxes the behaviour the concept wants more of, so planning, comparison and simulation have to stay cheap and the price sit where a result is delivered.
Later
Provider-network economics
When supply exists beyond one organisation’s own assets, a third-party capability could be booked through the network — and the layer that made it bookable would charge for the booking.
What it would be charged againstThe booking, plus adapter onboarding and certification as distinct one-off work. Certification means the scope clearance described under Defensibility, not a regulatory approval.
What has to be true firstVerified supply: providers whose capabilities are described precisely enough to be matched and governed, and cleared adapters to reach them. That chicken-and-egg problem is why this stage is last, not why the plan is wrong — the first two would produce the supply. It is still the least evidenced part of the model.
Before any of the three
Those three describe a product being sold. The first invoice would not be for a product — and saying so is more useful than making early revenue look like software revenue.
A paid discovery engagement
Bounded work inside one operation: take a recurring objective the organisation already pays for, describe the capabilities it actually needs, inventory which of its own and its providers’ resources could supply them, and write the plan and approval path a governed version would follow. The customer keeps that document whether or not anything is ever deployed.
What it does not proveThat a product exists. It is consulting revenue, tested where the thesis is weakest: whether an operator can describe a real asset in a shared vocabulary. What would turn it into a product is the same work getting faster on the second customer, because the first left a reusable capability class behind. Otherwise this is a services company with a good architecture diagram.
Why in-boundary, and not a network
The resources a first customer would orchestrate are largely already theirs or their contracted providers’, and the approval chains and audit record they answer to sit inside one boundary. A network asks a compliance owner to sign an outbound flow to parties they hold no contract with, before anything has been demonstrated. In-boundary asks for the smaller signature.
What it does not proveThat it scales by itself. It is the shape with no network effect: one deployment makes the next no easier unless it leaves behind a capability class, a cleared adapter and a governance pattern that the next one reuses — three of the six assets named under Defensibility, and this is the stage that would pay for them.
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
Satellite remote sensing, 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 Tilfang an autonomous AI agent?
Tilfang 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 Tilfang replace device-control systems?
No. Existing control systems, APIs, robotics frameworks, and operator tools remain responsible for device-level execution. Tilfang sits above them as an intent, capability, policy, and orchestration layer.
Can Tilfang use resources it has never seen before?
The long-term vision includes assisted capability discovery and onboarding. Unknown resources would first need to pass the ten-step onboarding path set out under Product architecture above — described, mapped, tested, verified, and authorised, one named scope at a time. 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 Tilfang 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, and Tilfang does none of their jobs. It would sit above them as the orchestration layer — capability-first discovery and governed mission composition across heterogeneous real-world resources and providers. Category by category, what each is good at and where this concept would differ:
Supply it would book
These build the physical and analytical supply. An orchestration layer without them has nothing to orchestrate.
Sensor & platform networks
Their strengthThey own the hardware and the access rights any real mission depends on — satellites and their tasking windows, aircraft and licensed crews, fixed installations, ground stations.
What a mission still needsWhich of them can answer this objective, at what resolution, lead time, cost, and approval burden — and what the plan does when the first choice is unavailable.
Perception & analysis models
Their strengthThey turn raw signals into meaning, increasingly with domain-specific models trained on far more data than an orchestration layer would ever see.
What a mission still needsWhat to observe in the first place, under whose authorisation, and which action a finding justifies. A model explains an anomaly; it does not decide who is sent to look at it, or whether they may.
Platforms it would sit above
Each of these solves a real part of the problem inside its own boundary. The distinction is the boundary, not the quality of the work.
Operational data & decision platforms
Their strengthEnterprise data integration, ontologies, workflow, and governed decisions over what an organisation already holds.
Where this differsCapability discovery outside that estate and across providers — and composing the mission that produces the data, rather than reasoning over data already collected.
Autonomy & mission-system platforms
Their strengthVertically integrated stacks: their own hardware, edge autonomy, sensor fusion, and command and control, tuned end to end for one fleet.
Where this differsCivilian and cross-industry by design, provider-neutral, and owning no hardware — the capability graph spans fleets it did not build, including vendors that compete with one another.
Robotics middleware & fleet management
Their strengthDevice communication, navigation, control, and reliable local execution — the layer that actually makes a machine move.
Where this differsStarts one level up, at objective → capability → resource, across fleets and organisations. Middleware stays responsible for what the machine does.
AI-agent frameworks
Their strengthTool use, workflow planning, natural-language interfaces, and fast integration across software tools.
Where this differsA physical action is not a callable function. It needs a verified adapter, a named approval scope, a stated autonomy level, and evidence that it happened the way it was planned.
IoT & digital-twin platforms
Their strengthConnected assets, telemetry, device management, and models of an estate that is known in advance.
Where this differsMissions composed across resources that sit in no predefined estate — including ones belonging to other organisations, discovered by what they can do.
None of this claims the work would be done better. The difference is the unit each layer starts from — a device, a dataset, a fleet — where this one starts from a capability and the mission that needs it.
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.”
None of this is settled at a desk. Whether an operator can describe a real asset in a shared vocabulary; whether a compliance owner will sign one narrow scope rather than refuse a broad one; whether a plan survives the constraints of an actual site — those answers exist only inside somebody’s operation. That is why the next step is not more architecture. It is one real mission, with the people who already run it.
The long-term vision
Every capability, discoverable.
Every mission, governable.
That is the destination, not the status: none of it is built. What exists today is an architecture, a set of claims anyone can check, and one bounded mission worth running first.
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
or write to [email protected]
Looking for design partners for the first simulation-first pilot.