Compute — Toronto
The application runs on Cloud Run in Toronto. Your files are parsed there, the reconciliation is computed there, and the findings are written from there.
Security
What we do with your data, stated precisely
Picklii reads two exports of your commercial data — sold hours and PSA budget — so where those files go, how long they stay, and who can reach them are fair questions to ask before you send one. Every answer below describes something already built. The last section lists what we deliberately do not claim.
Last reviewed 11 September 2026 · Picklii is a design-partner preview
Where your data lives
Your data is stored and processed in Canada. Both halves of the
system run in Google Cloud's Toronto region, northamerica-northeast2:
the application that parses your files, and the database that holds the results.
Storage — Toronto, permanently
The database is Firestore in Toronto. A Firestore database's location is fixed when it is created and cannot be changed afterwards, so this is not a setting that can quietly drift.
The export you upload is never kept
Your CSV is parsed in memory during the request that carries it, and then it is gone. It is never written to disk, never written to a storage bucket, and never copied anywhere for later. There is no file store in Picklii to put it in.
What is kept
- The parsed rows — project, role, hours, rate.
- The findings computed from them, and their severity ranking.
- Your saved column mappings, so next week is two clicks.
What is not
- The uploaded file itself, in any form.
- Any column you did not map — unmapped columns are never read.
- A copy in a bucket, a backup of the original, or an archive for audit.
This has a real cost and we would rather you hear it from us: because we keep no original, a past reconciliation cannot be recomputed from our side. If you want a run repeated, you upload the files again.
How your request reaches Toronto
This is the part most security pages leave vague, so here it is plainly. The application is served through Firebase Hosting. That means your browser's encrypted connection terminates at the Google edge location nearest you — which may be outside Canada — and the request is then carried to the Toronto service over Google's own network.
So the accurate claim is “stored and processed in Canada” — not
“nothing we run ever touches your data outside Canada”. Storage and processing
are Canadian. The connection path is not.
If Canadian TLS termination is a requirement for you rather than a preference, say so — it is an infrastructure change we know how to make, not a redesign. We have not made it yet because no one has needed it.
The AI agent, and what it may do
Picklii includes a conversational agent that answers questions about your reconciliations. It runs on Gemini through Google Cloud's Vertex AI, inside our own Google Cloud project — not through a consumer AI product, and not through a third party.
There is no API key
The service authenticates to Vertex AI with its own Google Cloud identity. No API key exists anywhere in the system, which means there is none to leak, rotate, or find in a log.
Montreal, not Toronto Exception
This is the one part of Picklii that does not run in Toronto. Google does
not serve Gemini from the Toronto region at all — we verified this
against the API rather than the documentation — so the agent calls
northamerica-northeast1, Montreal.
Still Canada, and still the only exception.
It can only read
The agent has exactly five tools, every one of them read-only and scoped to your organization. It cannot start a reconciliation, change a mapping, alter your severity settings, or delete anything.
| Tool | What it does | Writes? |
|---|---|---|
| list_runs | Lists your past reconciliation runs | No |
| get_run | Reads one run and its findings | No |
| search_findings | Filters findings within a run | No |
| list_mapping_profiles | Reads your saved column mappings | No |
| get_severity_config | Reads your severity settings | No |
That is the complete list. The agent cannot compose its own query against the database — it chooses from these five and nothing else.
Who can get in
Picklii is invite-only, and that is enforced on the server rather than in the interface. Identity comes from Firebase Authentication; authorization comes from an allowlist the server checks on every single request.
Identity is not access
Anyone can authenticate with a Google account. That gets them nothing: an
account absent from the allowlist is inert — every route answers
403 and it reaches no data at all.
The gate is server-side
No check in the browser is load-bearing. Bypassing the interface entirely
and calling the API directly still yields
401 or 403.
Verified email required
An account using a password provider whose email address is unverified is refused, even if that address is on the allowlist.
Secrets and deployments
Production secrets live in Google Secret Manager and are never committed to the codebase.
No service-account keys exist
Not in the repository, not in a password manager, not on a laptop. Our build pipeline authenticates to Google Cloud by Workload Identity Federation, which mints a credential that lives for minutes and is bound to a single workflow run.
Deploys are automated and reviewed
Changes reach production through a pipeline that runs the full test suite first, from a reviewed change on the main branch — not from anybody's machine.
This website itself
The page you are reading loads no analytics, no tag manager, no web font, no icon library, and no third-party script of any kind. Everything it needs comes from this domain. It sets no cookie; the only thing it stores in your browser is whether you chose the light or dark theme.
That is enforced by a test, not by good intentions: our build fails if any asset on this site points at another origin.
What we don't claim
Picklii is an early-stage product in a design-partner preview, and the list below is as much a part of an honest security page as the list above. We do not have these, and we would rather you learn that here than discover it in procurement.
- No SOC 2 report. No audit has been performed, at either Type I or Type II.
- No ISO 27001 certification. There is no certified information-security management system behind this.
- No third-party penetration test. Nobody external has tried to break this and written it up.
- No formal incident response process. There is no documented, rehearsed procedure with defined notification timelines.
- No data processing agreement yet. We have no standard DPA or privacy policy to hand you. If your procurement requires one, that is a conversation, not a download.
- No encryption claims beyond the platform's. Data is encrypted in transit and at rest because Google Cloud does that by default. We have added nothing on top, and we will not imply we have.
Ask us something this page doesn't answer
If your security review has a question that isn't covered here, send it. A specific answer, or an honest “we don't do that yet”, comes back — this page gets updated either way.