Your assistants should already know who you are.

An assistant you allow writes into your profile by itself

Being admitted to read is automatic. Once an assistant has been authorised for your profile's address at our identity service, the first request it makes admits it: the server writes it a permission to read, and nothing else, without asking you. From then on it reads the whole profile at the start of a conversation. There is no per-assistant visibility level — every assistant you connect sees everything in the profile.

Writing is not automatic, and it is not a queue either. The permission to write is added by you, signed in, on your own connection page at https://apc.abt.nz/connect/<your profile id>, which lists the assistants connected to your profile and lets you allow one of them by name. After that, no human is in the loop at any point. When that assistant decides something about you is worth remembering, the statement is written into your profile immediately and every other assistant can read it at once. There is nothing to approve, nothing waiting anywhere, and no moment at which you could have said no. What the statement does carry is its author: a fact an assistant wrote is handed to every reader marked with that assistant's name, and a fact that came from you carries no mark at all. That name is the one you typed for it on the connection page — and typing one is optional. Leave the field empty and the assistant keeps the name it already had, which for one that admitted itself is the placeholder self-admitted. Either way the next assistant to read your profile can tell the two apart, and so can you.

That is a supported way to use the service, not a loophole — and it is also the path by which a model's invention, or a sentence planted in text the model happened to read, ends up in your profile and is quoted back to you by a different assistant next week. The terms of service put the responsibility for that on you, and say so at greater length. What bounds the damage is arithmetic rather than judgement: one assistant may write at most 50 statements a day, it can never occupy the last tenth of the profile's ceiling, and the constraints section — the one that says what an assistant must not do — is closed to assistants for writing: only you put anything there, and no assistant can add to it, replace what is in it, or undo it. Reading it is another matter — every assistant you connect reads that section like the other eight, which is the point of having it. Everything else is bounded by the record described below.

Two journals, and one permission that opens both

The server records every read: which connected assistant, which tool it used, which sections it looked at, how many statements it received, and when. It records every write in a separate journal: which statement, which section, which assistant, when, the reason that assistant gave, what the write replaced, and whether it has since been undone. The read journal goes back 90 days; older entries are deleted. The write journal is trimmed by the same 90 days with one condition attached: an entry goes only once it can no longer be acted on — undone already, or past the 30-day undo window — so a handle the undo still offers is never taken out from under it. With today's two numbers that comes to the same 90 days, the undo window being the shorter of them.

Reading either one needs a third permission, profile:approve — your own oversight, delegated to an assistant. It is never granted by default, deliberately left out of the “grant everything” switch, and never handed out by an assistant simply connecting. Today the only way to obtain the first one is a one-time pairing code minted at the console of our server with an explicit flag, which in practice means asking apc@abt.nz. An assistant that already holds it can mint codes for further assistants, but those codes carry reading and writing only — never this.

Until you have it, you may not know what has been recorded about you. The one signal that reaches an ordinary assistant of yours is a counter in the profile's manifest: how many writes have happened since you last looked at the journal. That counter is the only notification this service has, by design — there is no email, no messenger, no webhook, and there will not be one.

One honest limit on the write journal: it does not reprint the text of a statement that is no longer readable — one a later write replaced, an undo retired, or an expiry passed. It names which of those happened, and every other column stands. The full text is in an export, which is a command on the server.

A write can be undone for 30 days. A statement is replaced, never erased

Undoing a write retires the statement it added and restores whatever that write had pushed aside — the profile goes back to what it was. It needs the same profile:approve permission, and it works for 30 days after the write. Two gestures exist: undo this one write, and undo everything one assistant wrote since a given moment. Past 30 days, or for a statement you added yourself, the answer is to write to apc@abt.nz.

The undo is bounded on purpose: an assistant may only undo writes that assistants made. Your own statements, and anything in the constraints section, are refused — otherwise the permission that exists to hold assistants answerable would be the tool for erasing what you said about them.

There is no route that deletes one statement outright. You correct something by writing a new statement that supersedes the old one; from then on assistants only ever see the new one, and an assistant may supersede only statements assistants wrote. The superseded text stays in the database for 90 days before a cleanup job removes it — with two exceptions: it is kept for as long as an undo might still need it, and in every section the highest-numbered statement is never deleted, superseded or not, because statement numbers are never reused.

And whatever already read the old statement keeps its copy: we cannot reach into an assistant's history and take a sentence back. An undo restores your profile, not somebody else's memory of it.

Exporting your whole profile, or deleting it outright, is possible today only as a command the operator runs on the server. Write to apc@abt.nz and it will be done. We would rather say this plainly than imply a self-service button that does not exist yet.

What is deleted on a timer, and what is not

A profile that has an owner is never deleted for inactivity. There is no channel through which we could warn you first — see the counter above, it is the only one we have — and deleting your data silently is not something we are willing to do. Your profile goes when you ask us to delete it. What the timers do reach is narrower: an unclaimed draft nobody has taken ownership of is deleted 7 days after it was created; an assistant's access that has gone unused for 180 days is revoked and has to be granted again; and both journals are trimmed to 90 days.

Statements in the current section expire on their own — that is the point of the section. If an assistant names a date, it has to fall between one day and one year out; if it names none, the statement stops being handed to assistants 90 days later, quietly and with no warning. (The row stays in the database until the profile is deleted; nothing serves it any more.) What deletion does not currently reach is described honestly in the privacy policy — please read it before you decide this service is right for you.

The server is deliberately dumb

It never calls a language model — not to summarise your statements, not to de-duplicate them, not to check how they are worded. It never sends email, never posts to a messenger, never calls a webhook. Your statements are stored as written and handed over as written.

It makes outbound requests in exactly two places, and neither is on an assistant's path: at startup it fetches the signing keys of the sign-in service, and each time you sign in through a browser it exchanges your sign-in code with that same service. While an assistant is reading or writing your profile, the number of calls this server makes to anywhere is zero.

That is a claim about this server, not about every page in the deployment. The sign-in pages belong to the identity service, and they pull their front-end assets from cdn.casbin.org; your profile picture is kept as a link to Google and fetched from Google by whatever displays it. Both are third parties your browser talks to, both are listed in the privacy policy, and neither is something we have overridden yet. The page you are reading right now loads nothing from anywhere.

One profile, one owner

There is no sharing, no team access, no roles, no read-only links. If two people need profiles, that is two profiles. One account may own up to three of them, and each is a separate address with its own connected assistants.