Ward A, ward B

One store, many wards

Put one robot fleet across a hospital and you get one store. A porter robot writes what it saw on ward A. A cleaning robot on ward B reads the same store an hour later. That is Crew's proposition: every robot on a site, one governed memory. It is also the question. What crosses between wards, and what happens when somebody exercises a right of erasure against a store every machine in the building reads and writes?

Crew is in development and is not running on any site. Nothing here was measured on a machine, and no Tidewell memory holds anybody's data, because none does.

The question has a published answer. EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, version 2.0, adopted 20 October 2020, works through a hospital information system: access by default only to the treating speciality department, widened when other departments or diagnostic units join the treatment, narrowed again after discharge and billing. Three access states over the life of one record, drawn by the European regulator in a document with no robot in it.

A fleet memory as normally built has one [inference]. An episode written on ward A is exactly as readable a year later as it was the day it was written.

So scoping a shared robot memory is neither an ethics position nor a vendor preference. It is the regulator's own worked minimisation design, reaching a reader it did not have in mind. The much-cited EDPB document on AI and personal data is the wrong text for nearly all of it, right up to one seam.

The anonymity question never arrives

A reader coming from the AI literature starts by asking whether the memory is anonymous. For a retrieval store that question does not arise, and an argument built to answer it is a month of the wrong reading. Regulation (EU) 2016/679, Official Journal L 119, 4 May 2016, Article 4(1):

"'personal data' means any information relating to an identified or identifiable natural person ('data subject'); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;"

A site memory is records with provenance, read back as records. Where a record relates to an identifiable person it is personal data on the definition alone, with nothing to assess. Article 4(2) closes the other half: processing includes "storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available". A robot on ward B reading a ward A episode is a processing operation on the face of the text. That is the whole analysis, and none of it asks about models.

What governs, and in what order

Article 25(2), whole:

"The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons."

The third sentence is the one a vendor wants to lean on, and it will not hold the weight alone. The EDPB's own gloss on that limb, at paragraph 57 of Guidelines 4/2019, points it elsewhere:

"Making personal data available to an indefinite number of persons may result in even further dissemination of the data than initially intended. This is particularly relevant in the context of the Internet and search engines. This means that controllers should by default give data subjects an opportunity to intervene before personal data is made available on the open Internet. This is particularly important when it comes to children and vulnerable groups."

Publication, and the open internet. A data-protection officer knows that, and will say so to anyone who reads "an indefinite number of natural persons" as a rule about many internal readers of one internal system. The accessibility sentence is the statutory floor. It is not the argument.

The argument is paragraph 55, and its two halves travel together:

"The controller should limit who has access and which types of access to personal data based on an assessment of necessity, and also make sure that personal data is in fact accessible to those who need it when necessary, for example in critical situations. Access controls should be observed for the whole data flow during the processing."

The second half is the clinician's objection to ward-scoped memory, made by the regulator first. A memory scoped so hard that a robot responding to a deterioration on ward B cannot read a hazard written on ward A misses what paragraph 55 asks for as squarely as an unscoped store does. What a designer owes is the assessment, both ways, not the tightest partition available.

Then the worked example, §3.5 Data Minimisation, Example 4:

"A hospital is collecting data about its patients in a hospital information system (electronic health record). Hospital staff needs to access patient files to inform their decisions regarding care for and treatment of the patients, and for the documentation of all diagnostic, care and treatment actions taken. By default, access is granted to only those members of the medical staff who are assigned to the treatment of the respective patient in the speciality department she or he is assigned to. The group of people with access to a patient's file is enlarged if other departments or diagnostic units are involved in the treatment. After the patient is discharged, and billing is completed, access is reduced to a small group of employees per speciality department who answer requests for medical information or a consultation made or asked for by other medical service providers upon authorization by the respective patient."

Be exact about what that is. It sits under data minimisation, not under §2.2.2.4's accessibility limb. It is about hospital staff at terminals, not robots. It is a guideline, not law. And it is nonetheless the ward A / ward B design, published in October 2020, with the third state that nobody builds.

The regulator's example — one patient record over its life

1. By defaultonly the medical staff assigned to the treatment of that patient, in the speciality department she or he is assigned to
2. Widenedthe group with access is enlarged if other departments or diagnostic units are involved in the treatment
3. Narrowed againafter discharge and billing, a small group per speciality department who answer requests for medical information, on the patient's authorisation

The arrows are the transitions the example names, not a timeline we have drawn.

Two transitions: other departments joining the treatment, and discharge. The second is the one nobody designs for.

A fleet memory as normally built — the same record

Written on ward A, readable on ward Bexactly as readable a year later as on the day it was written

One state, from the day it is written. Nothing in the design causes a transition, so there is no second box to draw. [inference]

• A design published by somebody else: the regulator’s example above, the ordinary build below.
• One access state of one record.

