A NOC incident rarely lives in one record. The evidence is spread across alarms, assets, topology, tickets, changes, and runbooks, and root-cause analysis depends on keeping those connections intact.
AI-ready NOC incident data must preserve the relationships an analyst needs to explain an incident. Alarms, device records, topology, timestamps, tickets, changes, and runbooks can all remain present while the package becomes useless for root-cause analysis if their references no longer connect.
The acceptance question is therefore not whether every sensitive field has been removed or replaced. It is whether the protected working data still supports the same bounded investigation: what changed, which asset was affected, what depended on it, what happened next, and where the approved result must return. This checklist turns that requirement into testable evidence for one NOC workflow.
Key takeaways
- Define the root-cause analysis question before choosing which relationships the protected incident package must retain.
- Test stable identity across events, assets, topology, tickets, changes, and runbooks instead of checking field presence alone.
- Preserve time, sequence, provenance, and scope so reviewers can distinguish the event source from the system that observed it.
- Approve the workflow only after the protected package and the authorized return path pass both valid and failure cases.
What makes NOC incident data AI-ready?
NOC incident data is AI-ready when a protected package retains the relationships required for a specific operational question. It does not need to reproduce every field from every source, but it must keep the identifiers, links, order, and provenance that make the selected investigation possible.
Consider a hypothetical incident package for INC-2026-042. It contains alarms associated with a circuit and router, a topology record that shows an upstream dependency, a recent change record, a ticket timeline, and a runbook reference. The values in this example are fictional. Its purpose is to define a test fixture, not to represent a real customer incident.
An AI system may produce a fluent explanation from that package. The output is still operationally weak if the alert no longer points to the affected asset, the change cannot be connected to the incident window, or the runbook reference resolves to the wrong procedure. Readiness depends on those links surviving the protected round trip.
Start with the RCA question, not the protection method
The investigation question determines which relationships are essential. A team asking why a circuit failed needs a different evidence package from a team summarizing ticket volume or clustering recurring alarm text.
Write the expected decision before transforming the data. For example: “Determine whether change CHG-042 altered the upstream path used by the asset referenced in incident INC-2026-042, and return the approved finding to that incident record.” This statement defines the required entities, time window, topology edge, change relationship, and destination.
Then classify each relationship:
- Required: the investigation cannot answer its question without it.
- Supporting: it improves interpretation but is not part of the acceptance decision.
- Excluded: it is outside the approved task, scope, or retention boundary.
This classification prevents two common mistakes. The first is retaining excessive data because the team has not defined the task. The second is removing a link that looks incidental in isolation but is necessary to connect two evidence sources.
Preserve event-to-asset identity
Every event used in the investigation should retain a stable reference to the asset it describes. Repeated references to one asset must remain consistent, while different assets must remain distinct.
The test should cover more than one representation. An asset identifier may appear in an alarm attribute, a log body, a topology record, and a ticket note. The protected package should let the workflow recognize that these occurrences refer to the same bounded entity without exposing the original value to the approved external model path.
Field counts do not prove this property. A transformed record can contain the same number of identifiers and still break the join if one occurrence uses a different substitute, if two assets collapse into one label, or if a parser changes a structured reference. Compare the source fixture and protected working version by relationship, not by replacement count.
Preserve topology and dependency links
Topology turns a collection of alarms into an incident path. The protected package should retain the edges that identify upstream, downstream, parent, peer, and service dependencies needed for the investigation.
For the hypothetical fixture, define the expected graph before the AI request: affected asset, upstream node, dependent service, and the edge that connects each pair. The protected version passes only if the same graph can be reconstructed from its approved references. A node label that remains readable is not enough when its dependency edge disappears or points to another asset.
The test should also include a negative case. Introduce an out-of-scope node or an altered edge and confirm that the workflow does not silently attach it to a valid incident path. Unknown relationships should remain explicit for review.
Preserve time, sequence, and clock context
Root-cause analysis depends on when an event occurred, when it was observed, and how events were ordered. Preserve enough clock context to distinguish source time from collection time and to compare records across systems.
RFC 5424 defines a syslog message format with fields such as timestamp, hostname, application name, process ID, message ID, and structured data. It also provides structured data for time quality. These fields do not solve clock quality by themselves, but they show why a timestamp without origin and context is an incomplete basis for correlation.
For the test fixture, retain the source timestamp, observed timestamp when available, timezone or offset, sequence marker, and the clock-quality information the workflow actually uses. Test equal timestamps, delayed ingestion, missing source time, and records that arrive out of order. The expected result should state whether the workflow may reorder, flag, or exclude each case.
Preserve ticket, change, and runbook connections
Operational evidence extends beyond telemetry. The incident package should retain the approved links from an event to the ticket where it is investigated, the change that may explain it, and the runbook used to respond.
These references need typed relationships. A change that occurred near the incident is not automatically its cause. A runbook mentioned in a note is not necessarily the procedure that was executed. Preserve labels such as related_change, executed_runbook, or the equivalent fields used by the workflow so the AI system does not infer a stronger relationship from proximity alone.
Define pass conditions for both presence and direction. The incident should point to the expected change record, and the change record should remain within the approved scope. A ticket reference must lead back to the intended incident rather than another case with similar text. If the relationship cannot be confirmed, the protected package should carry an explicit unknown state.
Preserve provenance and scope
Reviewers need to know where each piece of evidence came from and what boundary applies to it. Source system, resource context, collection path, tenant or workflow scope, and applicable policy should remain distinguishable after protection.
The OpenTelemetry Logs Data Model includes fields such as Timestamp, ObservedTimestamp, TraceId, SpanId, Resource, InstrumentationScope, and attributes. OpenTelemetry Resources describe the entity that produced telemetry. The Semantic Conventions define common attributes intended to make telemetry easier to correlate and consume. These specifications do not define an NOC AI acceptance test, but they provide primary evidence for keeping resource and event context explicit.
The protected package should not merge source provenance with observer provenance. A device that emitted an event and a collector that received it have different roles. Likewise, a trace or incident correlation ID supports a join but does not prove causation. Record those boundaries in the expected result.
Test the protected incident package
The following table is an editorial acceptance framework derived from the reader task and cited data models. It is not a universal standard. Replace its generic labels with the exact schemas, policies, and destinations used by the deployment.
Relationship-preservation acceptance checklist
Run the test with a known fixture and a predeclared expected result. Compare the protected working version against the source fixture at the relationship level. Then inspect the model response for missing, altered, duplicated, or invented references. A useful output with a broken relationship is a failed data-readiness test.
Verify the authorized return path
The protected model exchange is only part of the workflow. The final acceptance test must confirm how approved operational values are reconnected and where the result is written.
LLM Capsule’s current architecture places original values and the protected mapping inside the customer-controlled environment. A protected working version travels through the approved AI path, and Reconstruction occurs inside that environment before the result returns to a ticket, report, record, or workflow. Teams evaluating the broader boundary can use the context-preserving data layer evaluation checklist. For detailed return-path cases, see how to test deterministic Reconstruction.
For this NOC test, verify the caller, mapping scope, applicable policy, unresolved-reference behavior, destination, and downstream write. The incident system must receive the approved result once. A model response or Reconstruction response that never reaches the intended record does not satisfy the workflow.
Approval rule
Approve one NOC incident workflow only when its protected test fixture preserves every required relationship, rejects or flags the defined failure cases, and completes the authorized return path. Record the scope of that approval: question, schemas, source systems, model route, policy version, destination, and test date.
Do not extend the result automatically to another incident type, topology model, ticketing system, or deployment boundary. A reusable checklist improves consistency, but each workflow still needs evidence from its own data path.
The decision is practical: if reviewers can trace the protected incident from source evidence to the stored result without exposing original values on the approved external model path, the workflow has a bounded basis for production review. If any required relationship becomes ambiguous, repair the data package or narrow the task before approval.
