Terms Version History

The on-device prompt-injection classifier runs by default. Section 5.2's bullet about it is rewritten: the Software carries the classifier as part of the web-content firewall, it is on unless the user turns it off in the Trust Center, and the deterministic chain runs ahead of it in every case. Everything else the bullet stated is unchanged -- the text is scored on the machine, nothing about a page is sent anywhere for that purpose, a page the deterministic chain did not already reject and the classifier scores as hostile is withheld from the model once the shipped model's measured accuracy has cleared the bar the Software sets, and a pass that could not run is recorded as not having run rather than presented as coverage. No clause about storage or transmission changed: the default of a control that transmits nothing is not a change in transmission, so the DPIA records the change in R3's mitigation and in no risk rating. Nothing else in either master changed.

Slack and Discord are removed from the messaging channels the Terms list (Sections 2.3 and 8.1), together with the sentence saying they were unavailable in distributed builds until a vendor-operated relay existed. Neither channel can be connected in a distributed build, so the Terms no longer describe them, and the app no longer offers them there. WhatsApp and Signal are unchanged. Section 3.3(d) now also names the United States law that applies to an IP address: with no general federal privacy law, the CCPA/CPRA in California and the other state consumer privacy laws treat an IP address as personal information when it can reasonably be linked to a particular person or household. Sections 4.1 and 4.2 are rewritten to describe the autonomy levels exactly as the Software applies them, after an audit of each promise against the code. Level 0 never carries out an action, whatever the user approves. Level 2 asks for each action, as Level 1 does. Level 3 acts alone only on a proven local record with the same model, from runs that passed the Software's quality check, with a threshold of at least 80% that the user can raise but not lower; an action taken from untrusted or external input (a transaction extracted from an email or an image, an agent-to-agent reply or commitment, a request from a paired MCP client) always asks at Level 3, and a document edit counts as applied only once it has changed the document. The configured level now applies to the sensitive areas too (financial operations, files, email, contacts, documents), and the user can set any area to ask every time; installations that predate this version keep asking in those areas until the user changes it. The confirmation before acting after reading external content becomes a user setting, on by default, that the user can switch off and on (Sections 4.2 and 5.2, and the fourth risk shown at acceptance). Where an approval is needed and no one is present, the action is not executed. Importing data from another installation no longer brings that installation's autonomy levels. The Software no longer suggests raising a level anywhere. Internal rule parameters are removed from the autonomy and prompt-injection sections and from Section 2.3 (the run window, the minimum run count, the edit size limits, the filter techniques and the adjustment list); the guarantees are unchanged. The Portuguese text is also corrected throughout for accents, spelling and grammar, with the same meaning in every clause. No new data is collected or sent.

The local adaptation of the agent's own planning guidance (Section 2.3) is now always on instead of off by default, and the setting that switched it off is gone. Nothing else about it changes: every adjustment is still proposed by fixed rules, shown with the figures behind it, applied only after the user approves it, measured live and withdrawn if it does worse, and the user can still revert any adjustment at any time. Sections 5, 6.1 and 6.9(a) are reworded to match: the adjustment record is kept, and the anonymous outcome counts listed in 6.9(a) ride the ModelIndex report, without the conditions that described the switch. What leaves the machine is unchanged: the same catalog values and counts, with no text and no identifier. Section 2.3 also lists four on-device capabilities it had not named, none of which sends anything to the Company: the mlx-vlm image engines on Apple Silicon; 3D model reconstruction, whose output carries the marker of Section 8.3; body pose estimation on an image the user chooses, which identifies no one and infers no emotion or personal characteristic; and audio clips heard by the on-device model, of which only the name and duration are kept.

The Terms now say who the Company is and what each side owns. Section 2 identifies the Company that develops and distributes the Software under the RunMyAI brand: Ritual do Cálculo, Unipessoal Lda, a Portuguese private limited company, NIPC 518859002, with its registered office in Leiria, Portugal. New Section 10.14 states the intellectual property terms: the Software is owned by the Company and licensed, not sold, under a personal, non-exclusive, non-transferable and revocable license for the user's own devices and purposes, with the usual restrictions on copying, redistribution and reverse engineering, and without limiting any right the law does not let a contract exclude (decompilation for interoperability included); third-party components keep their own licenses, and nothing in the Terms restricts a right those licenses grant, including access to source code; "RunMyAI" and its product names are the Company's trademarks, and third-party names appear only to identify their owners; the user keeps every right in what the user puts into the Software; and, as between the user and the Company, the user owns what the Software generates, with the Company assigning any right it may hold and claiming none -- without a warranty that generated content is protectable, original or free of third-party rights, and subject to any condition a model's own license places on its output. Section 10.6 now names Section 10.14 among the provisions that survive termination. Nothing about what the Software stores or sends changed.

