AI-Ready Topology, Tickets, and Runbooks: A Cross-System Context Checklist

A network incident rarely lives in one record. The alarm points to an asset, the topology explains dependency, the ticket preserves investigation history, the change record supplies timing, and the runbook defines the response. AI-ready network operations data must preserve those cross-system relationships while protecting the values that should not follow the model path.

That makes this a different problem from checking whether one incident package contains the right fields. The task here is to prove that identifiers and references remain stable across systems, retrieval steps, model output, and the final operational write.

Key takeaways

• Define the operational question before deciding which systems and relationships the AI needs.
• Preserve stable references across topology, tickets, changes, and runbooks instead of flattening each source independently.
• Keep event time, observation time, change time, and ticket time distinct.
• Test the final ticket or workflow update, including authorization, retry, and rollback behavior.

What makes network operations data AI-ready across systems?

The data is AI-ready when a protected working version keeps the incident graph usable for the task. The model must be able to distinguish an alarm from an asset, connect the asset to the relevant topology path, follow the ticket’s evidence trail, identify a nearby change, and reference the correct runbook step without receiving the original restricted values.

Field presence alone cannot establish that. Two systems may use different names for the same circuit. A ticket may contain a copied hostname while the topology service uses an internal asset key. A change record may share a timestamp but belong to a different maintenance window. If transformation removes or merges those distinctions, the model can produce a fluent but operationally wrong explanation.

Start with the question the operator needs answered

Before selecting data, write the operational question in a testable form. “Summarize the incident” is too loose. “Explain whether the packet loss on the affected service began after the approved interface change, identify the dependent assets, and propose the applicable runbook step” exposes the relationships the workflow must retain.

The question determines the evidence graph:

• the event and the bounded asset it describes;
• the topology edges needed to assess impact;
• the ticket entries that distinguish observation from hypothesis;
• the approved change and its effective window;
• the runbook version and the conditions for its step; and
• the destination that is allowed to receive the result.

More context is not automatically better. Pulling an entire topology or ticket archive can increase disclosure and introduce unrelated references. The workflow should retrieve the smallest connected evidence set that supports the operator’s decision.

Preserve identity without flattening provenance

Stable identity does not mean replacing every occurrence with the same generic label. The protected representation must preserve distinct entities and repeated references while retaining the source of each assertion.

For example, an alarm may report a device label, the configuration database may hold an asset record, and the ticket may contain a human-entered alias. They can refer to the same equipment without being equivalent evidence. A production test should verify both resolution and provenance: the model can follow the relationship, and reviewers can still tell which system supplied each fact.

This distinction also appears in OpenTelemetry’s service semantic conventions, which separate a service namespace, logical service name, and unique service instance. A protected workflow should retain whichever identity levels the operator’s question actually uses.

The same rule applies to topology. IETF RFC 8345 represents topology through nodes, links, termination points, and supporting relationships across topology layers. Direction, dependency type, containment, and confidence can change the meaning of an edge. A flat list of connected assets is not a substitute for the approved path used in root-cause analysis.

Keep the clocks separate

Network operations data carries several time concepts. Event time records when the condition occurred. Observation or ingestion time records when a system saw it. Ticket time records when a person or automation added information. Change time records when an approved action was planned or executed.

An AI workflow can create a false causal story if those clocks collapse into one sequence. Preserve the time type, source, timezone or offset, and uncertainty where relevant. Then test cases in which ingestion is delayed, ticket notes arrive out of order, or two changes overlap.

Use a protected incident graph through the model path

LLM Capsule keeps original values and the protected mapping inside the customer-controlled environment. The workflow assembles a protected working version in which supported assets, events, tickets, changes, and runbook references remain distinct and linked. That protected graph follows the approved model path.

After the model responds, Reconstruction resolves supported references within the authorized mapping scope and returns the result to the intended operational destination. The architecture must verify this return path for the actual connectors and workflow. It should not assume that a value is safe or usable merely because it was replaced.

This article does not claim that one representation fits every network tool or topology model. The protected form, connector behavior, and Reconstruction policy must be evaluated against the exact system contracts in use.

Test the operational write, not just the answer

A good answer displayed in a test console is not production proof. The result must reach the correct ticket, incident, change-review record, or operator interface with the expected identity and audit trail.

Run at least these cases:

1. a valid incident with repeated references across all source systems;
2. a missing or stale topology edge;
3. an unrelated change in the same time window;
4. an altered or unknown protected reference;
5. an unauthorized Reconstruction caller;
6. a duplicate delivery or retry after a timeout; and
7. a rollback after a downstream rejection.

Retain a shared test-run ID across the request, retrieval set, protected working version, model response, Reconstruction decision, and final write. Reviewers should be able to reproduce the decision without copying original values into unnecessary logs.

This evidence-first approach is consistent with the NIST Generative AI Profile, which treats AI risk management as work spanning design, development, use, and evaluation rather than as a one-time model check.