Sign in

Limitations

Each API publishes this list through its own /limits endpoint; it is shown here unchanged. Read it before you rely on a result.

The service

  • Availability. The service runs on one server in one data centre. There is no availability commitment on the self-service plans; measured availability is published on the Status page from the day of launch.

Verification API

  • Receipt chains are not signed. A receipt chain carries no signature. A valid result shows that the chain agrees with the published rule; it does not show who wrote the chain, and an unsigned chain held only by one party does not prove that this party did not rewrite the history.
  • A cut-off or re-hashed chain needs an expected head. Without an expected head, a chain that was shortened at the end, or altered and then fully re-hashed, is still reported as link-valid. Supply the head you obtained through a separate channel as expected_head to detect both.
  • Receipts are checked for integrity, not for truth. The service checks that the receipts were not altered after they were written. It does not check that the operations they describe took place, or that their timestamps are correct; the timestamps come from the clock of the machine that wrote them.
  • Size of a receipt chain. A request may hold at most 10000 receipts and 5 MB. Numbers with a fraction or an exponent, which the hash rule does not cover, make a receipt fail, and an object with a duplicate key is refused.
  • Signature trust rests on the keys you supply. Signatures of a computation record are checked only against the trusted keys sent with the request. The service never uses a key found inside the pack. Without trusted keys the response states that signature trust was not established. A result is worth as much as your confidence in where your keys came from.
  • A log run by the producer. When the log is operated by the producer of the records, both tree heads arrive in the same pack. The inclusion and consistency proofs show that the files of one pack agree with each other; they do not show that the producer has only one log or shows the same log to everyone.
  • No time is independently attested. Every time in a computation record or a tree head comes from the clock of the producer or of the log operator. Nothing in a verification shows that a record existed at the time it states.
  • Replay depends on the machine. Replay runs the model with ONNX Runtime 1.31.1 on the CPU of the server that runs this service. Results can differ in the last bits between machines and runtime releases. The response states whether the replay was exact, within the tolerance signed in the record, or outside it, with the deviation of every value.
  • Replay executes the model you send. Replay executes the model file of the pack after the model acceptance check of the specification, which refuses external data, custom operator domains and control flow. That check limits what a model can ask the runtime to do; it is not a sandbox. Each verification runs in a separate process that is stopped after 60 seconds or when it exceeds 1536 MB of memory.
  • Size and form of a pack. A pack may be at most 10 MB as sent and 24 MB unpacked. Only the nine files named in the specification are read. Version 2 supports one float32 input tensor and float32 outputs only.
  • A passing record does not show that a detection is right. A passing computation record shows that a computation took place as stated. It does not show that the flagged material is coordinated, that the model is accurate, or that the input numbers were derived correctly from the material they stand for.
  • Independent checking. The responses of this service are not signed and are statements by its operator. For a result that does not depend on us, run the published verifiers on your own machine; they need neither our code nor our server.

Memory API

  • Name the subject for reliable answers. A query that names the subject and relation of a stored fact (mode keyed) is answered from that fact. A relation worded differently from the stored one usually does not match: the service is set to avoid wrong answers rather than to catch paraphrases. When nothing is stored for the subject, the model answers as it would without the service.
  • Place addresses are exact keys. A fact can carry a place address such as home/kitchen/shelf. Lookup by address (mode address) is an exact match on the address and, when given, the relation. It does not interpret free text, does not match a similar or partial address, and abstains when nothing is stored at the address. Listing by prefix matches whole segments only.
  • Free-text questions are best effort. Mode natural looks for a stored subject named literally in the text and for the relation's words. It does not resolve paraphrases, synonyms, pronouns or misspellings, and every such response carries best_effort true. Use mode keyed or mode address when the answer matters.
  • Answer length. An answer can be up to 8 tokens of the model's vocabulary, which is usually a few words. Longer answers are refused with the code answer_too_long, and an answer the model cannot be made to produce is refused with answer_not_expressible, together with suggestions.
  • Completion prompts, not chat. Facts are applied when the model continues a prompt as given, with no chat template. A stored answer is not guaranteed to appear inside a chat-formatted conversation or after different wording, while the answer field of the response always gives the stored answer. Generation is greedy, so the same request gives the same output.
  • Output is unchanged where no fact applies. When no stored fact of the requesting account matches, the output is identical to the unmodified model, whatever this or any other account has stored. The proof endpoint shows this on the account's own facts.
  • Size of a knowledge base. An account holds up to the number of facts of its plan, at most 2,048. Larger knowledge bases are offered under an Organisation agreement after testing on the customer's data.
  • One fixed open model. The service runs one open model, Qwen/Qwen3-0.6B, with its weights unchanged, on CPU. It does not check whether a stored fact is true; the content of the facts is the customer's responsibility.
  • Typical response times. Storing or correcting a fact takes about one second. A keyed query without generation takes a few milliseconds, and generating a short answer takes under one second. Requests that use the model are processed one at a time, so times grow under load.
  • What the receipt chain proves. Every registration, correction and removal appends a receipt to the account's SHA-256 hash chain, which can be exported and checked with the open verifiers. The chain shows that the record was not altered after it was written; it does not show that the service did what a receipt says, and its timestamps come from the service's clock. A shortened or fully re-hashed chain is detected only against a head held by a second party.
  • What the signatures prove. Each receipt hash and each head statement is signed with the service's Ed25519 key, published at /keys. A signature stops someone who holds only the exported file from altering it unnoticed. It does not stop the holder of the signing key from rewriting the history, so keep a dated head statement with a second party when that matters.

