Privacy: what Junior holds, and how to erase it

The short version

• Documents you submit for analysis are sent to Anthropic (commercial API) to be processed, using the model claude-sonnet-5. They are not used to train models.
• Junior does not write your document to disk when you simply read a review. Filing a review to a matter does store parts of it — the passages the analysis quoted, verbatim, and the clause text behind each deadline. The badge on every review says which of the two just happened.
• You can delete a matter, and everything filed against it, from inside Junior. That was not true before 7 August 2026.
• Plenty is kept even when you do. Some of it is a financial record or a professional declaration; some of it is a platform log with no delete control in Junior at all. Every one is named below with the reason.
• Junior does not sell anything about you, and there is no advertising network on any page of it. Two stores are copied to other Manera services, and that is described below rather than left out.

Every store on this deployment

This list is not typed by hand. Junior parses its own source for every SQLite database any part of it can open, and every one found has to be classified below before this page will render at all — there is no way for a store to be simply absent. There are 44 of them: 6 are deleted when you delete a matter, 32 are kept and each one says why, and 6 hold nothing about a person and say what they hold instead. Several of the kept ones have no delete control inside Junior at all, and those rows say so in the same words.

“Document content” is the column that matters most: nearly all of these hold no part of your client's papers, and the ones that can are named. “Class” is the promise: what happens to this store when you use the delete control.

What you can erase

Signed in, at your data, you can see what is held about you and delete any matter. Deleting a matter removes, in the same action:

• Matters, filed reviews and the deadline register — Delete the matter — from its page, or from this one.
• Reviewer invitations and the access audit — As the person who INVITED: withdraw an invitation at any time from the matter page, and deleting the matter deletes the invitations AND their audit trail with it. As the person who was invited: these rows belong to the lawyer whose matter it is, and you cannot delete them here.
• Watched citations and their alerts — Stop watching an authority from the Watch page. Deleting a matter deletes everything watched for it.
• Time entries — Deleting a matter deletes the time entries filed against it, including ones you have discarded from your timesheet. Export first if you need them. An entry attached to NO matter has no delete control today — those are the ones logged before you filed the work anywhere.
• Precedent bank — Delete any precedent from the Precedents page.
• Personal playbooks — Delete any playbook, or any step, from its page.

The rows are deleted, not flagged. There is no hidden “deleted” column anywhere in these stores. Each delete counts the rows again after removing them and fails loudly rather than reporting a deletion that did not happen — and if any store cannot be reached at all, the erasure refuses and deletes nothing, rather than deleting the matter and stranding the rows that pointed at it.

What is kept even when you delete a matter

Named, with the reason. This list is generated from the same classification as the table above, so a store cannot be kept without appearing here.

• Follow-up threads on a paid case case_threads.db — Your email, what the case was for, a label for the document, how many follow-ups you have used, and a SHA-256 fingerprint of the document text. The text itself is never written here.
  Kept. A thread is the receipt for follow-up questions you have already paid for; deleting it would revoke what you bought. It holds a hash, not your document.
• Payments and checkouts payments.db — What you were asked to pay and what was confirmed: amount, currency, product, our reference and the provider's, and whether it has been spent. No card details reach Junior.
  Kept. This is the financial record of a sale — the evidence behind an invoice, a refund and a tax return — and it is also the only proof of what you are entitled to.
• Usage and the free first case plans.db — One row per case you ran, whether it was billed, and the amount; plus a single row recording that you have claimed the free first case.
  Kept. The charges are a financial record. The free-case claim is deliberately not erasable: deleting it would hand back a free case every time, which turns the erasure control into a way of taking the product for nothing.
• Practitioner attestation practitioner_attestation.db — Each time you declared that you are a qualified practitioner: the role, bar or order, licence number and jurisdiction you gave, the exact wording you agreed to, and the IP address and browser that sent it.
  Kept, and append-only. It is a professional declaration about who you said you were when the product was unlocked. There is NO control inside Junior to withdraw it today: the function exists in the store and no page calls it, so a withdrawal has to be asked for directly. Withdrawing would in any case append a row rather than delete one — an attestation is evidence of what you declared at the time.