A capability disclosure, not a change in what leaves the machine. The Software carries an on-device prompt-injection classifier that the user can switch on in the Trust Center; it is off by default. It scores third-party content on the machine, and nothing about a page is sent anywhere for that purpose. When it is on and the model shipped with the Software has met the accuracy bar the Software sets for it, a page the deterministic chain did not already reject and the classifier scores as hostile is withheld from the model instead of passed on, and the verdict that travels with the content says which layer withheld it. Where the pass could not run, the Software records that rather than treating the page as cleared by it. Section 5.2 states the control, as it states the rest of the prompt-injection defense.

A precision version: the Terms now describe exactly what the Software stores and sends. Nothing new is sent to the Company, and every transmission to a third party named here for the first time is one the Software already made. Section 6.1 is rewritten to say where each kind of data lives. The database remains the primary store, encrypted, and MyAI training pairs are no longer kept as files: they are derived from the database for each training run, written to disk only while the run lasts, in a folder only the user's account can read, and deleted when it ends. Three kinds of files outside the database are encrypted: call and meeting recordings, mail attachments, and the temporary copy Smart Reset makes while it runs. The clause now lists what is stored unencrypted and why: images, generated media, documents and the profile picture, which the Software opens by path; the WhatsApp and Signal session state, which those components read from disk; the MyAI adapters and fused models; the logs (up to about 128 MB, which can contain email addresses, excerpts of chats and searches, prompts and file paths); the local backups; working and temporary files; and the database key file. It states that, when the user runs MyAI from a separate volume, the user's content is kept on that volume and earlier copies on the computer are moved there, and what stays on the computer. It also names the `.kv-cache` store: when a local model runs through the llama.cpp runtime, the Software keeps next to the model file a snapshot of the model's pre-computed state for the fixed instruction text it places ahead of every request. A snapshot holds only that instruction text, which ships with the Software and is the same for every user, a fixed placeholder message and, for some models, the current date; never a conversation, a request or the user's profile. It is unencrypted for that reason and authenticated with a key derived from the database key; snapshots that fail that check, were written under an earlier format, or belong to a model that is gone are deleted, and Delete All Data and Smart Reset empty these folders without touching the model files. Section 6.4 states what each reset reaches: Delete All Data deletes every store of Section 6.1 that holds the user's data; Smart Reset does the same but keeps the local backups, and keeps the logs and the profile picture when the user keeps their group; and no reset deletes the password-protected exports, the key file, the record of acceptance, the licence and preferences, model files and model backups, the operator's support-desk store, or files the user saved elsewhere. Section 6.7(b) states that the import safety copy is deleted at the first start after its 24 hours. Section 6.2(c) now names the connections to the user's own mail provider (IMAP, SMTP, JMAP and its push channel, CalDAV and CardDAV, and a self-hosted server's account interface), the deliverability test messages and the TLS check of the user's mail host, the DNS lookup that authenticates another person's agent, and the one-click unsubscribe: only when the user chooses Unsubscribe on a message that offers it, one HTTPS request to the address the sender wrote, carrying no content or credentials, which shows the sender's server the user's IP address and that the mailbox is active. Section 6.2(f) states when the Software checks the connection in the background: only on a network change, when a fresh reading is needed, on retries after a failure, every 15 minutes while the Software is in the foreground, and once after launch, one request per check to Cloudflare or a Hetzner server, and none while the computer has no network. Section 6.2(g) states that checking whether the user's domain can deliver to particular addresses queries Cloudflare's public resolver for those addresses' domains. Section 6.6(a) names one more field of the optional adjustment digest a bug report can carry -- whether the Software could read its record of adjustments when it built the report -- and states that the model fingerprint in that digest is derived from the model file's name and size, not from its folder. Section 6.9(a) states that no adjustment outcome is sent to the ModelIndex while the local adaptation of planning guidance is off, that turning it off discards every outcome still waiting to be sent, and that the community aggregates sent back name the version of the adaptation rules they were produced under, and are used only when it is the Software's own. Section 6.9(a) also names the single-use anonymous token (`anon_token`) a contribution may carry in place of the former shared software-attestation signature: issued to the user's licence in an earlier cycle through a blind signature (RFC 9474), so the site cannot recognise it when it is spent and it proves only that a licensed installation sent the report, never which one; the site stores a one-way hash of each spent token and a keyed hash of the account identifier in the licence with a counter. Section 6.3(a) gains the request that obtains that token, which carries the license token, the key identifier and one blinded value, at most two tokens per licence in any 20-hour window. Section 6.9(g) states that reading the community ranking back no longer sends the hardware hash, or anything else: every installation makes the same request, receives the whole public board, and picks its own hardware class on the device. Section 4.1 now defines Level 3 by what the Software does: an action runs without asking only when, of the last 20 recorded runs of the same kind of action in the same execution lane with the same model, the share that succeeded (completed and passed the quality check) meets a threshold of 80% that the user can raise but not lower; only runs started on the device that read no untrusted external content count, fewer than 5 runs or an unreadable record means asking, and the agent's own confidence plays no part. For document edits, Level 3 applies only an edit the Software itself rates low-risk from the operation (a formatting change; an insertion of up to 240 characters; a replacement or deletion changing up to 240 characters in total that the Software verifies against the text the agent saw; or one literal cell value of up to 256 characters that is not a formula) to which the agent attached a confidence at or above that threshold, so the agent's confidence can keep an edit pending but never release one; Section 4.2 now states the same rule for actions with external consequences. Sections 2.3 and 8.1 state that Slack and Discord are not available in distributed builds until a vendor-operated relay exists.

