Cross-Tool Workplace Records
Chat, email, documents, projects and calendars from the same companies, linked by person and time.
Sample
3 recordsChat mention that pings an owner about a task
Representative shape, not real customer data. actor and target are resolved user nodes; task_id links the chat event to the same work tracked elsewhere.
{
"event_id": "cw-7f3a9c21",
"org_id": "org_03",
"tool_category": "chat",
"tool": "slack",
"action": "message.mention",
"actor_user_id": "u_1182",
"team_id": "t_44",
"timestamp": "2026-03-11T14:22:08Z",
"thread_id": "th_9920",
"task_id": "k_3019",
"target_user_id": ["u_2210"],
"parent_event_id": "cw-7f3a9c10",
"pii_status": "stripped_at_source"
}Document comment resolved to the same task
Representative. Same task_id as the chat event above - cross-tool linkage through shared task and user nodes is the structural contribution.
{
"event_id": "cw-7f3aa118",
"org_id": "org_03",
"tool_category": "files",
"tool": "google_drive",
"action": "document.comment_added",
"actor_user_id": "u_2210",
"team_id": "t_44",
"timestamp": "2026-03-11T15:01:44Z",
"document_id": "d_5567",
"task_id": "k_3019",
"target_user_id": ["u_1182"],
"pii_status": "stripped_at_source"
}Task status transition in a tracker
Representative. Closes the cross-tool chain: the work discussed in chat and a doc moves state in the project tool.
{
"event_id": "cw-7f3ab004",
"org_id": "org_03",
"tool_category": "project_tracking",
"tool": "jira",
"action": "task.status_changed",
"actor_user_id": "u_1182",
"team_id": "t_44",
"timestamp": "2026-03-11T16:48:12Z",
"task_id": "k_3019",
"pii_status": "stripped_at_source"
}Specifications
| Formats | JSON, Parquet |
|---|---|
| Delivery | S3, REST API, Webhook, Restricted training/eval agreement / data room |
| Cadence | Real-time streaming or daily batch |
| Coverage | Continuous |
| Tool coverage | Chat, mail, docs, projects, calendar |
| Event types | 40+ normalized across sources |
| Entity resolution | User, team, org, document, task |
| Schema | Unified collaboration activity graph |
| Access | Restricted access under a signed agreement; per-recipient export. PII is stripped at source; each partner org is held as an isolated boundary. Source identities are anonymous; full provenance under NDA. |
What ships
Communication Fabric
Messages, threads, mentions, and meeting activity across chat and mail. Normalized author, thread, and channel identifiers.
Document Graph
Document creation, edits, comments, and share events across collaboration storage. Link-level traversal with access context.
Task & Project Graph
Task assignments, status transitions, and project movement across project-management tools. Timestamped for replay-safe evals.
Fields
14 fields
| Field | Description |
|---|---|
| event_idstring | Stable identifier for one normalized cross-tool activity event.Example cw-7f3a9c21 |
| org_idstring | Partner org boundary. Entities and events are never merged across orgs.Example org_03 |
| tool_categorystring | One of 10 normalized categories (chat, email, files, project-tracking, source-control, crm, ...).Example chat |
| toolstring | Source product the event came from, within its category.Example slack |
| actionstring | Normalized action verb in the unified event vocabulary (40+ types).Example message.mention |
| actor_user_idstring | Resolved user node - the same human across every tool they appear in.Example u_1182 |
| team_idstring · nullable | Resolved team node, when the event is attributable to a working group.Example t_44 |
| timestampstring · ISO-8601 | Event time, normalized to UTC for replay-safe point-in-time evals.Example 2026-03-11T14:22:08Z |
| thread_idstring · nullable | Conversation or thread node for chat and mail events.Example th_9920 |
| document_idstring · nullable | Resolved document node when a file is created, edited, commented, or referenced.Example d_5567 |
| task_idstring · nullable | Resolved task node linking the event to a unit of work across tracking and service tools.Example k_3019 |
| target_user_idstring[] · nullable | Resolved recipients and mentions, as user nodes.Example ["u_2210"] |
| parent_event_idstring · nullable | Edge to a preceding event (reply-to, edit-of, status-change-from) for activity chains.Example cw-7f3a9c10 |
| pii_statusstring | PII handling marker. PII is stripped at source before records leave the partner environment.Example stripped_at_source |
Quality checks
2 checksCross-Tool Workflow Replay
Whether an agent, given a team resolved activity graph up to a point in time, would route work the way the real team did next - who to ping, which doc to reference, how a task should move.
Reconstruct the entity-resolved graph as of a cut time; pose the in-flight situation; withhold subsequent events; compare the agent next-action to the real recorded events that followed.
Methodology-stage. The source data-availability report explicitly states no signal, model, or predictive result exists yet; none is claimed.
Entity-Resolution Integrity
Whether the same human, team, document, or task is correctly unified into one node across all tools it appears in, within an org boundary.
Validate that nodes resolved across tools refer to one real entity and that no entity is merged across partner org boundaries.
Methodology-stage. No agreement figure is published at this stage.
Ground truth
| What is correct | The real, recorded cross-tool activity the team actually produced next - the events that genuinely followed in the partner own systems - reconstructed point-in-time from the resolved graph. |
|---|---|
| How it is established | Replay-based comparison: cut the graph at a timestamp, withhold subsequent events, and compare an agent proposed next action to what the org actually did. Integrity is anchored to consent and per-partner provenance, and to entity-resolution correctness within each org boundary. |
| Agreement | Correctness is anchored to the production record itself rather than a separate human-rater pass. No inter-rater agreement figure is published at this stage. |
How it is built
- 01
Consented collection
A point-in-time snapshot drawn from consented partner companies. Each partner provides explicit consent; this is a documented snapshot, not a continuous feed.
- 02
Normalization into an activity graph
Heterogeneous, tool-specific records are mapped into a single graph where nodes are entities and edges are activities, using one normalized action vocabulary across 10 categories and 38 tools.
- 03
Entity resolution
The same person, team, document, or task collapses to one node regardless of how many tools reference it, across five entity types. Resolution runs strictly within each org boundary; entities are never merged across partners.
- 04
PII stripping at source
Personally identifiable information is removed before records leave the partner environment, so PII is not present in the normalized graph.
- 05
Per-partner provenance and isolation
Each org boundary is held isolated so the lineage of every node and edge back to its consenting partner is unambiguous; counts are reported as collected, not deduplicated across partners.
- 06
Point-in-time replay
Events are timestamped to a common UTC clock so a slice of the graph can be reconstructed as of a moment in time for replay-safe evaluation.
Request a sample
We send real records in the format you would receive, with the field list and where each record came from. Access for evaluation is limited and covered by a mutual NDA.
ProductCross-Tool Workplace Records