Terms of service

Private beta

The marketplace is in an invite-only private beta, and these terms are a first version for it. Some features named here run only where they are enabled on the platform, and some steps are done by hand by Latent staff during the beta. Where that matters, the terms say so.

Who these terms bind

This service is run by Latent Energy LLC, a Puerto Rico limited liability company (Latent). Using the site or the API means you accept these terms. A buyer orders units of human robot work; a provider delivers them. Latent runs the marketplace, holds the buyer's credits while an order is open, releases them under the rules below, issues the seeds, checks the manifests, keeps the record of every order, verifies providers and decides disputes. Latent is not a party to the work itself unless it is the buyer or owns the provider. On units from a provider related to Latent, the buyer's decision stands, except that Latent may reverse an accept for a breach (see Providers related to Latent).

Accounts

• You sign in with a link sent to an email address you control, or with Google where offered. There are no passwords; keep your inbox and your API keys secure. During the beta only invited addresses can sign in.
• One account per person. A company account is operated by a named person who is responsible for it. An account cannot order from a provider it owns.
• Anything done with your session or your API keys counts as done by you. The key that delivers a unit is recorded on it. Revoke a key the moment you suspect it leaked.
• You must be 18 or older and able to enter a contract.
• Latent may freeze an account that breaks these terms, which stops its orders, purchases, deliveries and payouts, and may close it by hand. Open orders settle under the order rules first.

Units

Every order is priced per accepted unit. The three unit types are:

• Episode. One teleoperation or autonomous episode on a named robot platform that met the buyer's acceptance bar.
• Intervention. One live human takeover of a running policy, from the moment it stopped acting until it resumed, with the takeover span and the failure class in the manifest.
• Correction. One offline relabel or re-demonstration of a logged failure the buyer supplies, with the failed log and the policy version named in the manifest.

A unit is accepted when the buyer accepts it against the terms of the order, or on the buyer's behalf when the decision deadline passes. Buyers write the terms before ordering; providers deliver a manifest that lets the buyer check them.

Terms on the order

• An order carries its terms: a rubric of acceptance steps, the formats, the rights, the required streams, a minimum active length and the object list, plus the instruction printed on every seed. A task's acceptance bar becomes the first rubric step when the buyer writes no rubric.
• The terms are normalized and hashed when the order is created and do not change afterwards. Every reject code and every check refers to them.
• The buyer sets the decision window per unit, from 1 to 30 days; the default is 7 days. The clawback window is 14 days and is the same for every order.

Seeds and manifests

• Before recording an episode the provider draws a seed from Latent on the order: a random nonce, an episode id, the instruction and the objects. A seed is valid for 72 hours, belongs to one order and one provider, and is used once. Latent issues at most one open seed per unit still to deliver.
• An episode must start after its seed was issued and before the seed expires. The provider shows the nonce in frame at the start of the episode, on the printed seed card or the robot's card display. Latent matches the nonce to the seed; where Latent's checker runs on a unit, it also reads the card in the video. A card proves the recording was made after the seed was issued, unless the video was edited.
• Every delivered unit is a manifest: the seed, the format, where the files are, the operator, robot and station ids, the start time, the duration, the camera count, whether a policy was running and which version, the takeover span and failure class for an intervention, the failed log for a correction, the link latency if measured, and every file with its size and sha256.
• Latent checks the manifest against the seed, the order's terms and every file hash already delivered on the platform, by any provider. A manifest that fails a check is refused and no unit exists; nothing is held or charged for it. A manifest that passes with warnings is stored with them and the buyer sees them.
• A file whose hash was already delivered in another unit is refused. Two exceptions: a provider may deliver again the files of its own unit that was rejected or cancelled, and common dataset metadata files are not compared. Delivering bytes another provider delivered, or bytes already accepted, is a breach of these terms.
• Where Latent custody is enabled, the provider may upload the files to Latent (and must, when the order requires custody): Latent or its storage provider checks every hash against the stored bytes, and Latent serves the buyer's downloads. Otherwise the files stay in the provider's storage at the address in the manifest, Latent records the hashes without opening the files, and the provider keeps every delivered file available to the buyer, unchanged, until the order's clawback window has closed.
• A hash in custody shows that the bytes a buyer downloads are the bytes the provider delivered, unchanged since delivery. It does not show who recorded them, when or where, whether they were edited before delivery, or whether the recording meets the order's terms. Those rest on the seed, the checks, the buyer's decision and the provider's warranties below. For files outside custody, Latent holds only the hashes the provider declared.
• The manifest is the provider's statement. Fields that are false, including the claimed outcome, the timestamps, the operator or the latency, are grounds for rejection, reversal and suspension.