Two things ship in this version, both in Section 2.3 and both about what the agent can do rather than about any new data flow to the Company. The first is new. The agent can now adapt its own planning guidance from how its plans fare on the user's machine, and the Terms describe that capability the way it works: it is off until the user turns it on; it is driven by fixed rules over counts of outcomes, never by a model and never by anything the agent reads -- Section 5.2 states that every turn which read a web page, an email, a document, a file, a channel message or any other third-party content, every turn in which the injection filter matched anything, and every turn that did not start on the user's own desktop is excluded from the learning entirely, and that the learning reads counts, not text; it can change the agent only through a closed set of typed adjustments (a preferred execution lane for a class of request, a parallel planning strategy for a class of request, or the removal of a tool from a lane), none of which can add a tool, raise an autonomy level or bypass an approval; every adjustment is shown to the user with the figures behind it and used only after the user approves it; an approved adjustment is measured live against the previous behaviour and withdrawn by the Software if it does worse; and the user can revert any adjustment or turn the capability off, which restores the built-in behaviour at once. Most evaluations end with no change. Section 6.1 names the two stores this adds inside the encrypted local database -- the record of every adjustment proposed, approved, measured, retired or reverted, and the message history of the agent's own sub-agents that a conversation keeps addressable between requests -- both erased with the user's data. Two existing transmissions gain fields, each enumerated one by one. A bug report (Section 6.6(a)) may now carry, at the user's option and only when the capability shaped the failed execution, a digest of the adjustments in force for it: for the planner and for the tool router, the adjustment version, the evaluation group, the request class as two fixed category names, the typed adjustments as catalog names, a hash of the component's built-in instructions and a fingerprint of the model that ran it; whether the request was re-run with every adjustment off; and the version of the adaptation rules. Every field is a catalog name, a whole number or a hash; none can carry text. The anonymous ModelIndex report (Section 6.9(a)) may carry, for each adjustment that reached a final live outcome, the component it applied to, the typed adjustment, the model name and quantization it ran on, the rule version, its outcome as one of three fixed words and the number of evaluation units it was measured over -- counts and catalog values of the same nature as the plan counts the report has carried since v1.5, with no text, no trace identifier and no identifier of the installation; and the reply to that same report may carry back how many installations running that model promoted or retired each adjustment, which the Software uses only to lower the local evidence a proposal needs and to show those counts on the approval card. Section 6.9(c) states why none of this can identify a device: an adjustment is a combination of catalog values every installation of a model can emit alike, and its outcome and unit count move with every further evaluation. The second thing is a correction that had been waiting since v1.18: the video-generation line in Section 2.3 named one of the two engines the Software generates video with and now names both, with the model families each runs. This summary, as first published, left out a third addition made in the same version: Section 6.2 gains subsection (k), the native reminders and tasks bridge. When the user turns the bridge on and acknowledges a notice that names the destination, the Software writes reminders and MyProject tasks into a list the user selects in the operating system's own reminder store and reads back what the user wrote there. The picker shows, for each list, whether it is held on the device only or belongs to an account that syncs to a server; where it syncs, that account's own sync carries the copies to its provider, under that provider's terms. The Software contacts no server of its own on this path, and deselecting a list or turning the bridge off stops the next pass.

