Huddles are the one hole in the DM story. §6 of the source document says to turn them off, or accept that they are unrecorded 1:1 voice — "same problem as DMs, and easy to forget" — and docs/policy-mapping.md records the control as manual on the grounds that there is no API to observe them.
That grounds deserve re-testing. A 1:1 adult–student huddle is exactly the thing §4.1 exists to prevent, and right now nothing detects one.
What the policy actually needs. Not content. Just the occurrence: an adult and a student were in a huddle with no second adult present, anchored to a timestamp. That is a dmPolicy-shaped verdict and an occurrence finding, so recurrence.ts already has the right semantics for it.
Angles to check, roughly in order of promise:
- Artifacts left in the conversation. A huddle in a DM may leave a message or a message subtype in that conversation's history. If so,
recordMessage may already be seeing it and we are simply not classifying it. Cheapest thing to test first.
- Huddle recordings and transcripts. Where enabled, these land as files in the conversation. hawk-mod already records file metadata (
{id, name, mimetype, size}), so "a huddle happened in this 1:1" may be derivable from data we hold today, without fetching anything. Note this is contingent on the feature being on, so it cannot be the only signal.
huddle_state on the user object / user_change events. A presence-shaped signal at best — it may tell us someone is in a huddle without telling us who else is. Possibly useful in combination, probably not alone.- Discovery API and audit logs. Enterprise Grid only, so out of scope for us — confirm and rule out rather than assume.
If none of it works, the fallback is unchanged: huddles stay off. But make that a verified condition rather than a hope — check whether the workspace setting is readable via API, and if it is not, put it on the quarterly audit checklist rather than leaving it as something someone remembers.
Consent form note. docs/consent-form.md currently enumerates what the team records and states "that is the entire list." If huddle tracking lands, that section and the retention section both need a sentence, and the form version bumps.
Huddles are the one hole in the DM story. §6 of the source document says to turn them off, or accept that they are unrecorded 1:1 voice — "same problem as DMs, and easy to forget" — and
docs/policy-mapping.mdrecords the control as manual on the grounds that there is no API to observe them.That grounds deserve re-testing. A 1:1 adult–student huddle is exactly the thing §4.1 exists to prevent, and right now nothing detects one.
What the policy actually needs. Not content. Just the occurrence: an adult and a student were in a huddle with no second adult present, anchored to a timestamp. That is a
dmPolicy-shaped verdict and an occurrence finding, sorecurrence.tsalready has the right semantics for it.Angles to check, roughly in order of promise:
recordMessagemay already be seeing it and we are simply not classifying it. Cheapest thing to test first.{id, name, mimetype, size}), so "a huddle happened in this 1:1" may be derivable from data we hold today, without fetching anything. Note this is contingent on the feature being on, so it cannot be the only signal.huddle_stateon the user object /user_changeevents. A presence-shaped signal at best — it may tell us someone is in a huddle without telling us who else is. Possibly useful in combination, probably not alone.If none of it works, the fallback is unchanged: huddles stay off. But make that a verified condition rather than a hope — check whether the workspace setting is readable via API, and if it is not, put it on the quarterly audit checklist rather than leaving it as something someone remembers.
Consent form note.
docs/consent-form.mdcurrently enumerates what the team records and states "that is the entire list." If huddle tracking lands, that section and the retention section both need a sentence, and the form version bumps.