Telemetry Contract Builder
What a new system must log before it ships, mapped to OCSF and ATT&CK.
Sample logs you validate stay in this tab. The share link carries only the contract settings.
Export and validate logsExport the contract
Validate sample logs
Generated from the contract. Every user, IP and ID in it is made up.
Next steps in the workbench
How the contract is built
Each event is one OCSF 1.9.0 class and activity, with the fields a detection needs. Every event also carries the OCSF core: time, class, activity, type and severity IDs, metadata version, product, a unique ID, and metadata.event_code naming the contract event. Attributes that an OCSF class or object requires, such as file.type_id under File or algorithm_id under a hash, are added for you and marked OCSF. Data with no OCSF attribute, such as payout amounts or EDI control numbers, goes under unmapped.
Each technique on an event names the fields its detection keys on. Switch a field or an event off and the techniques that depend on it drop out of the score. SigmaHQ matches come from rules for comparable log sources that tag the same technique, checked field by field through a crosswalk from native names (verb, eventName, objectRef.resource) to OCSF paths.
How it compares
Checked 2026-11-06. Sample records from every event in the catalog, with every capability and pack on, were posted to the OCSF schema server's own validator for 1.9.0.
| Check | Result | Method |
|---|---|---|
| OCSF 1.9.0 validator, 53 events | 0 errors, 0 warnings (before this check: 14 constraint errors and 23 deprecation warnings) | schema.ocsf.io /api/1.9.0/v2/validate. Moved Account Change and User Access events to User Management, entity_result to updated_entity, app_name and app_uid to application |
| Validator on this page | Same findings as the official validator on all 53 records of the earlier catalog | Applies OCSF at_least_one and just_one constraints and flags deprecated classes and attributes |
| ATT&CK v19 data components | For 81 of 112 event techniques, MITRE's analytics read a component the event supplies | Detection strategy to analytic to log source, from attack-stix-data 19.2. The rest are host-side analytics that an application log does not feed |
| DeTT&CT | Exported files pass DeTT&CT v2.2.0 health checks for all 9 presets and build a Navigator layer | Data source administration file version 1.1, one entry per data component |
| Retention and privacy citations | Re-read against eCFR, EUR-Lex and PCI SSC; PCI references updated to v4.0.1 | v4.0 retired 31 Dec 2024. The PCI text was checked against published reproductions, since the standard sits behind a licence page |
- Palantir ADS asks each detection for its data needs and blind spots; this contract is that list, written before the system ships.
- Known limits: the DeTT&CT export scores data field completeness and consistency from the contract and leaves device completeness, timeliness and retention at 0 (DeTT&CT's "do not know") until they are measured. Enum sibling captions are not checked. ATT&CK v20 is current; the suite is pinned to v19.2.
Telemetry contract FAQ
What is a telemetry contract?
A written list of the events a system must log, the fields in each event and their types, agreed before the system ships. Detection engineers use it to make sure the data their rules need exists on day one, and developers use it as an acceptance test for logging.
Why OCSF?
The Open Cybersecurity Schema Framework is an open, vendor-neutral event schema with classes such as Authentication (3002) and API Activity (6003). Writing the contract in OCSF terms means the logs map cleanly into SIEMs and data lakes that speak it. The page uses the OCSF 1.9.0 schema, snapshotted from the OCSF schema server.
How is the coverage score worked out?
Each event lists the ATT&CK techniques it makes detectable and the fields each detection needs. A technique counts as enabled when one switched-on event carries every field it needs. The score is enabled techniques divided by all techniques the chosen system type could cover. Dropping an event or a field shows what you lose.
What do the SigmaHQ matches mean?
For each event the page lists SigmaHQ rules from comparable log sources, such as Kubernetes audit or Okta, that tag one of the event's techniques. It then checks whether the contract carries every field the rule's detection block uses, through a crosswalk from the native field names to OCSF paths. A rule that fits is a ready template for your own log source.
Can I load the contract into DeTT&CT?
Yes. The DeTT&CT export is a data source administration file (version 1.1) with one entry per ATT&CK data component the switched-on events supply. Data field completeness and consistency are scored from the contract on DeTT&CT's 0 to 5 table. Device completeness, timeliness and retention stay 0, meaning not known, until you measure them.
Are my sample logs uploaded?
No. Validation runs in JavaScript on this page. The share link holds only the contract settings, never log lines.
OCSF 1.9.0 schema from schema.ocsf.io, MITRE ATT&CK Enterprise v19.2, SigmaHQ rules at commit 8a48134. Event choices, technique mappings, the Sigma field crosswalk and retention tiers are this tool's own and are suggestions. Sample data on this page is generated and fictional.