Section 6.9 gains subsection (g): the Software now reads the ModelIndex back, not only contributes to it. Section 6.9 has always said the contribution powers hardware-matched recommendations the user receives in return; until this version nothing in the Software received them. At launch, and at most once every 24 hours afterwards, the Software asks the Company's aggregation service for the published ranking of its own hardware class, and shows each of the user's models' community score and rank on that hardware in the model manager. The request carries one value: the hash of the hardware specification that every report already sends. It carries no model list, no measurement, no identity and no content, and the Software matches the answer against the user's models on the device, so which models the user has never leaves it. The answer is public data -- the same ranking anyone can read on the ModelIndex pages -- and is kept locally for 24 hours. In the same version Section 10.4 points at the page that actually holds this history, runmyai.app/legal/terms, instead of the legal index at runmyai.app/legal, and the list of deterministic controls in Section 5.2 gains two entries. Web access cannot reach the user's own network: every address the agent asks the Software to open is validated before a connection is made, and one that points at the user's local network, the machine itself or a cloud metadata service is refused, whether written directly, reached through a redirect or returned by a name lookup that changes its answer, and the same check covers every page the built-in browser loads in the background. Answers are screened before they are shown: a link to a known exfiltration destination and any credential-shaped value in a model's answer are replaced by a redaction marker, and a link to a destination none of the turn's sources mentioned is marked as untrusted. Both are controls on the user's own machine; neither adds a data flow.

Section 6.9(a) splits one number in the ModelIndex report into the two numbers it was always two of. Each measured model reported a single "tokens-per-second"; it now reports the sustained rate the model holds across a whole answer and, separately, the highest rate it reached for a moment. No new category of data, no per-run detail, no identifier, and nothing about the machine that was not already listed — both figures are the same kind of measurement the clause has disclosed since v1.5, and the second one was already being measured on the device and simply had nowhere honest to go. The reason for the split is that the report had been sending the wrong one of the two under the only name available. Only one column in the Software's own records holds a sustained rate, and it is written solely when a user saves a star rating, so for nearly every model the report fell back to the other column: the highest speed seen over any one-and-a-half-second window since the model was first loaded, kept as an all-time maximum that never decays. Those are not the same quantity and they are not close. On one machine the public index listed a model at 82 tokens per second while that model was, in the same session, delivering an answer at 5 — and because the maximum is a ceiling rather than a throughput, the index also ranked a model's larger, slower quantization above its smaller, faster one. A reader choosing a model for their hardware was being answered with a number no run of that model would reproduce. With the split, the sustained rate is measured over generation time alone — the wait for the first token, queue time and any tool the model called are excluded, so it does not shrink merely because a prompt was long — and it is the figure the public index ranks on. The maximum travels beside it under its own name, so it can be read as what it is. A model with no sustained measurement yet now reports none, in the same way a model that has never run a plan reports no accuracy figure, rather than borrowing the maximum standing next to it.