Credits

• 1 credit is 1 US cent of prepaid balance. Balances are shown in US dollars.
• Credits are bought by card through Stripe, between the minimum and maximum shown on the billing page, or granted by Latent against an invoice paid outside the platform or for a pilot.
• Credits are prepaid. They cannot be withdrawn as cash, transferred to another account, or used outside this service, and they earn no interest.
• Refunds are made on request to market@latentenergy.com. Unused available credits bought by card are refunded to the card that paid for them. Credits granted against an invoice or for a pilot are refunded under the terms of that invoice or pilot. Credits held on an open order follow the order rules below.
• A refund or a chargeback removes the refunded or disputed credits from the balance. When more has been spent than remains, the balance goes below zero and new orders are paused until credits are bought or granted to bring it above zero.
• Card payments are charged in US dollars only.
• A card payment that is disputed with the card issuer, including an inquiry, removes the disputed credits and freezes the account (no orders, purchases or deliveries). A dispute Latent wins, or an inquiry that closes, restores its credits and lifts the freeze once no other dispute is open on the account and none was lost. A dispute Latent loses keeps the account frozen until Latent lifts the freeze, after the amount is settled.

Orders and the credit hold

An order moves credits in a fixed sequence. Nothing moves outside it.

• Prices come from the provider's listing at the moment of the request and do not change during the order.
• Each accepted unit is charged once. An order never takes the balance below zero; only a refund or a card dispute can.

Decisions, deadlines and auto-accept

• Every delivered unit carries a deadline unless its robot is revoked as compromised: its delivery time plus the order's decision window, and 72 hours more when the delivering robot was connected to the platform less than a day before. The buyer accepts or rejects the unit before it.
• A reject names a reason code from Latent's closed list (not as specified, wrong platform, missing streams, truncated, duplicate, quality below bar, takeover not needed, takeover late, other) and may add a text that names the rubric step. A reject without a code is not accepted by the platform.
• The buyer may extend a unit's deadline once, before it passes, by one more decision window.
• A unit the buyer has not decided by its deadline is accepted on the buyer's behalf and charged exactly as a buyer accept. Latent runs this check on a schedule; the buyer cannot stop it by staying silent, and the provider cannot bring it forward. Auto-accept waits while the unit is paused, while the order is in dispute, while the buyer's account is frozen, and for up to 48 hours past the deadline while Latent's checks on the unit have not finished. When Latent or the provider revokes a robot as compromised, its undecided units lose their deadline and are never accepted automatically. Under an order's "no people in frame" term there is no such limit: a unit is never accepted by the deadline without a passing people check. Without one it is paused instead, and the buyer can still accept or reject it.
• Once a unit is rejected the buyer deletes any copy of its files it holds, and the platform records the time of the rejection as the time the buyer's right of access ended.
• Automated checks may refuse a delivery that breaks the order's rules, and may pause the auto-accept deadline; they never accept, reject, charge or refund a unit. A Latent admin, or an auditor's reject, may also pause it. Units are accepted or rejected by the buyer, by the deadline in the order, or by Latent on review; on a unit from a provider related to Latent, Latent's review can only reject.

Reversal and the clawback window

• For 14 days after a unit is accepted, Latent may reverse the accept when the unit turns out to breach these terms or the order's terms: for example a false manifest, bytes that do not match the recorded hashes, a recording that predates its seed, or a duplicate that the hash check could not see.
• A reversal moves the charge from the buyer's spent credits back to available, reverses the provider's earning for that unit, marks the unit voided and writes the reason on the order record. The order's status does not change.
• A provider that is not related to Latent may open a dispute on a completed order for the same 14 days after completion, for example against a rejection it believes was wrong. Latent reviews it on the record. During the beta the platform cannot change a decision already made: if Latent finds a rejection wrong, any remedy is agreed with both sides by hand, and the dispute is then closed.
• Earnings are paid out only after the clawback window of the orders they came from has closed.

Cancel and dispute

