That shift moves the bar for every integration shipped, from “does it parse” to “does it mean what the source meant.” Across the 6,000+ integrations we have built, the defects that reach production are rarely parsing failures. They are records that validate cleanly and describe the wrong event. This post is about that class of defect: where meaning gets lost, why schemas cannot catch it, and how to make it testable before an agent builds a case on it.

A valid record can still describe the wrong event

Schema validation establishes important properties: required fields exist, values have permitted types, and enumerations follow the selected schema. It can also enforce relationships that the schema explicitly expresses.

However, checking a transformed record against its destination schema generally cannot establish that the mapper chose the correct source value for each role. Two user identifiers may both satisfy the same type constraints even when their assignments are reversed.

The distinction is visible in public specifications. OCSF’s actor guidance describes the entity initiating an action on another entity. A public directory-audit API likewise distinguishes the initiating user or application from the resources affected by the activity.[2] Those roles express different facts.

For the above scenario, a source-aware mapping test would establish that the administrator remains the initiator and the disabled account remains the target. Checking that both identifiers are strings would establish a much narrower property.

This is where integration engineering requires domain judgment. Field names help, but the event type, source documentation, payload context, and supported workflow determine what a value means. The same word—“user,” “status,” or “time”—can represent different concepts across sources and event classes.

Three places where meaning is easily lost

1. Identity roles and scope

Every identity event has an initiator and a target, and the roles are facts, not labels. A public integration repository closed exactly this bug in July 2026: Linux account-management events that parsed cleanly but put the affected account in the acting-user fields, or left the target empty. The fix shipped with a migration note because detections and dashboards had been built on the wrong locations. Self-service changes make it harder, not easier: initiator and target are legitimately the same identity, so a test that simply requires them to differ encodes a second error.

2. Event time and observation time

Suppose the account was disabled at 09:00 UTC, an access attempt failed at 09:05, and the disable event reached the collector at 09:15. Substituting observation time for event time would change the apparent order of those records.

OpenTelemetry’s Logs Data Model explicitly distinguishes Timestamp, representing when an event occurred, from ObservedTimestamp, representing when the collection system observed it. That distinction helps preserve the basis on which a consumer reconstructs activity.

Preserve both meanings where possible. When source event time is unavailable and a fallback is necessary, expose that limitation through the documented data or query contract. A timeline should not acquire more precision than the source evidence supports.

3. Outcome and uncertainty

A request was received. An operation completed. An action was blocked. A result was not reported. Each statement supports a different conclusion.

The ECS definition of event.outcome, for example, describes success or failure from the event producer’s perspective. It also distinguishes an unknown result from an event for which an outcome is inapplicable. These distinctions show why outcome mapping needs more than a convenient default.

Successful authentication does not establish benign activity. A blocked action does not establish that the entire attempted attack was contained. A missing result does not establish success.

The mapping should preserve what the source establishes and make uncertainty available to downstream consumers. If the destination cannot express a source distinction directly, document the translation and retain the original detail through an appropriate extension or source reference

Agents make those distinctions more consequential

Detection rules, dashboards, and existing automation already depend on correct mappings. Agents add another consumer and another route through which a mapping decision can influence downstream work.

An investigation agent may retrieve an event, connect it to other activity, construct a timeline, and recommend a next step. If the integration has mislabeled the initiator, every later step can operate on an incorrect premise. The agent’s prose may be fluent and its tool calls well formed while the underlying evidence remains misleading.

Agents commonly consume query results and tool outputs. The mapping implementation may sit several layers upstream. Its interpretation of the source still reaches the agent through the data it produces.

AI research offers a useful evaluation lesson. ToolSandbox tests stateful tool use, dependencies, and situations where necessary information is unavailable. Its experiments expose difficulties with these conditions in the models evaluated. τ-bench evaluates domain-specific interactions by checking the resulting database state against an expected goal, and examines consistency across repeated trials.

These studies are not benchmarks of security-event mapping, and their results should not be treated as current SOC failure rates. Their relevance is methodological: evaluating whether a call executes is only part of evaluating whether a workflow reaches a supported outcome.

For an integration team, the practical extension is to test the conclusion a representative event enables. Can a query identify the actual initiator? Can a timeline preserve the event’s time basis? Can a workflow distinguish an attempted action from a confirmed result?

Standards provide shared meaning; mappings put it into practice

OCSF and OpenTelemetry provide useful foundations in their respective domains. They define structures and semantics that help producers and consumers share an interpretation of data. They address different scopes and should be implemented according to their own models.

