Privacy Policy — Your Assignment Desk
Effective date: 5 October 2026
Who we are: The Boston Storytelling Collab LLC, a Massachusetts limited liability company, doing business as Your Assignment Desk ("Your
Assignment Desk", "we", "us"). Contact: hello@thestorytellingcollab.com.
1. The short version
- We do not use cookies. We do not run analytics. We do not use trackers, ad pixels, or advertising networks of any kind. We verified this by searching the entire codebase; there are none.
- We do not sell, rent, or share your data with anyone for their own purposes.
- We store what a newsroom needs us to store to do the job, for a stated period, and then it expires automatically.
- Tips forwarded to us are readable by us. We can read them and so can our AI sub-processor. Sealing — encrypting a tip line to a key only your newsroom holds — is built but not yet open to newsrooms. Section 5 explains this without softening it.
1b. Who is actually holding your data
Your Assignment Desk is a trade name. The entity that controls this data, and the one you would bring a claim against, is The Boston Storytelling Collab LLC, a Massachusetts limited liability company. Saying so plainly is the point of this section: a privacy policy that names a brand rather than a legal person tells you nothing about who is accountable.
2. Who the data belongs to
Two different relationships, and the distinction matters legally:
Your newsroom's own account data — the email addresses, names, and station details of the people who sign in. You give us this directly. We are the controller of it.
Everything your tip line receives — emails from sources, whistleblowers, PR firms, and members of the public. Your newsroom is the controller of that material; we only process it on your instructions. We do not decide what to do with it, we do not use it to improve any product, and we do not use it to train any model. When your newsroom deletes it or leaves, it goes.
Nothing is shared by default. Each newsroom's material is kept separate from every other newsroom's. No other customer can read it.
Sharing happens only when the customer directs it. If a station belongs to a station group, the group sees activity counts for its own stations: how many boards, pitches, assignments, records requests, follow-ups and ideas, and nothing of what they say. The group sees a station's board only after that station's owner turns sharing on, and the owner can turn it off at any time. The switch, and what it shares, are on the station owner's own account page.
Tips are never shared. No group view, tool or report reads a station's tip line, and there is no administrative view of everyone's tips, including for us.
3. What we collect
From the people who sign in
| What | Why | How long we keep it |
|---|---|---|
| Email address | It is your login and where pitches are delivered | Until the account is deleted |
| Name | So the desk can address you | Until the account is deleted |
| Password | Verification only — stored as a PBKDF2-SHA-256 hash with a per-account random salt, never in readable form | Until the account is deleted |
| Station and market | Determines which archive and which tip line you can see | Until the account is deleted |
| Session token | Keeps you signed in | 12 hours, then expires automatically |
| Failed sign-in counts | Locks out password guessing | 15 minutes |
Usage records
We keep a record of what the software did, not what it said. One entry per model call, per sign-in attempt, and per action taken in the dashboard:
| What | Why | How long we keep it |
|---|---|---|
| Which account and station made a request, and when | So we can tell a station what its own usage is, bill accurately, and investigate "it stopped working this morning" | 90 days |
| Which route ran (a sweep, a chat, a tip vetting) and whether it succeeded | Fault-finding and reliability | 90 days |
| Token counts and response time reported by the model provider | This is the only honest basis for a cost figure | 90 days |
| Sign-in attempts, successful and failed, including the address attempted | Without the failures, an attack on your accounts leaves no trace | 90 days |
| Administrative actions taken by our staff, and which person took them — and the two key operations a newsroom's own admin will be able to perform once sealing opens (publishing or resetting the sealing key) | So there is an audit trail of anyone at our end who looked at anything, and of the one irreversible thing a newsroom can do to its own tip line | 400 days |
| Which action was taken in the dashboard — a sweep started, a pitch opened, a script written, a script copied, a board emailed, a tip opened, vetted or dismissed, a section viewed, a search run | So we can tell whether the software is being used, or only being paid for | 90 days |
| Active time, in whole seconds — counted only while the tab is on screen and somebody has touched it in the last two minutes | An open tab is not a person. Without this we would report the hours a wall screen was lit as if they were work | 90 days |
| How many results a search returned, whether it returned none, and whether another search followed within a minute | A search that finds nothing is the clearest signal that something is missing. We can act on it without ever seeing the query | 90 days |
| The local hour and weekday on the machine that acted | To know whether this is a morning-meeting tool or an all-day one. It is a number from 0-23 and a number from 0-6, not a timezone, a location or a device | 90 days |
The dashboard sends these as small batches of integers, at most once a minute, to our own servers. Each one is a verb from a fixed list plus up to three numbers. There is no field in that message that can hold a sentence, and the server rejects any verb that is not on the list rather than storing it under a new name.
These records contain no editorial content. Not the text of a pitch, not a tip, not a script, not a search term, not a prompt, not a model's reply. The system that writes them has no field capable of holding any of those — the constraint is in the code, not in our good intentions, and it is covered by automated tests that fail the build if content ever reaches a usage record. That includes what the dashboard itself sends: we count that a search happened and how many results it found, and we do not record what was typed into it. The tip index searches the text of your tips, so a query would be a window into your unpublished reporting; that is why the number is the only thing that travels.
These records live in a separate store from your pitches and your tips.
From your tip line
| What | How long |
|---|---|
| The sender's address, subject, date, and message body of every email forwarded to your intake address | 365 days, then deleted automatically |
| The desk's assessment of each tip | Same 365 days, deleted with the tip |
From the work the desk does
| What | How long |
|---|---|
| Story pitches generated for you, and the public sources cited for each | 120 days |
| A story your newsroom saved to Favorites — the pitch as it stood when it was saved, who saved it, when, and any note added to it | Until somebody at your newsroom removes it. This one does not expire, because the whole purpose of saving a story is that you come back to it on a day you have time. Deleting it from Favorites deletes the record. |
| The daily news ticker for your market | 26 hours |
| A count of how many AI requests your account has made today | Reset daily; used only to enforce your usage limit |
From public agency Pages on Facebook
Once Meta approves it (see Facebook data below), the desk reads the public posts of a fixed list of government Pages — police and fire departments, emergency services and town halls — to find story leads for newsrooms. For each post it reads the Page's name, the post's text, the time it was posted, and the post's own Facebook link. It asks Facebook for nothing else: no comments, no reactions, no information about the people who follow, like or reply to a Page.
| What | How long |
|---|---|
| The post as the desk read it (Page name, text, time, link) | About five minutes, in a short cache, then discarded |
| A story pitch that cites a post — which may quote or paraphrase it and carries its Facebook link | The same as any pitch: 120 days, or until your newsroom removes it from Favorites |
From visitors to the website
| What | Why | How long |
|---|---|---|
| Name, company, email, phone, and any note you type into the demo request form | To reply to you | ~400 days |
| Country and referring page, taken from the request | Basic context on where enquiries come from | With the enquiry |
| A short-lived counter derived from your IP address | Stops one machine from flooding the form | 10 minutes |
We do not store visitor IP addresses as a record. They are used transiently to enforce rate limits and then discarded when the counter expires.
4. What we do not collect
No cookies. No third-party analytics — no Google Analytics, no Segment, no Mixpanel, nothing that reports your behaviour to another company. No advertising or marketing pixels. No session-replay or heatmap tools. No fingerprinting. No location beyond the country code that arrives with a web request. No purchase of data about you from brokers. No sale of data about you to anyone.
We do keep the first-party usage records described in section 3 — counts, timings and token totals, held by us, shared with nobody, and containing no editorial content. An earlier draft of this policy said "no analytics of any kind." That was accurate when it was written and stopped being accurate when we built our own usage records, so it has been corrected rather than left standing.
If a future release changes any of this, we will update this policy and say so.
5. Tips: readable by us until sealing opens
This is the most important section in this document and we would rather you read it than discover it.
By default, a tip forwarded to your intake address is stored in a form we can read. When it arrives, its sender address, subject and body are also sent to Anthropic PBC, our AI sub-processor, so the desk can assess it and suggest how to verify it. Anthropic processes it on our behalf under their commercial terms and does not train on it. But the plain fact is that the message leaves our systems and that we ourselves can read it.
Sealing is not open yet. Sealing means your newsroom generates an encryption key pair, keeps the private half, and gives us only the public half. From that moment, every tip that arrives is stored as ciphertext we cannot open, it is not sent to our AI sub-processor, and it is not assessed by us at all — the only copy anyone can read is the one your private key opens. It is built, and it is closed until the dashboard can generate the key and open a sealed tip on screen: publishing a key before then would lock your newsroom out of its own tip line. So no newsroom can publish one today, and every tip line is unsealed. Once it opens, publishing the key is deliberate: it can be done only by your station's owner account, only with the owner's password re-entered in the same request, and it is written to our audit log with that person's name. It is also write-once — a published key cannot be replaced by your newsroom, because replacing it would orphan every tip sealed to the old one. Only we can reset it, at your request, and the reset is logged the same way.
When it opens: we will tell you plainly, in writing, the day sealing opens to newsrooms, and rewrite this section that day.
Until your station reports sealed: true, do not treat this tip line as a
secure channel for a confidential source. Any claim that we cannot read your
tips is true only for a sealed station and only for tips received after the key
was published; we do not authorise anyone to make it about an unsealed station.
Sealing protects tips that arrive after the key is published. It does not retroactively encrypt anything already received. If a tip to a sealed station cannot be sealed, or cannot be stored once sealed, nothing readable is kept: the sender's email is returned asking them to send it again or telephone the newsroom, and your newsroom sees only that a tip arrived and could not be kept.
6. Who else touches the data
| Sub-processor | What reaches them | Why |
|---|---|---|
| Cloudflare, Inc. | Everything. Hosting, storage, and the email routing that receives your tips. | Infrastructure |
| Anthropic PBC | Story signals and generated drafts. For unsealed stations, also the sender address, subject and body of each tip. | The AI that drafts pitches, scripts, and tip assessments |
| Resend | Recipient address and message body of email we send — pitch deliveries, demo enquiry notifications, support replies | Outbound email |
One check that is deliberately not a data transfer. When an account is created, we test the chosen password against Have I Been Pwned's public breach corpus. We do this with k-anonymity: the password is hashed here and only the first five characters of that hash are sent. Roughly eight hundred different passwords share any given prefix, so the request identifies nothing, and the password itself never leaves our systems. We do not do this at sign-in.
That is the complete list. There are no others.
One more, on the public website only: the marketing page loads fonts from Google Fonts, which means Google receives visitors' IP addresses and browser details when the page loads. The signed-in application does not do this.
The desk also reads public sources — city open-data portals, court records, meeting agendas, regulatory databases, and (once Meta approves it) the public Facebook Pages of government agencies through Meta's Graph API. Those are outbound reads. No customer or tip data is ever sent to them. A post's text reaches Anthropic as part of the story signals, like any other public source; it is never used to train a model.
7. Legal process and confidential sources
We think you deserve a straight answer rather than a paragraph of hedging.
If we receive a subpoena, warrant, or other legal demand for material in your account, then unless we are legally prohibited from doing so, we will notify you before producing anything, so that your newsroom and its counsel can respond or move to quash. We will produce only what the demand actually requires.
What we can produce is limited by what we hold. For an unsealed tip line, we hold readable messages and can be compelled to produce them — and today every tip line is unsealed (section 5). For a sealed one, once sealing opens, we would hold ciphertext we cannot open, and the key would not be ours to hand over. That difference is the entire reason sealing exists.
We are not a law firm and this is not a promise about how any court will rule. Journalist's-privilege and shield-law protections vary by state and by circumstance.
We do not voluntarily hand material to anyone.
8. Your choices
See what we hold. Ask at hello@thestorytellingcollab.com and we will provide it. — self-serve export is being built; today this is a manual request.
Delete it. Ask and we will delete your account and its contents. Deleting an account does not immediately end a session that is already open; that expires within 12 hours.
Do nothing. Everything above expires on its own schedule regardless.
Facebook data, and how to have it deleted
Your Assignment Desk has no "Log in with Facebook" and never reads a person's Facebook account. The only Facebook data it handles is the public posts of the government Pages described in section 3, read through Meta's Graph API under Meta's Page Public Content Access feature. We collect nothing about individual Facebook users.
To have any Facebook-sourced material removed — a cached post, or a pitch that quotes one — email hello@thestorytellingcollab.com with the post's link. We will remove it from everything we control and reply to say what, if anything, remains: a pitch a newsroom has saved to its Favorites stays in that newsroom's archive until they remove it, and we will ask them to. Posts leave our cache on their own within minutes, and unsaved pitches expire as described in section 3.
Where you are matters. Some laws — the EU and UK GDPR, California's CCPA/CPRA, and other state privacy laws — give people specific rights over their data, such as access, correction and deletion, and set deadlines for a response. Write to hello@thestorytellingcollab.com and tell us where you are; we will honour the rights the law that applies to you gives you, within its deadline.
9. Security
Passwords are hashed with PBKDF2-SHA-256 and a per-account random salt. Sessions expire after 12 hours. Sign-in attempts are throttled. Every route that returns a newsroom's data requires a live session, and tip routes additionally require that the session names a station — a session without one gets nothing rather than everything. Which station or market you are acting as is read only from your server-side session, never from anything a caller can set.
No system is perfectly secure, and we would rather point at the specific things we do than claim a standard we have not been audited against.
10. Children
The service is sold to newsrooms and is not directed at children. We do not knowingly collect information from anyone under 13.
11. Changes
If we change this policy we will update the date at the top and, for anything that materially changes what we do with your data, tell account holders directly before it takes effect.