What we store, what we reuse, and the line we don’t cross.

Your documents, your holdings, your results.

When you upload investment documents, we store the documents themselves, the holdings and identifiers we extract from them, and the analysis results — the per-commitment findings, the evidence behind them, and the report built from both.

Your own governance acts are stored too, and durably: your mission and IPS text, the commitments your committee has ratified, and any committee adjustment to a drafted finding. Those are your record, kept with attribution and a date — not analysis the product produced, but decisions you made.

Your documents and results never cross to another user on their own.

This is a product invariant, not a policy we could quietly relax: no analysis, no uploaded document, and no personal information reaches another customer as a side effect of how the product works. Nothing you upload is pooled, and no other customer’s analysis can read from yours.

You can deliberately share, and that is the one way anything crosses. An owner may share a completed analysis with a named person by email; that person can then open that analysis’s report. It is your act, on one analysis, to a recipient you name — but it is real, so this page says so rather than claiming an absolute the product does not hold. What that act does, exactly, is described below.

A share is a named person on a list, not a link.

When you share an analysis, we record one row: this analysis, that email address. There is no share link, no token, and no expiry date. Holding the URL is not what opens the analysis — being on that list is, and the list is consulted on every read. If the person you named has not signed up yet, the row waits for them to create an account with that address; until then it grants nothing.

Because it is consulted on every read, removing someone from the list takes effect on their next request. There is no session to wait out and no cached grant to expire.

One thing does outlive removal, and it is worth knowing rather than glossing. When a recipient downloads a report, we hand their browser a direct link to the stored file that is good for five minutes. A link issued in the five minutes before you removed someone will still open the file it points at until that window closes. It cannot be used to reach anything else, and sharing issues no new one once the row is gone.

Everything above describes what SHARING grants and what removing a share takes away. It is not a statement about every route into your analysis. Our administrators can reach it independently of your share list, so removing someone does not close their access, and you as the owner keep yours. Sharing is one door; it is not the only one.

Someone you shared with can read the analysis and its reports. Sharing does not let them download the documents you uploaded: that route checks ownership, and being shared with does not make someone the owner. An administrator is again the exception.

Public market and filing data is reused — your data never is.

Separately from that boundary, this product treats public data differently on purpose. When it calls a public source — SEC EDGAR filings, grounded web research — it persists everything useful the call returns, not just the slice one analysis needed: full holdings, full research responses and their sources, every identifier resolution including a negative one. That record is reused across analyses, for any user, because it describes the public market rather than any one client.

That reuse never mixes in client data. The public record stays public data — your documents, holdings, and results are never folded into it, and nothing pulled from it for your analysis is attributed back to you in a way another user could see.

How much a third-party finding tells you about its source depends on where you read it.

Some of what a report says about a holding comes from someone else’s dataset — fund grades, signatory lists, financing records, impact-registry entries. Attributing those to the dataset behind them is what this product is trying to do everywhere, and it is why a dataset we haven’t loaded produces an omitted section rather than a filled-in guess. It is not yet something we can tell you holds on every page, so the rest of this section is what actually happens rather than what we intend.

The written report carries the most: the source named, its vintage, its URL. Others carry less. The CSV export has vintage columns for some datasets and none for others, and no source-URL column at all. The in-report badges carry the source and its value, but not a link. And a structured receipt can record an impact-registry certification against a holding carrying no source, no vintage and no URL beside it — that one names no dataset at all, which is why the paragraph above stops short of promising you it always would.

A single, uniform “source, vintage, and URL, everywhere it appears” guarantee is what this should become. It is not what the product does today, so this page does not claim it.

One shared research database is passed through under a dated allowance, not a clearance.

Some of what a report says about a company — a figure, and sometimes a quoted line from the company’s own filing — comes from a shared research database this product reads. That database has its own rule about what may be passed on: a value may be republished only where every source behind it carries permission to republish it. The rule is enforced where the database is served publicly. We read it over a private connection, underneath that check, so a value arrives here with no permission travelling alongside it, and we put it in your report.

That is allowed for now, by the body that governs the database, under an allowance with a date on it: 31 October 2026. The allowance exists because for a share of the values in that database the record of which source each one rests on is not yet complete. It matters most for a report you send outside your own organisation, which is why it is stated here rather than left in an engineering note.

What should happen instead is that a value we cannot clear is withheld and named as withheld — the citation kept, the number absent, said out loud in the same vocabulary this product already uses for anything else it does not have. That is filed as work to do, with the date on it. It is not built, and this page will say so until it is.

No person writes a finding into your report.

The engine produces the findings — a grade, a dollar figure, a severity, a narrative, a citation — from evidence, and that is the whole design: there is no hand-scoring screen in this product, and building one is ruled out rather than unbuilt. Where the evidence isn’t enough to support a judgment in either direction, the report says so as a named absence rather than defaulting to a number that implies certainty the evidence doesn’t support.

The honest edge, stated plainly rather than in a footnote: a transitional path still exists that accepts report content from an operator, and what it accepts is not cosmetic — it includes the graded rows themselves, along with coverage, collisions, discharge and receipts. A report assembled that way is readable through the ordinary report surfaces. That path is scheduled for deletion, not retained as an option, and no client report is meant to travel it — but while the code can still do it, we will not tell you that no person has ever authored any part of any report.

The one exception is your own governance acts, described above under “What we store” — your mission, your ratified commitments, your committee’s resolutions. Those are decisions you made, not analysis we produced, and the line between the two is the one this product holds everywhere: you state what you believe and decide what to do; the engine states what is true about the portfolio.

Your portfolio uploads are deleted 24 to 30 hours after the analysis that read them finishes, unless a delete fails.

Holdings files, custodian and sponsor statements, annual reports, anything else you attach for the analysis to read — none of it is kept. Once the analysis that used them has been complete for 24 hours, a scheduled sweep deletes the stored files. The sweep runs every six hours, which is why the window is 24 to 30 hours rather than exactly 24. Re-running the analysis restarts that clock: the sweep measures from the latest completion, and skips a session that has been re-run since it was picked up.

That is the normal schedule and not a guarantee. If the storage service refuses a delete, the sweep records the failure and leaves the file where it is; the next sweep picks it up again six hours later. So a file whose deletion keeps failing stays past the 24-to-30-hour window until a sweep succeeds. We would rather say that than name a maximum we cannot hold you to.

Two uploads are exempt and are kept: your mission statement and your investment policy statement. They are kept because your values profile and any later re-reading of your policy are built from them, and re-uploading a governing document to answer a question about it is not a reasonable thing to ask of you. They go when you delete the session, or when your account is erased — on the same best-effort terms for the stored file itself, described under session deletion on the data page.

What the sweep removes is the file, and only the file. Everything the analysis made from it stays: the holdings and identifiers extracted, the findings and the evidence behind them, the report, and the record of the document’s own name and type. Nothing sweeps those on a schedule. They go when you delete the session, or when your account is erased.

The full table — every category, its period, and whether you can delete it yourself — is on the data retention page, alongside the privacy policy.