• Daily brief delivery brief_sends.db — One row per day a brief was emailed to you: the date and how many items it carried. Not the contents.
  Kept. It is the record that stops the same brief being sent to you twice in one day.
• Email sign-in codes local_auth.db — A HASH of each sign-in code sent to your address, when it expires and whether it was used, plus one timestamp per failed attempt. The code itself is never stored.
  Kept. It is the rate limit that stops someone else guessing their way into your mailbox-based sign-in.
• Per-call record of every analysis you ran usage_governor.db — One row EVERY TIME Junior sends anything to the model on your behalf: your email, which product, which model, how many tokens went in and out, what it cost, the HTTP status, a fixed label naming which part of the code made the call, and when. Plus one row holding your plan tier and this month's running spend.
  Kept, and this is the one that most deserves an explanation. It is not an analytics table: `usage_log` IS the spend ledger. usage_governor._current_month_spend() sums this month's rows to decide whether your next call is inside your budget, so deleting them would reset your monthly spend to zero and hand back paid budget on demand — the same objection as the free-case claim above. It is also the cost evidence behind what you were charged. What it records is that a call happened, what it cost, and a fixed label for the code that made it — never what you asked or what came back. There is no column for either, and no caller passes any part of your question into the one free-text field there is. Nothing sweeps it on a schedule.
• Prepaid credit, top-ups and auto-recharge usage_meter.db — Credit and token balances held against your address, when they expire, and your auto-recharge settings including the payment-method reference held at the provider.
  Kept. It is a balance you paid for; deleting it would destroy the record of credit you are owed.
  The four counts beside this row are not the whole store: it also keeps a history of every automatic recharge that fired, which is counted at the payment provider rather than here.
• Bug reports and feedback you sent feedback.db — Anything you typed into the feedback widget, the page you were on, your email, your browser string, any JavaScript errors the page had collected, and the path of any screenshot or attachment you sent.
  Kept, and there is no delete control for it inside Junior. A report is the record of a defect and of who can be told it is fixed.
• Platform incident log, one file per service _anomalies.db — On this deployment the file is lexiworld_anomalies.db — the name is built from the service id at runtime, which is why no line of source spells it. One row per fault the platform raised — a failed payment lookup, an unreachable billing gate, a rejected agreement. The `detail` field is free text written by whichever check fired, and several of those checks put the URL they were calling into it, which can contain your email address.
  Kept. It is the operational record of things going wrong, and there is no delete control for it in Junior.
  Nothing in this store is keyed to a person. Your address can appear INSIDE an incident's free text, and there is no query that can find it reliably, so this page will not pretend to have counted.
• Backup copy of the incident log backup_all_mesh_anomalies.db — Whatever the incident log above held when the copy was taken.
  Kept. A copy is exactly the thing a delete control does not reach, which is why it is named here instead.
  A backup file. mesh_alerter names it only to SKIP it, and nothing in Junior reads or writes it.
• Behavioural sensor on the LexiWorld workspace user_sensations.db — Page views, clicks, rage clicks, scroll depth and how long you stayed, recorded against a session identifier and a hash of the signed-in address, with the path of the page. It is first-party — nothing is sent to an analytics company — and it is injected into the /workspace pages, not Junior's.
  Kept. There is no delete control for it inside Junior.
  Rows are keyed by a HASH of the address, not the address, and Junior cannot reverse it to count yours. That is better for you than a lookup table and it is the reason this cell is not a number.
• Terms you accepted or refused agreements.db — Which document you accepted, its exact version and hash, when, from which IP address and browser, your locale and the country the request came from — and the same again for a refusal, with the reason.
  Kept, for the same reason as the practitioner attestation: it is evidence of what you agreed to and when. Deleting it would delete the proof that consent was ever asked for.