The integration team still has to establish how a particular source expresses the concepts those models define.

That work includes choosing the event class, identifying the initiating entity, interpreting time and outcome, handling unavailable evidence, and recording supported source variants. A schema provides the vocabulary and constraints; a reviewed mapping connects them to source behavior.

This responsibility continues as integrations evolve. A source can add a new outcome or change which identity a field represents. A destination can introduce a more precise class. Changes of this kind deserve semantic review even if parsing continues to succeed.

Correcting meaning also creates a compatibility obligation. The changelog associated with the account-management example describes affected-account fields and migration requirements for content that used the earlier locations. Mapping fixes can require coordinated updates to detections, dashboards, and saved searches.

MCP adds an interface through which an agent can discover and invoke tools. Its tool specification supports descriptions, input schemas, and optional output schemas for structured results. These mechanisms help teams define the interface, but source interpretation still has to be implemented and tested within the system behind it.

The resulting product obligation spans both layers: preserve meaning in the data, then communicate relevant limitations when that data is returned.

Make semantic expectations executable

A practical starting point is a semantic contract for each priority integration: a documented set of source interpretations, supported scenarios, and testable expectations. This is an engineering practice teams can adopt within their existing schema and release process.

For the account-disable scenario, a compact contract could cover the following:

Representative fixtures—saved source events paired with reviewed expectations—make these requirements testable. Include administrator actions, self-service changes, application-initiated operations, missing identities, unsuccessful operations, and unfamiliar source values where the integration supports those cases.

Self-service activity is an important example: initiator and target may legitimately be the same identity. A rule that simply requires them to differ would encode another semantic error.

Then test the transformation’s relationships. Change only the source initiator in a fixture and check that the normalized initiator changes while the target remains stable. Remove an outcome and check that the transformation follows its documented uncertainty policy. Add an unfamiliar source value and verify that it follows an explicit handling path.

Finally, carry selected fixtures through a downstream query, detection, or agent evaluation. A mapping test should establish that admin-a initiated the account change. A workflow test should establish that the selected consumer attributes the change accordingly.

For agent evaluations, specify the facts the answer must preserve, which claims lack support, and when the agent should seek more information. Run repeated trials where behavior is nondeterministic, and retain the relevant retrieval and tool traces. This helps distinguish a mapping regression from a retrieval, prompt, or model problem.

Version the mapping, fixtures, and expectations together. When either source behavior or the destination model changes, rerun the affected scenarios before extending the integration’s compatibility claims.

Keep event meaning and collection coverage visible

Correctly mapped records can still form an incomplete answer.

If an agent searches for account changes in the last 15 minutes while collection is delayed by 25 minutes, an empty result does not establish that no changes occurred. That is a coverage limitation, distinct from whether each available event was mapped correctly.

Query and tool contracts should surface the limits the system can establish: requested scope, known unavailable sources, truncation, and relevant collection-health evidence. A “latest event received” timestamp alone does not prove that all earlier events arrived. Avoid promising complete coverage unless the collection mechanism can support that claim.

This gives product teams two complementary obligations: preserve the meaning of the evidence they return, and communicate the boundaries of that evidence.

What to ask before your next release

Five questions separate integrations that are agent-ready from integrations that merely parse:

1.   Which integrations support a workflow an agent will act on, and who owns their meaning?
2.   For each, can the team show the fixture that proves who acted, on whom, when, with what result?
3.   When the source adds an outcome or a platform changes a schema version, which scenarios get re-run before the compatibility claim is updated?
4.   When a customer disputes a record, can they identify the mapping version that produced it and reproduce the interpretation?
5.   Does the tool or query the agent calls declare its coverage limits, or does it imply completeness it cannot support?

Start with one integration that feeds a high-value investigation. Make its meaning explicit, testable and versioned. The opening scenario ends differently when that work has been done: the role reversal is caught in the fixture, not in the incident review, and the agent’s first sentence about the administrator is true.

Join the conversation

We are going deeper on how security and observability integrations are changing as agents become their first reader, including what the shift means for how vendors build, certify and maintain them. Join Crest Data’s webinar, How Security and Observability Integrations Are Evolving for the Agentic Era, on 08 December at 02:00 pm ET. And if you want a second pair of eyes on which of your integrations are agent-ready today, our integration engineering team offers an Integration Ecosystem Assessment.

Thought Leader: Jainil Desai