• A buyer may cancel while the order is open, once every delivered unit has been accepted or rejected. When the provider accepted the order and then delivered nothing for 7 days, the buyer's cancel counts against the provider's track record.
• A provider may cancel at any time before the order completes, except while it is in dispute. Delivered units that were not yet decided become voided: they are not charged and count as neither accepted nor rejected. Once the provider has accepted the order, the cancel counts against its track record: the units left undone count as bad, up to the number delivered on the order and at least one. When the buyer had rejected units on the order, the cancel counts only once a Latent audit upholds one of those rejects.
• Either side may open a dispute once a unit has been delivered and while the order is open. Latent reviews the manifests, the checks, the messages and the order record, and decides each unit not yet decided as accepted or rejected. That decision is final within the platform. When the provider is related to Latent, only the buyer may open a dispute, the buyer still decides each unit not yet decided, and Latent can only reject one (see Providers related to Latent). When Latent closes a dispute with units never delivered, they count against the provider's track record unless Latent finds that the buyer caused the shortfall.

The order record

• Every step on an order (request, response, seeds, delivery, decision, extension, auto-accept, reversal, cancel, dispute, review) is written as an event whose hash covers the previous event. The chain is shown on the order page to both sides and can be recomputed from the published rule on the docs page.
• Latent keeps the record, the manifests, the file hashes and the check results for the periods in the privacy notice. Manifest fields and file hashes delivered to the platform may be used to refuse duplicates on any later order, from any provider.

Custody, checks, keys and audits

• These run only where they are enabled on the platform. Each one flags or refuses, and none of them accepts, rejects, charges or refunds a unit.
• Files in Latent custody are kept for the periods in the privacy notice, then deleted. The buyer's access ends when the unit is rejected or voided; the provider and Latent keep access until the files are deleted.
• A check that finds a fact about the bytes (a broken dataset, frames lost beyond the published limit, a video that cannot be decoded, the recording code of another seed) may pause the unit's auto-accept deadline. The buyer can still accept or reject, and Latent reviews paused units; when Latent clears the pause the buyer has at least 48 hours more to decide.
• A delivery may be signed by a key the provider registered for a cell (a key file on a robot, or a security key). An order may require a signature, a hardware key, custody or physical checks; a delivery that does not meet the order's requirement is refused. A robot connected to a provider account acts for that provider: the provider is responsible for every unit it delivers.
• Auditors Latent appoints audit a sample of units in custody under confidentiality, and Latent compares auditors against hidden test units. Test units are copies made only from units a related provider delivered on orders Latent placed, or from orders whose terms allow audit examples (a choice the buyer makes when ordering, shown to the provider on the order), and are deleted 7 days after they are retired. An audit verdict is a record; an auditor's reject may pause the unit's auto-accept for Latent to review. Only a buyer decision, the deadline or Latent on review moves credits.
• Every hour Latent may publish a Merkle root of all order records, timestamped by outside authorities, on the public transparency page. The page lists roots and leaf hashes, never order ids or parties.

Fees

Latent charges the platform fee in force when a unit is accepted, as a share of that unit's price; it is currently 15%. The fee is taken from the provider's side at the moment the unit is accepted, is returned with the rest when an accept is reversed, and is shown to the provider on the order and in the provider console. A change to the fee is announced to account holders before it applies.

Provider earnings and payouts

• Earnings accrue in the provider's ledger as units are accepted, and are reduced when an accept is reversed.
• Earnings become payable for units whose order completed more than 14 days ago (the clawback window), that are not part of an open dispute, and whose buyer's account is not frozen.
• A provider in the United States can be paid through Stripe. The provider sets up a Stripe account from the provider console and gives its identity and bank details, and the tax details Stripe asks for, to Stripe in Stripe's own onboarding, where it accepts Stripe's terms for connected accounts. Latent sends payable balances to that account only while Stripe has enabled it for payouts, when an admin starts a payout or on the automatic schedule shown in the provider console when that schedule is on, and never while the provider's account is frozen. The automatic schedule skips balances below the minimum shown in the provider console. Stripe pays out to the provider's bank on its own schedule.
• Other providers are paid by bank transfer outside the platform and supply a payout method. Latent may require a tax form (W-9, or W-8 for non-US providers) before the first payout of either kind, and always requires one before the first bank transfer.
• Each payout is recorded in the provider's ledger. A Stripe payout that fails or is cancelled returns its amount to the payable balance. If a Stripe transfer is reversed, the reversed amount returns to the provider's ledger as held: it becomes payable again only if Latent releases it after review.

Provider verification and listing

