Request access

How it works · TAP

From request to receipt.

Any person, business, agent or machine can ask for a physical outcome. Teleport routes it to someone who can do it, checks the work, and issues a proof anyone can verify.

Request API accessSee what a proof proves
A task, from request to receiptFloor plan. A delivery robot waits in a corridor at closed door 3B and posts a task. Teleport routes it to a person nearby, who walks over and holds the door while the robot rolls through. The evidence passes rule checks, a bounded model and policy, and a receipt is printed and stamped verified.3A3B3CCORRIDORDOOR 3BTASK · OPEN 3B · $3.00RULE CHECKS ····· PASSMODEL ··········· 0.98POLICY ········· ACCEPTPROOF OF PHYSICAL WORKOPEN DOOR 3BROBOT ASKED · HUMAN DIDCLAIM 0xe7e7…d547VERIFIED
§ 01

Five steps, one record.

Every task moves through the same lifecycle, whoever asks and whoever does it. Dashed means claimed. Solid means proven.

  1. 01 · Post

    Post

    Describe the outcome, not the method: what done looks like, who may do it, what evidence counts and what it pays. Machines post under a mandate their owner set.

    DRAFT → VALIDATED → FUNDED
  2. 02 · Route

    Route

    Teleport finds an eligible performer nearby, uses the one you designate, or skips this step when the work already happened.

    MATCHING
  3. 03 · Perform

    Perform

    A person or machine does the work and captures evidence as it goes: guided video and photos, telemetry, logs.

    ACTIVE
  4. 04 · Verify

    Verify

    Rule checks, perception and a bounded decision model score the evidence. A versioned policy makes the call. Uncertain work goes to a person.

    VERIFYING → ACCEPTED
  5. 05 · Prove

    Prove

    Accepted work is paid in dollars and committed to a Proof of Physical Work, batched and anchored on Base.

    FULFILLED · PoPW ANCHORED
§ 02

Anatomy of a task.

A TAP task specifies the work — and who is accountable for it — before anyone lifts a finger. This is the door-assist task from the film, abridged. Point at a part to find it.

task_door_3b_0001 · TAP v0.2 · abridged
{
  "title": "Open door 3B for a delivery robot",
  "category": "OPERATE",
  "requester": { "requesterType": "ROBOT",
    "principal": { "principalType": "ORGANIZATION" },
    "mandateId": "mdt_amr_fleet_help_v3" },
  "trigger": { "type": "ROBOT_EXCEPTION" },
  "fulfillment": { "mode": "MARKETPLACE" },
  "actorRequirement": { "permittedActorTypes": ["HUMAN", "HUMANOID"] },
  "completionConditions": [
    { "type": "TRANSITION", "id": "robot_passed" },
    { "type": "STATE", "id": "door_closed_after" } ],
  "evidenceProfiles": [{ "requiredEvidence": [
    { "type": "ODOMETRY", "acceptedOrigins": ["ATTESTED_DEVICE"] },
    { "type": "IMAGE", "acceptedOrigins": ["TELEPORT_CAPTURE"] } ] }],
  "verificationPolicy": { "policyId": "door-assist", "version": "1.0" },
  "rightsPolicy": { "policyId": "operational-evidence-v1" },
  "economics": { "performerPayUsdCents": 300,
    "requesterPayment": { "method": "MANDATE_BUDGET" } },
  "popw": { "required": true, "proofTiming": "WORKFLOW" }
}
  1. Outcometitle · categoryThe physical result wanted, not how to get there.
  2. RequesterrequesterWho asked — and the person or organization that answers for it.
  3. TriggertriggerThe event that caused the task. Required whenever a machine posts.
  4. Fulfillmentfulfillment.modeTeleport routes it, you bring your own performer, or Teleport only verifies.
  5. Eligible performersactorRequirementWhich kinds of actor may do it, and with which capabilities.
  6. Completion conditionscompletionConditionsTestable statements of what done means.
  7. Evidence and originevidenceProfilesWhat proves each condition, and where that evidence is allowed to come from.
  8. Verification policyverificationPolicyA versioned rulebook that turns evidence into a decision.
  9. RightsrightsPolicyWhat may be done with what was captured.
  10. PriceeconomicsPriced in US cents. Paid in dollars or USDC — never in $PORT.
  11. ProofpopwWhether a Proof of Physical Work is issued, and how it is batched.
§ 03

Anyone can ask. Someone always answers for it.

A robot, a sensor or an AI agent can originate a task. It can't be the party responsible for it. Every task resolves to an accountable person or organization.

