Found during the Gate B3 scoping pass (#43), unattended run 2026-08-28. Searched open and closed first: #43 covers the redaction design and #48 covers entity-name accuracy; neither describes this surface and neither ships before 2026-09-30. This is the live leg, and it is leaving the building today.
What happens
drb-c2-core/app/internal/alerter.py writes a raw 200-character transcript_snippet into the alert_events document and POSTs the same text to the customer's own Discord webhook. No redaction of any kind is applied.
Board minutes #42 ratified that person names are suppressed on every surface until E&O is bound. A webhook POST to a third-party service is the least recoverable surface we have: once it is in a Discord channel we do not control it, cannot unsend it, and cannot audit who read it.
#43 is a 2026-09-30 deliverable that needs a per-talkgroup flag, a new data model, and a redactor built from scratch (the extraction prompt carries no person-name field — see the scoping comment on #43). That is 6-10 engineering-days.
This one does not need any of it. The snippet is a convenience field. It can be truncated to nothing, or dropped from the webhook payload entirely, without waiting for the redactor to exist. Alerting keeps working; the alert says an incident matched and links to it.
Why it is not urgent-in-practice today, and why that will change
Today the only consumers are the owner and the comped friends-and-family tier, so the blast radius is people who already have full access. It becomes a real exposure the moment the first outside operator is given alerting — which is the sellable path, so it is on the critical line to revenue rather than off to one side.
It also interacts with the open owner ruling on #43: whether comped access to unredacted names is paused today or knowingly left in breach until 2026-09-30. If the answer is "paused", this is in scope of that pause and is the first thing that has to change.
What done looks like
The webhook payload carries no raw transcript text, or carries it only when the org has explicitly opted in under contract.
alert_events either stores no raw snippet or stores it in a field the Firestore rules do not expose to browser reads.
A test that asserts the outbound payload contains no transcript text by default.
Found during the Gate B3 scoping pass (#43), unattended run 2026-08-28. Searched open and closed first: #43 covers the redaction *design* and #48 covers entity-name *accuracy*; neither describes this surface and neither ships before 2026-09-30. This is the live leg, and it is leaving the building today.
## What happens
`drb-c2-core/app/internal/alerter.py` writes a raw 200-character `transcript_snippet` into the `alert_events` document and POSTs the same text to the **customer's own Discord webhook**. No redaction of any kind is applied.
Board minutes #42 ratified that person names are suppressed on **every** surface until E&O is bound. A webhook POST to a third-party service is the least recoverable surface we have: once it is in a Discord channel we do not control it, cannot unsend it, and cannot audit who read it.
## Why this is separate from #43
#43 is a 2026-09-30 deliverable that needs a per-talkgroup flag, a new data model, and a redactor built from scratch (the extraction prompt carries no person-name field — see the scoping comment on #43). That is 6-10 engineering-days.
This one does not need any of it. The snippet is a convenience field. It can be **truncated to nothing, or dropped from the webhook payload entirely**, without waiting for the redactor to exist. Alerting keeps working; the alert says an incident matched and links to it.
## Why it is not urgent-in-practice today, and why that will change
Today the only consumers are the owner and the comped friends-and-family tier, so the blast radius is people who already have full access. It becomes a real exposure the moment the first outside operator is given alerting — which is the sellable path, so it is on the critical line to revenue rather than off to one side.
It also interacts with the open owner ruling on #43: whether comped access to unredacted names is paused today or knowingly left in breach until 2026-09-30. If the answer is "paused", this is in scope of that pause and is the first thing that has to change.
## What done looks like
- The webhook payload carries no raw transcript text, or carries it only when the org has explicitly opted in under contract.
- `alert_events` either stores no raw snippet or stores it in a field the Firestore rules do not expose to browser reads.
- A test that asserts the outbound payload contains no transcript text by default.
Refs #43, #48, #42, #45.
Fixed and pushed — commit 0635de8, unattended run 2026-08-29.
Raw transcript text now requires two independent gates, both closed by default:
an operator switch set from the environment, and
an explicit per-org opt-in on the organization document.
The operator switch is not redundant with the org flag. The frontend reads and writes Firestore directly from the browser, so consent alone would have let an org owner opt themselves into receiving person names lifted from live public-safety traffic. Capability is the operator's to grant; consent is the org's to give. Both, or nothing.
The gate fails closed on a Firestore read error and on a call with no org — a pre-tenancy node that has not been through the backfill. A less informative alert is cheap; an unrecallable disclosure to a third party is not.
Alerting itself is unchanged. The webhook still fires and still carries the rule name, the talkgroup and the matched keywords — only the transcript text is withheld. Both surfaces named in this issue are covered: the outbound POST and the alert_events document, which the browser reads directly.
Seven tests assert that a person name present in a sample transcript appears in neither the outbound payload nor the Firestore write, across every combination of the two gates, plus the two fail-closed paths. Full suite: 273 passed.
This did not wait on #43. As this issue argued, the snippet was a convenience field and needed no redactor in order to be withheld — so the live leg is closed today rather than on 2026-09-30.
Still open and unaffected:#43 (the Gate B3 redactor proper) and #48 (entity-name accuracy). The owner ruling referenced here — whether comped access to unredacted names is paused today or knowingly left in breach until 2026-09-30 — is still outstanding on #43. This change removes the third-party leg of that question but not the question.
**Fixed and pushed — commit `0635de8`, unattended run 2026-08-29.**
Raw transcript text now requires two independent gates, both closed by default:
1. an operator switch set from the environment, and
2. an explicit per-org opt-in on the organization document.
The operator switch is not redundant with the org flag. The frontend reads and writes Firestore directly from the browser, so consent alone would have let an org owner opt *themselves* into receiving person names lifted from live public-safety traffic. Capability is the operator's to grant; consent is the org's to give. Both, or nothing.
The gate fails **closed** on a Firestore read error and on a call with no org — a pre-tenancy node that has not been through the backfill. A less informative alert is cheap; an unrecallable disclosure to a third party is not.
Alerting itself is unchanged. The webhook still fires and still carries the rule name, the talkgroup and the matched keywords — only the transcript text is withheld. Both surfaces named in this issue are covered: the outbound POST **and** the `alert_events` document, which the browser reads directly.
Seven tests assert that a person name present in a sample transcript appears in neither the outbound payload nor the Firestore write, across every combination of the two gates, plus the two fail-closed paths. Full suite: **273 passed**.
This did not wait on #43. As this issue argued, the snippet was a convenience field and needed no redactor in order to be withheld — so the live leg is closed today rather than on 2026-09-30.
**Still open and unaffected:** #43 (the Gate B3 redactor proper) and #48 (entity-name accuracy). The owner ruling referenced here — whether comped access to unredacted names is paused today or knowingly left in breach until 2026-09-30 — is still outstanding on #43. This change removes the third-party leg of that question but not the question.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found during the Gate B3 scoping pass (#43), unattended run 2026-08-28. Searched open and closed first: #43 covers the redaction design and #48 covers entity-name accuracy; neither describes this surface and neither ships before 2026-09-30. This is the live leg, and it is leaving the building today.
What happens
drb-c2-core/app/internal/alerter.pywrites a raw 200-charactertranscript_snippetinto thealert_eventsdocument and POSTs the same text to the customer's own Discord webhook. No redaction of any kind is applied.Board minutes #42 ratified that person names are suppressed on every surface until E&O is bound. A webhook POST to a third-party service is the least recoverable surface we have: once it is in a Discord channel we do not control it, cannot unsend it, and cannot audit who read it.
Why this is separate from #43
#43 is a 2026-09-30 deliverable that needs a per-talkgroup flag, a new data model, and a redactor built from scratch (the extraction prompt carries no person-name field — see the scoping comment on #43). That is 6-10 engineering-days.
This one does not need any of it. The snippet is a convenience field. It can be truncated to nothing, or dropped from the webhook payload entirely, without waiting for the redactor to exist. Alerting keeps working; the alert says an incident matched and links to it.
Why it is not urgent-in-practice today, and why that will change
Today the only consumers are the owner and the comped friends-and-family tier, so the blast radius is people who already have full access. It becomes a real exposure the moment the first outside operator is given alerting — which is the sellable path, so it is on the critical line to revenue rather than off to one side.
It also interacts with the open owner ruling on #43: whether comped access to unredacted names is paused today or knowingly left in breach until 2026-09-30. If the answer is "paused", this is in scope of that pause and is the first thing that has to change.
What done looks like
alert_eventseither stores no raw snippet or stores it in a field the Firestore rules do not expose to browser reads.Refs #43, #48, #42, #45.
Fixed and pushed — commit
0635de8, unattended run 2026-08-29.Raw transcript text now requires two independent gates, both closed by default:
The operator switch is not redundant with the org flag. The frontend reads and writes Firestore directly from the browser, so consent alone would have let an org owner opt themselves into receiving person names lifted from live public-safety traffic. Capability is the operator's to grant; consent is the org's to give. Both, or nothing.
The gate fails closed on a Firestore read error and on a call with no org — a pre-tenancy node that has not been through the backfill. A less informative alert is cheap; an unrecallable disclosure to a third party is not.
Alerting itself is unchanged. The webhook still fires and still carries the rule name, the talkgroup and the matched keywords — only the transcript text is withheld. Both surfaces named in this issue are covered: the outbound POST and the
alert_eventsdocument, which the browser reads directly.Seven tests assert that a person name present in a sample transcript appears in neither the outbound payload nor the Firestore write, across every combination of the two gates, plus the two fail-closed paths. Full suite: 273 passed.
This did not wait on #43. As this issue argued, the snippet was a convenience field and needed no redactor in order to be withheld — so the live leg is closed today rather than on 2026-09-30.
Still open and unaffected: #43 (the Gate B3 redactor proper) and #48 (entity-name accuracy). The owner ruling referenced here — whether comped access to unredacted names is paused today or knowingly left in breach until 2026-09-30 — is still outstanding on #43. This change removes the third-party leg of that question but not the question.