• Waiting list for products not yet open waitlist.db — The address you left, which product, when, your IP address, your browser string, the page that referred you and any note.
  Kept. There is no unsubscribe control wired to this store inside Junior; ask and it will be removed by hand.
• Cross-product assistant memory personal_assistants.db — An assistant per product per address, the messages exchanged with it, facts it has recorded ABOUT YOU with a confidence score and which product supplied them, and the briefings it generated.
  Kept. There is no delete control for it inside Junior. This one is worth a second look if you use more than one Manera product: it is the store designed to carry what one of them learned into another.
• Log of mail sent to you mail_log.db — For each message Junior sent: from, to, the subject line, which service sent it, whether it was delivered and the error if it was not. Not the body.
  Kept. It is the record of whether a sign-in code or a brief actually reached you, which is the first thing anyone needs when it did not.
• LexiWorld workspace store (reference law, and more) lexiworld.db — Mostly reference material — jurisdictions, statutes, cases, employment rules. It ALSO carries `contracts`, whose `content_text` column holds a document's FULL TEXT when the workspace half of the site saves one, an `audit_trail` keyed to the acting address, and batch and subscription rows keyed to a customer. Junior's own per-case flow does not write here; the /workspace pages on the same domain do.
  Kept. There is no delete control for it inside Junior.
  `contracts` and `legal_queries` now carry an owner_email, so rows written from 2026-08-10 onward are attributable to the account that made them. Rows written BEFORE that have no owner recorded and cannot be attributed after the fact — they are visible to nobody but the operator, and Junior cannot find them to delete them for you either.
• API keys for the machine-callable products api_keys.db — An address, a LABEL you chose, and the SHA-256 HASH of an API key — never the key itself, which exists in plaintext only once, at the moment it is issued. Also when the key was created, when it was last used, and whether it was revoked.
  Kept, and the honest reason is that a key is a credential, not a record about you: revoking it is the control that matters, and revocation is immediate. Only the hash is stored, so what remains after revocation cannot be used to call anything.
  Junior itself never writes here. If you have never been issued an API key for the NEIP or ProductDNA APIs, there is nothing in this file about you.
• Onboarding progress onboarding.db — Which step of a product's setup you reached, whether you finished or skipped it, and the answers you gave.
  Kept. There is no delete control for it inside Junior.
• Support tickets support_tickets.db — A ticket's subject and body, your address, who it was assigned to, every message on it and its audit trail.
  Kept. A support history is the record of what was asked for and what was promised.
  The count beside this row is tickets only. Their messages and audit rows hang off a ticket rather than off an address, and the mailbox-polling cursor is about the mailbox, not about you.
• Satisfaction survey answers nps_responses.db — Your score, the reason you typed, a follow-up address if you left one, what triggered the survey, and your IP.
  Kept. There is no delete control for it inside Junior.
• Guided-signup sessions concierge.db — A signup session keyed to your address: what was found out about your firm, the answers you gave, the workspace it created, and any colleagues you invited.
  Kept. There is no delete control for it inside Junior.
• Queued automated email email_queue.db — Messages waiting to be sent to you: your address, which template, the values that will be filled into it, and how many attempts have been made.
  Kept. There is no delete control for it inside Junior.
• Queued email for another Manera product manera_trading.db — The same queue shape as above, belonging to a different Manera product. Junior names the file because email_automation reads trial state from it; Junior does not write your rows into it.
  Kept by whichever Manera product owns it, under the retention rules of that product. Junior has no control over this file and does not claim one.
  It is not Junior's store and Junior does not open it on this deployment; a count from here would be a guess.
• Daily model-cost ledger cost_ledger.db — Per-call cost with a `customer` field, used to stop the fleet spending past a daily budget.
  Kept, for the same reason as the spend ledger above: it is the brake, and a brake you can erase is not one.