Who can post a task

  • Person
  • Organization
  • AI agent
  • Humanoid
  • Robot
  • Vehicle
  • Drone
  • Device

Machines may ask humans for help. They may not manage them.

TAP v0.2 · §2.4

When a machine posts, the person doing the work is told: “Requested by an automated system for Acme Logistics.” The task can't grow once it starts, and anyone can decline or stop for safety without penalty.

Posting mandatemdt_amr_fleet_help_v3
Issued by
Acme Logistics (verified organization)
May post
OPERATE tasks only
Spend
Up to $5 per task · daily cap
Approval
Automatic under $5; a person approves above
Rate limit
A sensor storm can't post a thousand tasks

Checked before quoting and payment. A task outside its mandate is rejected or held for approval — never quietly narrowed.

§ 04

Three ways to get it done.

Teleport doesn't need to own the workforce to prove the work. Verify-only and direct modes need no marketplace at all.

  1. MARKETPLACE

    Marketplace

    Teleport finds an eligible performer, assigns the work, pays them, verifies the result and issues the proof.

    A robot needs door 3B opened. Someone nearby does it for $3.00.

    VALIDATED → FUNDED → MATCHING → ACTIVE → FULFILLED
  2. DIRECT

    Direct

    You bring your own performer or fleet. Teleport checks it meets the spec, then verifies and proves the work.

    A warehouse proves every tote its own robots deliver.

    VALIDATED → FUNDED → ACTIVE → FULFILLED
  3. VERIFY_ONLY

    Verify-only

    The work happened outside Teleport. Evidence is submitted against the spec. Weak evidence can trigger a fresh capture task.

    A property manager checks a contractor's drywall repair.

    VALIDATED → FUNDED → AWAITING_EVIDENCE → FULFILLED
A freshly patched and painted wall in an empty room

Verify-only, upgraded

A contractor uploads photos of a repair. The evidence is thin, so Teleport posts a linked capture task and someone nearby re-photographs the wall. Weak evidence becomes strong evidence, instead of a flat no.

§ 05

Models estimate. Policy decides.

“AI verified” is not an auditable statement. “Verification policy door-assist v1.0 accepted this evidence” is. The model never releases money or issues a proof on its own.

  1. 01

    Rule checks

    Are the facts right?

    Files present, recording continuous, hashes match, barcode equals the SKU. Never delegated to a model.

  2. 02

    Perception

    What can be observed?

    Detection, OCR, pose and change detection turn evidence into normalized observations.

  3. 03

    Bounded decision

    What does it mean?

    Jev answers typed questions — completed, matches the task — with probabilities, not prose.

  4. 04

    Policy

    What is Teleport allowed to do?

    A versioned policy accepts, rejects or sends to review. It alone releases payment and proof.

  5. 05

    Human review

    When it isn't clear

    Uncertain outcomes, privacy exceptions, high-value work and disputes go to a person.

Try a score against the policy

ACCEPT if P(COMPLETED) ≥ 0.97 AND rule checks PASS

Accepted. Above the line. Payment is released and a proof is issued.

Review. The model says 0.95. The policy asks for 0.97. A person takes a look.

Rejected. Rejected, with the reason. A fresh attempt can be requested.

§ 06

Every proof says where its evidence came from.

A proof built on uploaded photos says so, and can only reach the standard tier. Evidence captured under Teleport's integrity controls can go higher.

Evidence originStandardVerifiedHigh assurance
Teleport captureTELEPORT_CAPTUREGuided capture in the Teleport appmax
Attested deviceATTESTED_DEVICEA registered robot or sensor with attestationmax
Actor telemetryACTOR_TELEMETRYSigned logs from the performermax
SubmittedTHIRD_PARTY_SUBMITTEDUploaded files, no Teleport capture chainmax
§ 07

Twenty-four kinds of work, and a custom one.

Categories help route and discover tasks. They don't limit what the protocol can carry.

  • OBSERVE
  • INSPECT
  • MEASURE
  • VERIFY
  • MOVE
  • TRANSPORT
  • DELIVER
  • PICK
  • PLACE
  • MANIPULATE
  • SORT
  • LOAD
  • UNLOAD
  • STOCK
  • ASSEMBLE
  • DISASSEMBLE
  • CLEAN
  • MAINTAIN
  • REPAIR
  • OPERATE
  • NAVIGATE
  • MONITOR
  • CAPTURE
  • DEMONSTRATE
  • CUSTOM

Build on TAP

Write your first task.

We're onboarding design partners and developers now. The protocol is a preview and may change.