Three corrections, identical in kind: in each, the Terms stated something about the Software that was not so. They ship as one version because none of them had been published on its own, and a reader gains nothing from being asked to accept the same document three times in a day. **The first removes a disclosure of a flow that does not exist.** Two clauses about browser cookies are replaced, because they described a data flow the Software does not have. Section 3.1(d) said the agent and the embedded browser panel share one cookie store, so that logins created while browsing in the panel could be inherited by the agent's later searches; Section 5.3 listed that inheritance as a known risk. Neither happens. Every browsing window the agent opens is created in a private mode that gives it its own isolated storage -- separate from the panel's and, on macOS, separate from every other agent window -- and the panel is created the same way. Nothing the user is logged into in the panel is reachable by the agent, and nothing the agent picks up is reachable by the panel. Nothing persists between runs of the Software. The clauses now say that, and they state the two limits that do exist in place of the one that did not: the erasure of a window's storage is issued as soon as the window is released but may not have finished before that window is used for the next page, and on Windows the agent's own windows share one storage area with each other during a single run, so one site the agent visits may observe storage set by another site the agent visited in the same run. A consequence the user can see is stated for the first time: because the agent arrives at every site carrying no cookies, some sites treat it as a first-time visitor and show verification pages that a regularly used browser would not. In the same pass a defect behind the correction was fixed. The erasure that runs after each page was clearing the browser engine's default storage area, which no agent window is attached to, so it removed nothing the agent had set and consecutive pages fetched through one reused window did carry each other's cookies; it now clears the storage of the window being released. This version narrows what the Terms disclose because the Software does less than the text claimed, not because anything was taken out of the Software. **The second removes a denial of flows that do exist.** Two statements that denied something the Software does are rewritten: the Preamble's "This is not a cloud-hosted AI service" and the first bullet of Section 2.2, headed "A cloud service" and closed with "Everything occurs on your machine". Together they read as a statement that the Software cannot be reached from anywhere but the machine it runs on. It can, and Section 2.3 has listed how since the versions that disclosed each path: a paired messaging channel carries commands to the agent from a phone, the built-in WebChat has an opt-in local-network mode that serves the whole interface to a browser on the user's own network, and Remote Link carries it between the user's own installs across networks. Section 6.2(b) states, correctly, that the message content of a channel transits that platform's own servers. The two headline statements therefore contradicted both the capability list and the data-transmission clause of the same document, and they are what a user reads first at the acceptance gate. Both now state what is actually being denied -- the Company's infrastructure, not remote access: no search, inference or action runs on the Company's servers and the Company operates no relay through which the user's requests or results pass, while the Software may be reached from away from the machine and the work still runs on it, with only the message transport crossing infrastructure outside it -- either a platform the user chose or a server the user operates. The comparisons with cloud-hosted assistants in Sections 3.1(a) and 3.2 are unchanged and remain exact: they are about whose servers perform a search and whose address it carries, which is the user's machine and the user's address however the request arrived. Nothing about the Software changed, no capability was added, and no data flow changed; what changed is that these two statements now make the promise the architecture actually keeps, and neither is falsifiable by a feature the same document discloses two sections later. **The third states the defense that is actually in force.** Section 5.2, on prompt injection, is rewritten end to end. It opened with an unbounded list of harms -- actions not intended, exfiltration to third parties, commands outside the authorized scope -- written as though the agent ran on somebody else's servers, and then named a handful of mitigations, some of which did not hold as stated while most of the ones that did hold went unmentioned. It now has the shape of Section 5.8: the controls first, in plain language, then what remains after them. Third-party content is filtered on the device before the model reads it, with evasion normalization and a phrase catalog covering all ten languages the Software ships in, not the four alongside English that the previous text named. It is marked as data between delimiters drawn fresh for each call, across web pages and search results, email, documents, inbound channel messages, call transcripts, calendar-derived fields, bank-statement transaction descriptions, local files the user named, retrieval hits of unestablished origin, images handed to a vision model and site-map listings -- twelve surfaces that carried no such marking before this version. A structured verdict travels with the content and rejected content is withheld rather than passed on with a warning. How a document arrived decides whether it is trusted, and an unrecorded route counts as third-party. An action with an effect outside the Software, in a turn that read third-party content, requires explicit approval at any configured autonomy level, and is refused rather than left waiting where no person is present to answer. Outbound screening aborts the action instead of redacting it and sending the remainder. Nothing in any of it runs in the cloud. The text still discloses the residual risk, because there is one: detection-based defenses are treated in published research as bypassable by an attacker who adapts to them, so what Section 5.2 now claims is defense in depth, least privilege and human approval for consequential actions, measured per release -- not prevention. In the same pass the defects behind the correction were fixed, which is what lets the text say these things. Content was being shortened to a character budget after its delimiters had been added, so a page that used its full budget always lost the closing delimiter and every byte after it -- the Software's own headings included -- fell inside the untrusted block; a broad search shrinks that budget further and made the loss the normal case rather than the exception. Content is now held as its text with the delimiters drawn at the moment it is rendered, so shortening it shortens the text and encloses it again. Whether a document was trusted was being decided from a file marker that exists only on macOS and is absent more often than it is present, which meant nothing was filtered at all on Windows and Linux and that mail attachments, transcriptions and files the agent itself opened were indexed as though the user had written them; the route each document took is now recorded, an unknown route is untrusted, and the filter runs on every route on every system. And the chat window used to load a remotely hosted image as soon as a model's answer mentioned one, while the answer was still streaming and before the outbound screen had run -- the path by which a hostile page gets data off a machine with nobody clicking anything. It now waits for a click.

One sentence in Section 6.6(a) is made precise. No capability changes, no new collection, and nothing about a bug report's content changes — what changes is that the text now describes the two screens the Software actually runs instead of merging them into one. Before sending a bug report the Software screens every text field for credentials, keys and tokens. It additionally screens every field that can carry free writing — the summary the on-device AI wrote, the description the user typed, and the error and reason text captured from the failed run — for personal identifiers: email addresses, home directory paths, network addresses, phone numbers, long numeric identifiers such as payment card numbers, and grouped identification numbers such as tax or citizen numbers, treating every country the same way. The report's generated identifiers and its fixed-vocabulary fields — the report and request identifiers, the status, the execution lane and action, and the runtime environment — get the credential screen only. That is deliberate and is the reason the sentence had to be split: those are the keys the support desk uses to find the report the user is writing about, the identifier patterns would rewrite exactly those keys, and a generated identifier or a closed vocabulary has no way to contain someone's address or tax number to begin with. The previous wording promised one screen over "every text field", which was a stronger statement than the design makes and a weaker description of it. Found by Privacy & Compliance Audit #007.

Section 6.9(a) adds two numbers to the ModelIndex report, and the Software stops sending a third one it was not entitled to send. Each measured model, and each measured model pair, now reports what share of its finished runs delivered a result (and for a model, how many of its plans finished at all) — two aggregate counters about the Software's own runs on the machine, of exactly the same nature as the plan count and the quality-gate pass rate the clause has listed since v1.5. They carry no content, nothing about what any run was for, and nothing about the machine. The reason for adding them is that the pass rate alone had been misleading, in the app and in the public index alike: a run can finish in a degraded state — the model was never handed the tools it needed, say — while every individual step inside it is marked as passing, so a model that failed every run it attempted was scoring higher than a model that completed every one of them. The pass rate needs the outcome of the runs it scored in order to mean anything. In the same change the report became narrower for lightly used models and pairs: a quality-gate pass rate measured over fewer than three finished plans is no longer transmitted at all, because a single run that happened to pass is not evidence about a model, and in the public index that field carries 40% of the ranking. For such a model the report now says less than it did before this version. Nothing else about what is transmitted changed: no new category of data, no per-run detail, no identifier.