Signals API

  • The limitations of this API could not be loaded. Please try again later.

Spatial Memory API

  • How objects are matched. Objects are matched by their position and motion history, with an optional simple shape descriptor that only separates candidates already close in position. An object that moves far while out of view is recorded as a new provisional object, and the earlier one is marked unconfirmed if its position lies in a declared coverage box. Objects that are turned while out of view are not told apart by shape.
  • Validate on your own sensor and scene. Results depend on the sensor, the segmentation and the scene. Check the service on recordings from your own setup before you rely on it, particularly for cluttered scenes, objects that touch each other and objects handled by people.
  • Segmentation. Automatic segmentation groups points into connected 2.5 centimetre voxels by default, so objects that touch or stand closer than about one voxel become one segment, and one object seen in separated parts becomes several. Callers with their own segmentation can send segments instead.
  • How the memory is updated. By default the memory changes only on repeated evidence: a new object is provisional until it is seen consistently, a single contradicting observation is kept as an alternative, a move is accepted after it persists, and an object that keeps being missing inside a declared coverage box becomes unconfirmed. The consolidated position of an object in continuous motion therefore lags behind it; for such objects select the last-observation rule through the policy endpoint. Thresholds are set per space.
  • No object recognition. The service does not name, classify or recognise objects. A label is whatever the caller confirms for an instance.
  • No robot or device control. The service stores records and answers questions about them. It does not control robots or other devices, and its answers are not rated for safety-relevant decisions.
  • Memory is explicit records, not training. Each space holds explicit records: positions, descriptor values, labels and their history. Nothing is trained on customer data, and records of one account are never used for another.
  • What a find answer means. A find answer gives the consolidated position and the time the object was last seen; it does not prove that the object is still there. When the evidence does not support a position, the answer is not_seen, ambiguous or unconfirmed instead of a guess. Labels are matched exactly.
  • Missing objects are detected only inside a declared coverage box. Only when an observation declares a coverage box does the service count a miss for objects inside it that were not seen; without a box no object is ever marked missing. A box larger than the real view will wrongly mark hidden objects as unconfirmed.
  • Coordinates and time. Coordinates are metres in the space's own frame. A sensor pose sent with an observation is applied as given; the service does not estimate sensor poses or align clouds. Observations must arrive in time order within a space.
  • Size limits. An observation may hold up to 200,000 points, or fewer if the plan sets a lower limit, and the request body may not exceed 10 MB, so large clouds should use the binary format. At most 64 segments are kept per observation and 1,000 instances per space.
  • Typical response times. An observation of a few thousand points is processed in tens of milliseconds and one of 200,000 points in under half a second in binary form. Matching time grows with the number of instances in a space.
  • What the receipts prove. Every observation, update action, label, policy change and forget appends a SHA-256 receipt to the space's chain in the published receipt-chain format. Receipts carry identifiers, counts and hashes of the state, not positions, so forgetting an instance removes its history while the chain stays verifiable. A chain proves order and integrity only when its head is also held by another party. Deleting a space deletes its chain, so export it first if you need it.