• A provider profile is public only after Latent verifies it. Latent staff verify by hand, for example by email or on a video call, and may ask for proof of identity, a business registration and proof of control of the robot or cell.
• The verified badge means Latent checked who the provider is and that the described setup exists. It is not a warranty of the work.
• Latent may suspend a listing for breaches of these terms, for a pattern of rejected or reversed units or disputes, for duplicate deliveries, or when the described setup no longer exists. Open orders settle first.
• Stats on a profile (units completed, acceptance rate, response time, rating, the verified track record and the verified score) are computed from orders, audits and reviews on the platform and are not edited by hand. Units between linked accounts (including a buyer on the provider's own company mail domain), practice orders, and orders between a provider related to Latent and Latent's accounts, accounts linked to them or accounts on Latent's mail domains count for neither side.
• The verified track record shows, per robot platform and unit type over the last 12 months, the units accepted (by the buyer or at the deadline), rejected and reversed, the reasons for rejects, the orders closed short, repeat buyers and lead time, with the sample size next to every number. A row with fewer than 3 buyers shows only how many units were decided, its orders closed short and its lead time. The verified score counts accepted units as good and rejected, reversed and cancelled units, and accepted units a Latent audit failed, as bad, weighted by price; a unit accepted at the deadline counts half, a reject a Latent audit overturned counts as neither, and no buyer counts for more than 7 units. The formula is on the docs page. Rates and the score show from 20 units and 3 buyers.

Providers related to Latent

A related provider is a provider owned by Latent or by a person who runs Latent. Today there is one: a robot cell owned personally by Latent's founder, not by Latent Energy LLC.

• A related provider sells through the platform like any other provider. Its units go through the same seeds, manifests, checks, deadlines and reversal rules as any other provider's; decisions and disputes on them follow the rule below.
• While an order's units are being decided, the order page tells the buyer that the provider is related to Latent.
• Latent also places orders with a related provider to test the platform.
• Reviews between Latent and a related provider follow the review rules below, including saying so in their text.
• A related provider, a provider whose account is linked to one of Latent's accounts, and a provider on one of Latent's mail domains are labelled "Related to Latent" on the profile and in the directory. Orders between it and Latent's accounts, accounts linked to them, or accounts on Latent's mail domains count in none of its public numbers, and the profile says how many of its reviews are left out for that reason.

On a unit delivered by a related provider, the buyer's decision stands, except that Latent may reverse an accept for a breach within the 14-day clawback window, which voids the unit, ends the buyer's access and returns the charge to the buyer. Only the buyer accepts such a unit, by deciding or by letting the auto-accept deadline pass. A Latent admin can only reject it, and a reject settles it for the buyer: nothing is charged, and its credits return to the buyer's available balance when the order closes. A related provider cannot open a dispute on its orders, and Latent's audits never count against a buyer's reject of such a unit. If the buyer opens a dispute, the buyer can still accept or reject each unit not yet decided, and a Latent admin can still only reject. The buyer keeps its rights under Governing law below.

This rule covers orders where a related provider is the seller. When Latent places an order as the buyer with a provider that is not related to it, a Latent admin decides a dispute on that order, as on any other order.

People in recordings

Robot recordings can show people: the operator, people nearby, and sometimes children. Latent does not need anyone's face or identity to check a unit.

• Providers keep people who are not part of the task out of frame, and never record a child on purpose.
• Before delivering, a provider has the consent of every person who appears in a recording, and of a parent or guardian for a child. A take that shows a child, or a person who did not agree to be recorded, is not delivered: the provider discards it and records again. If such a take was delivered, the provider tells Latent at once.
• Buyers do not try to identify anyone who appears in a recording, and use footage of people only for the purpose of the order.
• Where the people check runs, Latent scans delivered videos for people and shows the result to both sides as a warning; on its own, a warning pauses nothing. On an order whose terms say "no people in frame" (such an order requires custody), the check fails closed: a unit's auto-accept is paused when the check finds a person, when the scan could not run, when a camera could not be read or stopped short, and when no passing scan exists by the deadline. Such a unit is never accepted by the deadline without a passing people check, even after a Latent reviewer clears the pause; the buyer can still accept or reject it. The check is not calibrated and can be wrong both ways.
• When a person is found, Latent makes a copy of each video with faces blurred, and the buyer may download it instead of the original. Blurring is best effort and can miss a face. The original stays in custody as the record for hashes, disputes and audits.
• When a person who appears in a recording, or the parent or guardian of a child who appears, asks Latent to remove it, or the law requires it, Latent may stop serving the unit's files and delete them, and the buyer deletes any copy it holds. A recording delivered in breach of this section is grounds for rejection, for reversal inside the clawback window and for suspension.

Witness phone (planned)

Latent plans an iPhone app that films an episode from the side while the robot records it. It is not released. When it is, an order may ask for it: the app's video then becomes part of the unit, is stored in Latent custody and is compared with the delivered dataset, and the rules on people above apply to it. These terms will be updated before the app is released.

Rights in delivered units

Providers warrant, for every unit they deliver, that:

• they own or control every right in it, including a written assignment or licence from each human operator who produced it;
• every person who appears in a recording consented to being recorded and to the use described in the order, through a parent or guardian for a child;
• it contains no personal data beyond what the task requires, and no material they are not entitled to share;
• it was recorded after its seed was issued, by the operator, on the robot and at the station the manifest names.

When a unit is accepted and charged, the buyer receives the rights stated in the order's terms. If the terms state no rights, or state Non-exclusive or Undecided, the buyer receives a perpetual, worldwide, non-exclusive licence to use the unit to train, evaluate and deploy models, and the provider keeps its own rights. Rejected and voided units stay with the provider and the buyer deletes any copy it holds.

Buyers warrant that a task asks for nothing unlawful and that they hold the rights they need in anything they hand to a provider. Latent receives a limited licence to store the manifests, hashes and check results, to store files delivered into custody and run its checks on them, to make face-blurred copies of their videos, to display the material in an order to the two sides, to auditors and to staff who decide a dispute, to use file hashes and video fingerprints to refuse duplicates, and, when the order's terms allow it, to keep an accepted unit as a hidden audit example. Latent does not train models on order material. It may run its checks again on delivered units to measure them.

Reviews

• After an order completes, or is cancelled, with at least one charged unit, each side may review the other once: four ratings from 1 to 5 and a text. A review of a cancelled order is shown as one. Orders with nothing charged cannot be reviewed.
• A review is written within 14 days of the order completing or being cancelled. Time the order spends in a dispute is added to the window, since neither side can review during one. After that the window is closed.
• Reviews are published when both sides have written one, or 14 days after the first review, whichever comes first, but a lone review is never published while the other side's window is open or the order is in dispute. Until publication a review's ratings and text are shown only to its author: not to the other side, and not on Latent's admin pages. The order record shows both sides that a review was posted, with a seal (a hash of its ratings and text) and no rating; at publication the record adds what is needed to check the published review against that seal.
• A provider's public rating is shown only once it has 3 or more published reviews from 2 or more buyer accounts in the last 12 months. Each review is weighted by the credits charged on its order, and no single buyer counts for more than 20 percent of the weight, or an equal share when fewer than five buyers have reviewed. A buyer whose rejects Latent's audits have overturned counts for less: after the cap, the weight is multiplied by (rejects upheld + 2) / (rejects audited + 2).
• A provider's profile lists the reviews its rating counts: those published in the last 12 months, on orders not between linked accounts and, for a provider related to Latent, not between it and Latent. It says how many published reviews it leaves out and why. The rule is the same for every review, whatever its rating.
• A review describes the order it is attached to. Latent removes a review only when it contains personal data, threats, content unrelated to the order, or when the order it describes is found to be fake. Latent does not edit reviews and does not suppress negative ones.
• Offering credits, discounts or anything else for a review, or threatening a review to obtain a concession, breaks these terms. A review by a person with a stake in the other side of the order, such as a review between Latent and a related provider, must say so in its text.

Acceptable use

• No tasks that are unlawful, that target a person, or that collect data from people who did not agree to it.
• No moving a matched order off the platform to avoid the fee. Working together outside the platform on new work is fine.
• No scraping of profiles, tasks or reviews, and no automated accounts.
• No false identity, no claims of setups you do not control, no manifests you did not produce, no files recorded before the seed, no bytes delivered twice.
• Keep API use within the published rate limits.

Availability and liability

The service is provided as it is. Latent checks manifests, and the hashes of files in its custody. It does not warrant that a provider's work meets the order's terms, that a buyer will accept units, that a file outside its custody matches its recorded hash, that its automated checks, the people check or the face blurring catch everything, or that the site is available at every moment. To the extent the law allows, Latent's total liability for anything arising from an order is limited to the platform fee Latent earned on that order, and Latent is not liable for lost profits or indirect losses. Nothing here limits liability that cannot be limited by law.

Governing law

These terms are governed by the laws of the Commonwealth of Puerto Rico and applicable United States federal law. Disputes with Latent that are not settled by talking first go to the courts of Puerto Rico.

Changes

The date at the top of this page marks the current version. Latent tells account holders about changes that affect fees, credits, deadlines or rights before they apply. Continuing to use the service after that date means you accept the new version.

Contact

Latent Energy LLC. market@latentenergy.com.