Two precision corrections to the ModelIndex section, both found by Privacy & Compliance Audit #006, and neither adding a capability or a new collection. First, Section 6.9(a) now lists the short accelerator label the report carries alongside the accelerator fields it is composed from — "40-core GPU", "NVIDIA GeForce RTX 4090", "CPU". The label is built on the device from the accelerator values the clause already listed, so nothing new is transmitted and nothing new is learned; what was wrong is that the allow-list is meant to name the report field for field, and this one field was not named. Second, Section 6.9(c) states the anonymity guarantee in the terms the design actually delivers. The previous text said the Company could not link one report to another "even in principle", which was written when the hardware class was three coarse buckets. The report now carries the machine's published product specification, so the sentence is replaced by the specific one: no contribution can be tied to a device or a person, and two reports cannot be attributed to the same machine, because the only thing two reports from one machine share is a product specification and its hash — which every machine built from the same published parts also produces, making two matching reports indistinguishable from two different machines of the same model. That is a statement about what a specification identifies, and it is the property the automatic contribution rests on. In the same pass, and the reason the wording had to be exact: the aggregation service was still storing and indexing the per-installation public key that older builds sent, three months after the desktop stopped sending one and after the June 2026 change that was supposed to end it — the values were kept rather than cleared, and the daily rollup still read them to count contributors. For those legacy reports the "cannot link" sentence was simply untrue. The endpoint no longer accepts either installation field, the stored values are erased and the columns removed, and software attestation is now the only way a report is accepted. One omission from the v1.12 summary is also recorded here rather than left out of the history: in that same version the processor's family field went back to being the vendor word the machine reports ("Intel", "Apple") instead of a class chosen from a hand-maintained table ("Intel Core Ultra"), because the table filed every chip it had not been taught under "Other". Section 6.9(a) has described the field correctly as "its vendor" since v1.12; only this summary did not mention that it had changed, and the change reports less about the machine rather than more.

The ModelIndex report now includes the published core counts of the processor and of the accelerator (Section 6.9(a)), and the processor core count is removed from the never-transmitted list in 6.9(b) where v1.11 had placed it. This closes a gap v1.11 left open rather than widening the disclosure in kind: naming a part without its core count does not identify what ran, because a single marketing name covers parts that are not the same part — an "Apple M4 Max" is sold with a 32-core and a 40-core graphics section, and the index reported both as the same accelerator. A core count is printed on the part's spec sheet, is identical on every unit of it, and cannot narrow to a machine; it is a specification, exactly like the model name v1.11 already disclosed, and the reasoning in 6.9(e) applies to it unchanged. Everything the report must never carry still stands and still excludes every measured value: the measured RAM amount, the measured video-memory amount, the operating-system version, serial numbers, network addresses, and any device identifier. Memory stays bucketed to tiers, the operating system stays a family without its version, and there is still no per-device identifier of any kind, so a contribution cannot be singled out and two contributions cannot be linked — the basis on which the contribution is automatic. No other data flow changes and no new capability. In the same pass, a defect was fixed that had nothing to do with what is collected and everything to do with whether it was attributed: the most-used execution path recorded neither which model ran a step nor a quality-gate verdict, so models used mainly in chat reached the index with no accuracy signal at all.

The ModelIndex report now names the hardware it measured on (Section 6.9(a)). Until now it described the machine as a vendor word — "Apple", "Intel" — plus a RAM tier and a runtime type, which put an entry-level laptop and a top-end workstation in one class and made the public index unable to answer the question it exists for: which model actually runs well on the reader's own machine. The report now carries the processor's published model name and its family class, the accelerator's published model name and the inference runtime type, the video-memory tier, and the operating-system family, alongside the RAM tier and the non-reversible hash, which is now derived from all of those fields. These are published product specifications of manufactured parts, each shared by a very large number of machines; they describe a product, not a person. What the report must never carry is stated for the first time as an explicit list and narrows the disclosure at the same time as widening it: no measured RAM amount, no measured video-memory amount, no processor core count, no operating-system version, no serial number, no network address, no device identifier of any kind. The amounts stay bucketed to tiers and the operating system is disclosed as a family only, precisely so that no combination of transmitted values narrows to one machine — the anonymity premise the automatic contribution rests on is unchanged, and Section 6.9(e) now says why the specification does not disturb it. No other data flow changes, no new capability, and nothing about conversations, prompts, outputs, files or identity: subsection (b)'s existing prohibitions stand. In the same pass the public index started ranking models by model name rather than by the name of the file on the contributor's disk, which is a change to how contributed data is presented, not to what is collected.