• Manera billing database, read but not written by Junior billing.db — Your subscription and entitlement records, held by Manera's billing service. Junior READS it to work out which plan you are on and writes nothing to it.
  Kept by the billing service. A subscription record is a financial record.
  It belongs to the billing service, not to Junior, and is not part of this deployment's data directory.
• Inter-service event bus event_bus.db — Events one Manera service publishes for another, each with a free-text JSON payload. What is in a payload depends on the event, and some of them carry an address.
  Kept. There is no delete control for it inside Junior.
  Nothing is keyed to a person; an address can be inside a payload and no query can find it reliably.
• Signals sent to and from other Manera services mesh_signals.db — What was sent where, and the free-text payload that went with it. Same caveat as the event bus.
  Kept. There is no delete control for it inside Junior.
  Nothing is keyed to a person, and a payload is free text.
• Which alert was already sent to which address intel_alerts.db — A recipient address against the item it was alerted about, so the same alert is not sent twice.
  Kept. Deleting it would start the duplicate alerts again.
• Self-healing event log healing_log.db — Faults the platform noticed and what it did about them, with a free-text `details` field written by whichever check fired.
  Kept. There is no delete control for it inside Junior.
  Nothing is keyed to a person. As with the incident log, an address can appear inside an error string, and this page will not claim to have counted it.
• Self-healing pattern memory healing_memory.db — Error signatures the platform has seen before and the action that fixed them.
  Kept. There is no delete control for it inside Junior.
  A signature is a fingerprint of an error message, not of a person, and nothing here is keyed to one.
• Timestamped copies of a store *.db.bak-* — Whatever the store held at the moment the copy was taken. This deployment has one: a copy of the LexiWorld workspace store.
  Kept until somebody removes it by hand. This is the honest limit of every erasure claim on this page: deleting a row deletes the row, not a copy of the file it was in.
  A copy is not connected to anything. No delete control in Junior reaches one, which is exactly why it is named here.

Stores that hold nothing about a person

Listed anyway, with the justification. A store left off a privacy page because somebody assumed it was harmless is indistinguishable from one left off because nobody looked.

• Revenue/cost circuit-breaker state circuit_breaker_state.db — Whether the fleet's spending brake is tripped, when it tripped and the ratios that tripped it.
  Two tables, and every column is a mode, a timestamp or a money total for the whole business. There is no per-person column and no free-text field a request could reach.
• Disk-space alerter state disk_alerter_state.db — One row per mount point: how full it was, when it last alerted.
  Three columns — a mount name, a level and a timestamp. Nothing about a person can be written into any of them.
• Process-health alerter state pm2_health_state.db — Restart counts per process, and alert fingerprints.
  A process name, restart counters and timestamps. The fingerprint is a hash of an alert about a process.
• Alert de-duplication mesh_alerter_dedupe.db — A fingerprint per alert already emailed, and when.
  One table: a hash and a timestamp. The alert TEXT is not stored here — only a fingerprint of it — so there is nothing to read back.
• Signal state (what the fleet is currently told to do) mesh_signal_state.db — The active operating instruction — pause, throttle — with its reason and expiry.
  A kind, an action, a reason string written by the fleet about itself, and an expiry. Nothing in the write path can put a user's data into it.
• Ingested public news news.db — Public articles: source, title, by-line, summary, full text.
  Published material, fetched from public feeds. The `author` column is a journalist's by-line on an article that was already public — it is not anything about YOU, and no user input reaches this store.

What leaves this container

Two of the stores above are copied to another Manera service by name, by code inside this application. Feedback you send is copied out to Manera's own machine so somebody can read it, and a platform incident — whose text can contain your email address, because some checks put the address or the URL they were calling into it — is broadcast over HTTP to the other Manera services. Neither is a sale and neither goes to an advertiser; both mean a copy exists that no control on this page reaches. Separately, and it is not a property of any one row below, EVERY database in this container is copied off this machine every night — that is the section after this one.