§3.8's example is closer to the physical shape of the problem: a controller extracting patient-record data "has assessed the risk for routing the extracts to a server that is accessible to all of the company's employees as likely to be high for data subjects' rights and freedoms". A server every employee can read is the nearest published regulator analogue to a store every robot can read [inference]. The quotation and the risk characterisation are the EDPB's; the analogy is ours.

Article 5(1)(b) requires data "collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes…"; Article 5(1)(e) that it be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed…". Each continues into an archiving-and-research carve-out omitted here, so neither is quoted complete. One says what a ward's records were collected for; the other, how long that answer stays true.

Then the counterweight, which cuts towards the vendor. Article 11(2):

"Where, in cases referred to in paragraph 1 of this Article, the controller is able to demonstrate that it is not in a position to identify the data subject, the controller shall inform the data subject accordingly, if possible. In such cases, Articles 15 to 20 shall not apply except where the data subject, for the purpose of exercising his or her rights under those articles, provides additional information enabling his or her identification."

Articles 15 to 20 include Article 17. A controller that genuinely cannot identify the data subject is relieved of the erasure obligation itself, not merely of the mechanics, unless the data subject supplies the identifying information. For a store whose records read "the trolley in bay 3 was moved at 14:20", that is the operative provision. It is also why the strongest move available to a fleet memory is not an access-control design at all. It is not collecting the identifier. Our own Data page stands there already: "Faces and patient identifiers are never collected."

The one seam where the model question arrives

The path a correction takes is published on the same page: written to the robot's episodic buffer as it happens; uploaded append-only on reconnect, the site server assigning the global order; consolidated there into episodes carrying provenance, contradictions surfaced rather than overwritten in silence. Then: "Nightly fine-tunes run against the skill library; larger training runs will go to our own GPUs in Singapore, which we do not own yet."

That sentence is where a site's own corrections meet model weights most explicitly, and it is not the only place we publish the crossing: the Brain page says "Corrections captured on site feed the next training run", and that our budget goes to post-training on data from our customers' sites [inference]. The seam is narrow wherever it is drawn, and everything changes across it. On the near side a person-linked fact is a record with provenance: findable, scopable, deletable. Article 17(1)(a) — "the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed" — lands on something you can point at. On the far side it is a parameter.

One door a reader will reach for is the wrong one. Article 17(2), on telling other controllers to erase links and copies, is triggered only where the controller "has made the personal data public". A hospital's internal robot memory is not public; the resemblance is a resemblance of shape. Article 17(3) cuts the other way: erasure carries carve-outs, public health and archiving among them, and a hospital reader knows it.

Here, and only here, the document everyone reaches for first becomes the governing one. Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models was adopted on 17 December 2024 per the instrument's own cover; the EDPB's document register carries 18 December 2024, the listing date. It was issued on the Irish supervisory authority's Article 64(2) request. Its §31:

"The EDPB considers that, even when an AI model has not been intentionally designed to produce information relating to an identified or identifiable natural person from the training data, information from the training dataset, including personal data, may still remain 'absorbed' in the parameters of the model, namely represented through mathematical objects. […] Whenever information relating to identified or identifiable individuals whose personal data was used to train the model may be obtained from an AI model with means reasonably likely to be used, it may be concluded that such a model is not anonymous."

§34 draws the conclusion, and the wording matters. §34: "the EDPB considers that AI models trained on personal data cannot, in all cases, be considered anonymous. Instead, the determination of whether an AI model is anonymous should be assessed, based on specific criteria, on a case-by-case basis." The executive summary of the same document says "trained with". Cite §34, and cite "on". §43 sets the test: both "the likelihood of direct (including probabilistic) extraction" and "the likelihood of obtaining, intentionally or not, such personal data from queries" must be insignificant for any data subject.

That is why the opinion has not appeared until now. It answers whether a trained model is anonymous, and a retrieval store never reaches that question: its contents are personal data under Article 4(1) on the definition alone. Before the fine-tune, erasure has a target. After it, erasure meets a document that says anonymity is decided case by case.

We do not publish that a person-linked fact is ever promoted across that line, and this article does not claim one is. The skill library is a skill library. So the claim here is conditional: if a correction carrying a person-linked fact were promoted into a fine-tune, that is where the law changes, and the design answer is to make sure one never is [inference].

Before either path — Article 11(2), where the arrow never starts

The identifier is not collectedOur Data page already stands here: faces and patient identifiers are never collected.

Where the controller can demonstrate it is not in a position to identify the data subject, Articles 15 to 20 do not apply, unless the data subject provides additional information enabling identification. That relieves the erasure obligation itself, not merely its mechanics.

Into the site memory

• Episodic bufferwritten on the robot as it happens
• Append-only uploadon reconnect; the site server assigns the global order
• Consolidated episodecarrying provenance, with contradictions surfaced rather than overwritten in silence
• An erasure request terminates hereArticle 17(1)(a) lands on a record you can find, scope and delete: the personal data are no longer necessary in relation to the purposes for which they were collected. Article 17(2) is the wrong door — it is triggered only where the controller has made the personal data public, and an internal hospital memory is not public.

The seam, and it is a sentence wide wherever we draw it