Disclosure reconciliation with the shipped implementation, plus two egress removals in the same pass — no new capability and no new collection, and two flows narrow rather than widen. The update check's staged-rollout cohort number is now disclosed (Section 6.3(a)(1)): a random number between 0 and 99, drawn once on the device and stored locally, shared by roughly one install in a hundred, not derived from the hardware and identifying neither the device nor the user; the previous text said the request carried the operating system, architecture and app version and nothing else, which was not the complete list. The bug-report allow-list (Section 6.6(a)) is rewritten to name the transmitted payload exactly: report identification and classification, the runtime environment including the build identifier and the app's interface language, the optional execution-trace digest with its fields enumerated, the failure-recurrence count, the on-device AI abstract summary, and the names of any redaction categories applied; the previously listed error code and stack trace frames are not transmitted and are removed from the text. Internet latency measurement now targets Cloudflare and Hetzner endpoints only, and Section 6.2(f) names Cloudflare's speed-test and network-trace endpoints; the third-party endpoint the code previously also probed was removed from the Software rather than disclosed. The acceptance gate's step-1 risk summary is realigned to quote Section 11.1 verbatim, pinned by a test. In the same pass two unused diagnostic commands able to reach arbitrary URLs were deleted from the Software, and the webview's blanket HTTPS fetch permission was removed, so the declared Rust call sites remain the only egress surface.

Document signing disclosed, and the user's own payment-service account given its own clause. Signing a document or contract is now listed among the Software's capabilities (Section 2.3), and a new Section 6.2(i) states what leaves the machine when the user signs or verifies a signature. Signing with a certificate file or a hardware token held on the machine contacts nobody. Signing with a gov.br advanced signature does: the user signs in at that service, and the signature service operated by the ITI returns the user's own public certificate and produces the signature -- a request that carries the SHA-256 digest of the document and nothing else, so the document itself never leaves the machine, under a single-use, short-lived authorization that is never written to disk. A timestamp authority, where the user configures one, receives the digest of the signature. Checking whether a signing certificate is still valid contacts the revocation endpoints named inside that certificate (OCSP responder or certificate revocation list), addresses chosen by whoever issued the certificate rather than by the user or the Company. New Section 6.2(j) covers the user's own payment-service account (Stripe): requests authenticated by the user's own API key, to verify the connection and to create payment links carrying the amount, currency and reference the user supplies. Neither clause adds a capability or a new collection -- both describe transmissions the shipped product already made and this text did not enumerate, found by Privacy & Compliance Audit #005.

Paired MCP client software disclosed (new Section 6.2(h)). The Software can now serve its built-in tools to the user's own MCP-capable client software over a loopback-only endpoint (`127.0.0.1:57292`), never reachable from the network and running only while a pairing is active. Each pairing is a device with a bearer token (stored hashed) and an access scope defaulting to read-only; it expires after 90 days and is revocable at any time. Every request passes the Terms-acceptance check, the token lookup, a per-device rate limit and the scope; every data-changing action needs desktop approval in every scope; every response passes the outbound secret redaction already applied to messaging channels; every call is audited with the device as origin. The data the client receives is what the user's scope allows, and whatever service backs that client -- including a remote model -- is the user's configuration and responsibility. No Company endpoint is involved and no other data flow changes.

Sign-in activation disclosed (Section 6.3(a)(2)). Activation can now happen by signing in instead of pasting a licence token, and that path reaches the Company's licence endpoint at activation itself: the app asks for a short confirmation code, opens the Company's confirmation page so the customer approves the code where they are already signed in, and then collects the licence token. Those requests carry the confirmation code, a secret generated for and held only by this installation (it never leaves the device and is discarded once the pairing settles), and the same random installation identifier and operating-system family the refresh already carried -- no user content and no usage data. The confirmation page is opened without the code in its address, so the link alone approves nothing. Pasting a token is unchanged and remains local, with the token first transmitted at the first refresh. No other data flow changes, and no new value is collected: the correction is that the previous text said activation contacted no server, which stopped being true when the sign-in path shipped.

Licence seat binding — a new value is transmitted, and it is the first such addition since 1.5. The licence refresh now carries a random installation identifier generated on the device and the operating-system family alongside the token (Section 6.3(a)(2)). The identifier is a random value stored locally, not derived from the hardware: it carries no serial number, network address or any other property of the machine, and a reinstall reads as a new installation. It exists so one licence runs on a limited number of devices and so the user can see and remove their own activated devices from their account. No usage data accompanies it, and no other data flow changes.

