Platform
One capability layer between intent and evidence.
Three parts, in the order a mission would meet them: the capability graph that describes what resources can do, the seven layers that turn an objective into a governed plan, the onboarding path an unknown resource would have to pass — and the autonomy model that keeps a person accountable throughout. All of it is design, stated precisely enough to be argued with; none of it is a running system.
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 site — in layer 6’s trust boundary above, in the autonomy levels below, and in the moat on the front page. It is a design, not a running process: no adapter has been through it.
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.
The demo shows this design at work on three sample objectives — and the front page argues why it is worth building at all.