• Bug reports and feedback you sent feedback.db — This database is COPIED OUT of the container. feedback_aggregate.py runs `docker cp` against it to build Manera's internal review queue, so a report you sent also exists on Manera's own machine, and deleting the copy here would not reach that one.
• Platform incident log, one file per service _anomalies.db — Incidents do not stay here. mesh_sentinel.broadcast_anomaly posts the same `detail` text over HTTP to the other Manera services in the mesh — Dr. Manera and Bidit among them — so an incident that named your address has been sent to them as well.

What leaves this machine, every night

Every database in this container is copied off this machine, every night at 03:00 UTC.

Not two of them — all of them, including the matters store with the passages quoted out of your client's document. The whole data volume is archived, encrypted with a passphrase held on the host, and uploaded to Backblaze B2, a third-party storage provider. The archives are kept 14 days on the machine and 30 days at Backblaze B2, then deleted. Which means: a matter you delete today is gone from this application immediately and from every query it answers — and a copy of it goes on existing in those archives for up to 30 days afterwards. Nothing on this page reaches them.

This one is not derived. Every other number on this page is read out of the code that applies it; this backup runs in host cron, outside this container, and Junior can neither see it nor perform it nor delete anything out of it. It is an operational statement about how this deployment is run, checked by hand against the host on 7 August 2026, and the four commands that re-check it are written into privacy.py beside these numbers. If the schedule changes and nobody edits that file, this paragraph goes stale and no test in this product can tell you.

How long things are kept

Every period below is read from the code that applies it. The second column is the one worth reading: nothing in Junior deletes anything on a schedule. Some of these numbers are genuinely enforced — an expired invitation really does stop working — but enforcing a limit and deleting a row are different things, and the column says which one this is.

Copies that have already left

Anything you have already downloaded stays where you put it. The closing memo PDF is generated when you ask for it and is never stored by Junior — but the copy on your computer, and any copy you emailed, is outside Junior's reach and deleting a matter here does not touch it. The same is true of a timesheet you exported to CSV, and of the daily brief that was delivered to your mailbox.

Who else sees a document

• Documents you submit for analysis are sent to Anthropic (commercial API) to be processed, using the model claude-sonnet-5. They are not used to train models.
• Anyone you invite to review a matter — one matter, read-only, bound to the mailbox you named, for a period you set. Every opening is recorded and you can withdraw access at any moment.
• No analytics company, no advertising tag and no third-party script runs on any Junior page. Nothing about you is sold. What does happen is described above and is between Manera's own services: the LexiWorld workspace on this same domain records page views, clicks and dwell time against a session identifier and a hash of your address, and a platform incident whose text contains your address is broadcast to the other Manera services.
• No document text is in either of those. What crosses is your address and what you did, not what your client's contract said.

What this page does not claim

• It does not claim certification under Quebec's Law 25, the GDPR, or any other regime. It describes mechanisms; whether they satisfy a given obligation is a legal question and no lawyer has answered it for Junior.
• It does not promise a retention period Junior has not built. Where nothing expires, the table above says “no time limit”.
• It does not promise to reach copies you have downloaded or forwarded, or the timestamped backup copies of a store listed above.
• It does not reach the nightly off-box archive. Every database here is copied off this machine every night at 03:00 UTC, encrypted, and kept 14 days on the machine and 30 days at Backblaze B2. Deleting a matter removes it from Junior at once; a copy survives in those archives for up to 30 days and no control in this product deletes it. This is operational policy on the host, not something this application enforces or can verify.
• It does not claim that deleting a row scrubs the file it was in. SQLite leaves a freed page in place until it is written over, and Junior does not compact these files after a deletion. The row is gone from every query; the bytes may sit in the file until the space is reused.

This register lists dated obligations Junior found in documents you filed. It is NOT a docketing or limitation-period system, it does not know about documents you have not filed here, and it does not calculate limitation periods. Keep your own docket. Every entry quotes the clause it came from — check the quote.