Before execution
Identity, provenance, approved baseline, mission semantics and current readiness establish whether physical work may continue toward dispatch.
TTAN.IO Robotics / physical authority chain
From digital intent to bounded physical authority.
TTAN.IO Robotics does not treat a login, certificate, API connection, ROS 2 permission, AI recommendation or successful provider call as permission for arbitrary physical work. Authority is progressively narrowed across six stages and then checked against what the robot actually did.
Each stage may narrow or stop authority. No later stage is allowed to widen what an earlier stage permitted.
Core ruleALLOW is not DISPATCH.
A security decision can say that a mission is admissible while execution still remains blocked until identity, state, readiness and exact command material all match.
01 · Identity + provenance
Know who is asking — and where the request came from.
TTAN.IO begins by establishing trusted source context. A command may originate from an operator, HMI, MES, PLC, ROS 2 node, vendor application, planner or AI service. The system records the authenticated identity and provenance of that request without confusing identity with authority.
A valid certificate or authenticated ROS/DDS participant proves something about the requester. It does not prove that the requested physical action is allowed.
Input
Authenticated source context
Workload identity, operator context, provider path, signed request metadata and other trustworthy source evidence.
Decision
Identity is accepted as evidence
The source is known strongly enough to continue evaluation, but receives no automatic physical authority.
Failure behavior
Unknown or ambiguous identity fails closed
Caller-controlled headers, stale credentials or uncertain provenance cannot silently become trusted execution context.
TTAN.IO law:
Identity is not application authority, and application authority is not physical authority.
02 · Robot + baseline
Bind the request to the robot’s approved behavior.
Every protected robot can carry a profile describing its identity, capabilities, tools, allowed zones, operational limits and approved behavior baseline. TTAN.IO evaluates the requested mission against this known context instead of assuming that any syntactically valid command is legitimate.
Production drift does not automatically become the new baseline. Changes require controlled provenance, validation and promotion.
Robot context
Which machine is this?
Tenant, plant, line, cell, robot identity, controller/provider identity, toolset and capability context remain attributable.
Baseline
What behavior is approved?
Programs, jobs, limits, zones, tools and expected production behavior are versioned rather than learned silently from runtime drift.
Mismatch
Deviation can stop eligibility
Unexpected tool, program, zone, capability or baseline state can trigger HOLD, DENY or HUMAN_REQUIRED.
TTAN.IO law:
The robot is evaluated against approved behavior, not merely against what it is technically capable of doing.
03 · Mission validation
Validate the requested physical effect.
The request is normalized into a security-relevant mission representation. TTAN.IO evaluates the intended robot action, target, tool, zone, destination, limits and production context against policy and capability.
This is where an authenticated and technically valid command can still be rejected because its physical meaning is wrong for the current mission.
Normalize
Turn provider syntax into security meaning
Vendor-specific API calls, ROS actions or PLC requests are mapped into stable mission semantics before authority is considered.
Validate
Check policy + capability + context
Robot capability, approved behavior, target, zone, tool, limits and current production rules are evaluated together.
Outcome
ALLOW, DENY, HOLD or HUMAN_REQUIRED
The result can permit continuation, stop the mission or require human intervention without dispatching anything yet.
TTAN.IO law:
A security decision can make a mission eligible; it does not by itself create executable command authority.
04 · Execution readiness
Check whether execution is admissible now.
A mission that was valid moments ago may no longer be executable. TTAN.IO re-evaluates time-sensitive conditions before privileged dispatch: robot state, provider connection, controller status, relevant trust evidence, baseline freshness, replay state and other required preconditions.
Reconnects, failovers and provider changes are treated as new security events rather than reasons to inherit stale authority.
Fresh state
Current, not historical
The system evaluates current readiness instead of relying on an old ALLOW or an earlier connection state.
Provider boundary
Connectivity is checked, not trusted
A working adapter or credential proves reachability. It does not widen the mission or command that may be dispatched.
Replay protection
One authorization, one effect
Consumed, stale or ambiguous authorization material cannot be reused to generate a second physical effect.
TTAN.IO law:
Past eligibility never guarantees present readiness.
05 · Exact command binding
Authority is bound to the command that will actually be sent.
Immediately before privileged dispatch, TTAN.IO binds authority to the exact normalized execution material. Robot, mission, parameters, tool, target, zone, provider path and other security-relevant fields become part of the command context.
If any bound field changes, the previous authority no longer applies. This prevents a valid approval from being reused for a modified physical action.
Binding
Exact execution material
The authorized object is not “the session” or “the user”; it is the bounded command context that will reach the provider/controller path.
Mutation
Change invalidates old authority
Robot, target, destination, tool, zone, limits or parameters cannot change underneath an existing authorization.
Dispatch
Provider adapters cannot create authority
The adapter translates and sends authorized material. It must never broaden scope because a vendor API permits more.
TTAN.IO law:
The exact command is the unit of physical authority.
06 · Observed outcome
Verify what happened in the physical world.
A successful API response is not accepted as physical truth. TTAN.IO separates what was requested, authorized and sent from what controllers, sensors, PLCs, ROS/DDS telemetry and other independent sources report afterwards.
Evidence is reconciled so missing, conflicting or ambiguous observations cannot silently become verified success.
Evidence
Multiple independent sources
Controller state, ROS telemetry, PLC/interlock state, sensors, vision and provider records can contribute to terminal evidence.
Reconcile
Expected vs observed
TTAN.IO compares approved/authorized intent with execution claims and the observable state of the robot and production context.
Terminal truth
Unknown remains unknown
Missing or contradictory evidence does not become success, and ambiguous outcomes do not trigger blind retry.
TTAN.IO law:
Do not trust the command. Do not trust the report. Correlate independent evidence.
The complete chain
Trust is narrowed, never widened.
At execution
Authority is bound to the exact command and privileged provider boundary. Changes invalidate stale authority.
After execution
Independent evidence establishes what actually happened and whether the observed result reconciles with the authorized mission.