Every external system, registered and classified.
Before any data is ingested, every external system is registered in the canonical data surface registry. Each surface is classified by what it offers, what it costs to integrate, and whether it belongs in the measurement at all.
Enterprise privacy model → Measurement methodologyThe canonical record of every external system.
The registry is the single source of truth for what systems exist, what signals they offer, what content they require, and what strategic disposition governs them. No system is ingested without a registry entry.
Every system in scope carries a registry entry like this one. The entry is created before ingest, reviewed before each pilot, and versioned alongside the reference field.
Five dispositions. One decision per system.
Every registered surface receives exactly one strategic disposition. The disposition states what the product will do with that system — and what it will not.
Build and operate
We build and operate the connector ourselves. The system is core to measurement and worth the integration investment. Owned connectors are maintained to production quality.
Read-only ingest
We ingest signals from the system through its existing API or export. We do not build a deep connector. The system provides useful context but is not core to the measurement primitive.
External join only
We do not ingest from the system. We join its outcomes to our internal metrics for a declared validation question. The join is optional, governed, and always ASSOCIATION.
Partner integration
The system is integrated through a formal partner relationship. Data flows under the partner's governance and contract. Used when direct integration is not possible or appropriate.
Out of scope
The system is explicitly excluded. It may be out of privacy scope, out of measurement scope, or not worth the integration cost. Exclusion is a deliberate decision, recorded in the registry.
The systems we can see — and how we classify them.
These are the categories of systems that produce observable signals relevant to AI operator intelligence. Inclusion in this list is not inclusion in a pilot. Each system is registered and dispositioned separately.
AI
Operator-facing AI systems. The primary measurement surface.
Communication
Messaging and collaboration platforms. Content is not required — metadata and timing only.
Engineering
Code hosting, issue tracking, and DevOps. Numeric signals for workflow fit and outcome joins.
Documents
Document and knowledge systems. Content not required; existence and structure signals only.
Projects
Project and task management. Workflow-stage signals and completion timing.
Sales
CRM and sales engagement. Outcome joins for sales-adjacent cohorts.
Support
Customer support and ticketing. Outcome joins for support-adjacent cohorts.
Learning
Learning and skills platforms. Optional context for training interventions.
Custom
Enterprise-specific systems not listed here are registered with a custom entry and dispositioned like any other surface.
Minimum evidence, not maximum collection.
We do not collect everything because it exists. We collect the minimum evidence required to answer the measurement question.
The registry exists to enforce this principle. Every system is registered before ingest, dispositioned against a measurement question, and reviewed for whether the question still justifies the data. Systems that no longer serve a question are removed — not retained just in case.
Every system is classified by privacy level.
Privacy class is assigned at registration and reviewed before each pilot. It governs who may see the system's signals and under what conditions.
| Privacy class | Meaning | Examples |
|---|---|---|
| CORE | Token telemetry and signed numeric snapshots. Required for measurement. Content-free. | AI token counts, cache reads/writes, yield, leverage |
| CORE-ADJACENT | Numeric and metadata signals adjacent to core telemetry. No content. Optional but commonly joined. | GitHub PR counts, Jira issue counts, deployment frequency |
| METADATA | Approved metadata only. No content, no body text, no attachments. Explicitly approved per pilot. | Slack channel membership, Drive file existence, Notion page counts |
| CONTENT-EXCLUDED | System may contain content, but content is explicitly not required and not ingested. The system is registered to document the exclusion. | Email bodies, Slack messages, document text, code content |
| OUTCOME-JOIN | External business outcomes joined for a declared validation question. Optional, governed, ASSOCIATION only. | Sales revenue, support CSAT, engineering cycle time |
A system's privacy class can change between pilots — but only through an explicit registry update, never silently. The registry is the audit trail.
The registry is the first artifact of a pilot.
Before any data flows, the registry is drafted, reviewed, and signed off. It is the contract between measurement scope and privacy governance.
Enterprise governance → Design a pilot →