Into model weights

• Nightly fine-tune against the skill libraryour Data page's own words; our Brain page publishes the same crossing as corrections captured on site feeding the next training run
• The fact is now a parameterOpinion 28/2024 §31: information from the training dataset, including personal data, may still remain absorbed in the parameters of the model, namely represented through mathematical objects.
• The same request does not terminate§34: models trained on personal data cannot, in all cases, be considered anonymous; anonymity is assessed case by case. §43 sets the test — both direct extraction and extraction from queries must be insignificant for any data subject.

Conditional. We do not publish that a person-linked fact is ever promoted into a fine-tune, and this article does not claim one is — the skill library is a skill library. The design answer is that one never is. [inference]

• Our published design — the path a correction takes, as our Data page states it.
• What the law does when the fact arrives there. Quoted, not paraphrased.
• A boundary that is a condition, not a component: one that stops the path starting, one the path may never cross.

Singapore, and what nobody has published

A Singapore reader gets a different answer, and the useful part is what the statute does not contain.

The Personal Data Protection Act 2012 (2020 Revised Edition), informal consolidation in force from 5 December 2025, retrieved from Singapore Statutes Online on 11 September 2026 and re-pulled on 12 September, has no analogue to GDPR Article 25(2) [primary]. No accessibility-by-default sentence, no data-protection-by-default provision in the Act as read. Section 24 states a different duty: an organisation "must protect personal data in its possession or under its control by making reasonable security arrangements to prevent — (a) unauthorised access, collection, use, disclosure, copying, modification or disposal, or similar risks". Reasonable security, owed by the organisation. Article 25(2) is minimisation by default, owed by the designer. A fleet memory engages both, and only one of them tells you anything about how to build it.

Section 25 reaches Article 5(1)(e)'s destination by another route, with no stated period. An organisation "must cease to retain its documents containing personal data, or remove the means by which the personal data can be associated with particular individuals, as soon as it is reasonable to assume that — (a) the purpose for which that personal data was collected is no longer being served by retention of the personal data; and (b) retention is no longer necessary for legal or business purposes." The alternative to deletion in that sentence is the move a memory of operational facts should make. A record that a bay was cleaned at a time stays useful for years. The association with an individual does not.

Nothing above says the PDPA requires a memory to be scoped. It does not. The two sections quoted here were pulled from the Law Revision Commission's own PDF twice, by two people a day apart, and checked against each other; the absence of any by-default or by-design provision is a search of the whole Act, not an impression of it: "by default", "by design", "indefinite number" and "minimis*" each return zero. Anyone relying on either should still re-pull it, and the route costs one command.

We looked for a regulator's published treatment of a persistent memory shared across a fleet of robots and did not find one. On 11 September 2026 we read the EDPB's Article 25 guidelines and its AI opinion in full, and searched the PDPC's and the ICO's published guidance for robotics instruments; the EDPB's own site search would not accept our query, so we report no count from it. We did not search any other supervisory authority, any non-English guidance, or any enforcement decision. That is what we could not find. It is not a proof that nothing exists.

The research literature is thinner than its citation counts suggest. MemClaw (Governed Shared Memory for Multi-Agent LLM Systems, arXiv 2606.24535, 23 June 2026) defines four systems-level primitives, in its own words "scoped retrieval, temporal supersession, provenance tracking, and policy-governed memory propagation", and describes itself as "a production multi-tenant memory service" — software agents, no embodiment in it [carried from shared-memory-failure-modes]. Read from that abstract, supersession is about which of two writes is current and propagation about where a write travels; neither narrows who may read a record after an event like discharge, so the transition Example 4 turns on is not among them [inference]. A Semantic Autonomy Framework for VLM-Integrated Indoor Mobile Robots (its abstract calls the system the "Semantic Autonomy Stack", arXiv 2605.02525, 4 May 2026) organises memory under a three-part scope taxonomy across two custom-built differential-drive robots; every experiment ran in a single indoor corridor on one floor of one building, which is the bound the paper sets itself [carried]. Neither is evidence about a hospital fleet.

Which leaves our own pages, where the gap is specific. Crew technology calls the failure modes of a memory many writers share specific and known, and names leakage across scopes first among them — an argument we publish separately. The one scope statement we publish is the verifier's fifth check: "and scope, meaning whether this robot is permitted this task and this tool call." That is an authorisation on what a robot may do. On what a robot may read we publish nothing: "scope" appears twice on the Brain platform page (one of the two being IEC 63327's own scope of application, which has nothing to do with memory), twice on the Crew platform page and not once on the Data page [inference], re-checked 12 September 2026. The EDPB's example is about reads.

So the question to put to every vendor selling a fleet memory, ourselves included, is not whether the memory is scoped. It is how many access states a record has over its life, and what causes each transition. The regulator's example has three. If the answer is one, the follow-up is what changes at discharge. A vendor who has not thought about that has not read the 2020 example with their product's problem already drawn in it. We do not publish an answer today. When we do, it goes on the product page, not in an article.