Accuracy reconciliation of the disclosure text with the shipped implementation — no change to any capability, and no new data collection; two disclosures narrow rather than widen. Agent-to-agent messages are marked with the machine-readable header only: the message body is a signed, encoded agent envelope with no human-readable prose to carry a body line (Section 4.5; email keeps both mark parts). License activation is local and contacts no server; the token is first transmitted at the first periodic refresh (Section 6.3(a)). Bug reports are stored in the Company instance's dedicated local support-desk store (Section 6.6(d)), and the Portuguese master's bug-report allow-list now lists the failure-recurrence count the English master already carried, so both locales publish the same list (Section 6.6(a)). The ModelIndex allow-list now matches the transmitted report exactly: per-model and per-pair performance measurements, the per-model average of the user's own star ratings, the coarse hardware class as plaintext class fields plus their non-reversible hash, the plan tier, and report bookkeeping (app version, timestamp, schema version); the previously listed "distribution of task domains and execution strategies" is not transmitted and is removed (Section 6.9(a), (d)). New disclosures: mail-account setup auto-discovery lookups — the provider's autoconfig endpoints, the Mozilla-operated Thunderbird ISPDB (mail domain only), and public DNS SRV/MX records with the public-resolver fallback stated (Section 6.2(e)); public unauthenticated reference-data and measurement requests carrying no user identity — currency exchange rates (Frankfurter, CoinGecko) and internet speed/latency measurement (Cloudflare speed test, Hetzner mirrors) (Section 6.2(f)); and user-configured domain DNS management through the user's own Cloudflare account with DNS-over-HTTPS propagation checks (Section 6.2(g)).

Service connections declared (Section 6.3, retitled "Telemetry, Analytics, and Service Connections"): the update check and signed update download (OS, architecture, and app version only), license-token activation and periodic refresh, subscription management, release-notes fetch, and model catalog/downloads are now enumerated as content-free connections to Company-operated infrastructure, with the network-level IP visibility stated plainly. Section 6.8's "only data that ever reaches the Company" parenthesis extended to reference them. No change to the two data flows (bug report, ModelIndex) or to any capability.

Recording responsibility allocation sharpened (Section 5.9(c)): the on-device recording indicator is now described as shown by default and user-disableable in settings after the recording acknowledgment; the acknowledgment notice and the indicator are expressly stated to be awareness aids for the user only — visible solely on the user's own device, not notice to or consent from any participant, not legal advice, and satisfying no notice or consent obligation of the user — with no responsibility transferring to the Company whether the indicator is on or off; informing the other participants is solely and entirely the user's obligation. Liability exclusion added for recording, capture, transcription, AI analysis, or import performed without legally required participant consent or notice, including with the indicator turned off (Section 7.2). Indemnification extended to claims by recorded participants or authorities arising from the user's recording activity (Section 7.5(f)).

Video calls and meeting intelligence disclosed: capabilities now list peer-to-peer and own-server calls, call recording, live transcription, meeting capture from third-party conferencing apps, and recording import/re-transcription (Section 2.3). New Section 5.9 states that recordings contain other participants' voice, image, and speech; that the user is the controller of that data; that obtaining any participant consent required by every participant's jurisdiction is the user's responsibility; and that the Software creates no voiceprints or other biometric identifiers. A one-time in-app acknowledgment is now required before the first recording, capture, or import (Sections 5.9(c), 11.2). Storage disclosure: recordings are stored as individual files outside the database, encrypted at rest with AES-256-GCM under the same master key; transcripts, summaries, and indexes live inside the encrypted database; loss of the key file also renders recordings unreadable, and the password-protected export covers the database but not recording media files (Sections 6.1, 5.7). Call signaling over the user's mail provider and the machine-readable call-capability header on outgoing email disclosed (Section 6.2(d)). Recording a conversation without legally required participant consent added to prohibited uses (Section 8.2).

Capabilities updated to list local video and voice generation alongside image generation (Sections 2.1, 2.3). Cloud-assistant comparisons made vendor-neutral (no third-party brand names). ModelIndex contribution (Section 6.9) re-engineered to be anonymous by construction — the report carries no per-device identifier — so it is now automatic for everyone, with no EU/EEA/UK opt-in carve-out; legal basis is "not personal data" with legitimate interest as the documented fallback (DPIA LIA).

Initial Terms: local-execution and IP disclosure, agent autonomy levels, known risks, data and privacy (local-first; bug reports; ModelIndex contribution — automatic outside the EU/EEA/UK, opt-in inside it), limitation of liability and indemnification, ICC/Switzerland dispute resolution, general provisions, and the 3-step in-app acceptance mechanism. Companion Privacy Policy, Refund Policy, and AI Disclosure published alongside.