FAQ
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.
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.
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 on the platform page — described, mapped, tested, verified, and authorised, one named scope at a time. An LLM reading documentation is not sufficient for safe physical control.
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.
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.
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:
These build the physical and analytical supply. An orchestration layer without them has nothing to orchestrate.
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.
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.
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.
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.
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.
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.
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.
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.
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.
A question this page does not answer is worth asking directly — that is how it earns its place here.