Know what your network AI can change. Prove whether it should.
AI agents and rApps/xApps can influence routing, network policies, slices and service operations. Individual model checks, access controls and telemetry see only parts of the decision. HAIEC connects source-supported network action paths with telecom entities, native operations, approved authority and evidence to assess consequential changes using deterministic rules.
Follow the network action that carries the business risk.
Choose an operating domain. The view connects possible action paths to telecom evidence and decision authority without claiming every vendor interface is connected.
rApp / xApp policy
Who can publish or change a consequential near-real-time optimization policy?
Slice and QoS changes
Can a change affect another tenant, slice boundary or service objective?
5G Core / SBI
Which network function, route or service relationship can an AI action reach?
Subscriber and charging
Can permitted automation change an account, entitlement or charging state?
A network optimization agent proposes an A1 policy change.
Source and control-plane context can identify a policy-capable route from an application to a protected RIC operation. The source finding motivates an authority question before an operator accepts a change.
The rApp is registered, a source call or policy API exists, and the calling identity can be configured.
What HAIEC can addA source-backed consequential path, relevant approved A1 change scope, effective access and bounded business decision rights.
What requires additional proofA deployed and accepted policy or network change needs native target state and eligible qualified observations, not code scanning alone.
Speak telecom without rebuilding a second assurance engine.
HAIEC adds telecom context to its existing canonical evidence and effect models. It preserves native identity and operation names, recognizes selected network families and leaves unmapped operations open for a qualified business rule.
Typed telecom entities make network evidence identifiable.
Evidence can reference canonical identities for cells, sessions, network slices and functions. Each requires actual native identifiers before a stable entity is resolved.
Source: CellSite / siteId Source: NetworkSlice / sliceId Source: SBI_Transaction / transactionId Resolved identity: deterministic digest of type + native keys Missing required identity: unresolved, never guessed Display name alone: not proof of entity identity
The specific typed entity claim for source-bound identity and replay stability.
What remains distinctA resolved snapshot entity does not prove a live network state, nor is this a full TM Forum SID graph database.
Open the Telecom Entity Reference →Entity families supported by the typed read model
CellSite · NetworkCell · Sector · TrackingArea · UE_Device · UE_Session
NetworkSlice · SliceSubnet · SliceIsolationPolicy · QoS_Flow
NetworkFunction · SBI_Transaction · NRF_Registration · SCP_Route · NF_Communication_Pattern
TransportLink · PacketSession
From baseline to degraded and compromised states, with evidence.
AL0, AL1 and AL2 are declared scenario states. HAIEC compares qualified changes within the stated scenario. It does not infer compromise, attacker intent or root cause simply from the chosen label or timestamp proximity.
Establish the defined reference before comparing change.
Start from explicit scenario binding and relevant source records, not an inferred timeline. A baseline is the comparison basis, not proof every network action is safe.
Open the Public Forensic Example →The stated policy, available entities, declared action context and observed facts within the baseline scope.
What the state label alone cannot answerIt does not prove target-side behavior outside the captured evidence or guarantee the baseline has no findings.
Proof from an actual agentic assurance workshop, with results and limits.
HAIEC's published TM Forum MoDaaS workshop evidence archive records deterministic control tests, policy enforcement observations, forensic findings and qualified monitoring. These results demonstrate methods and specific tested outcomes, not universal carrier deployment or an independently verified competition ranking.
Tokens in C16 assessed satisfied run
Tokens in C16 assessed breach run
C7 original expected event coverage
Manifest-listed paths in public archive
One 60,000-token cap, two defensible outcomes.
The archived register contains a comparable SATISFIED run at 35,559 tokens and NOT_SATISFIED run at 106,829 tokens under the same frozen policy.
Inspect the Original Control Register ↗A source-qualified deterministic pass/breach contrast for a defined usage budget.
What it does not implyThis does not establish that every telecom provider token-ceiling enforcement point works or that the model can never overrun a different budget.
A domain-aware extension of one deterministic assurance platform.
HAIEC reuses its same evidence owners and evaluator while interpreting telecom-specific identities, operations, action relationships and consequences. The six capabilities support independent jobs, not six separate network products.
Identify AI systems, source-capable network endpoints, typed telecom entities and action connections.
Compare applicable network policy and technical source evidence with deterministic controls, then retrieve bounded reports and qualified artifacts.
Govern material choices, inspect connected runtime sources and operate configured customer execution controls where proven.
Specific proof, not unqualified autonomy claims.
What is the difference between telecom semantics and a complete telecom ontology?
HAIEC provides a 17-type read-model for selected network identities and a versioned operation-mapping pack. Both feed its common effect and assurance contracts. It does not include every SID entity, TM Forum API or vendor-specific network control implementation.
How does HAIEC treat ambiguous native telecom operations?
It preserves the original operation. A canonical verb is assigned only where a deterministic mapping exists. An ambiguous reboot or switchover may have a proposed mapping, but remains partial until an applicable business rule is established.
What role do TM Forum ODA, SID and Open APIs play?
They provide open telecom architectural and data interchange references. HAIEC can map qualified native evidence to its canonical assurance model where a supported adapter exists. Standards references do not establish conformance certification or live provider integration.
What can HAIEC examine for rApps and xApps?
Current HAIEC source includes rApp supply-chain, excessive-capability, lifecycle mismatch and A1 policy-integrity detection families. Actual findings depend on supported source visibility, applicable rules and evidence.
Is an AL2 scenario label proof of a security compromise?
No. AL2 is a declared state used to organize a specified forensic example. Claims about cause, attacker behavior or target-side consequence require their own qualified records.
What did the TM Forum 2026 event demonstrate?
The public archive documents a deterministic token-cap pass/breach pair, partial audit coverage, two C9 satisfied assessments, policy enforcement observations, an S2 false-certainty failure, an S3 safe escalation result and a monitored alert-delivery mechanism with declared boundaries.
Does the TM Forum report establish a competition win or organizer certification?
The source establishes a publisher-released, integrity-manifested workshop evidence package. A verified organizer placing, certification and byte-exact organizer upload receipt are separate claims not established by that archive alone.
Does a real telemetry sweep with no findings prove nothing went wrong?
No. In the workshop, 40 real spans were accepted with zero detector findings in the configured condition, while distinct control tests and forensic reconstruction found other issues. Sources and detection rules answer different questions.
Can HAIEC block any O-RAN or 5G network action?
Only configured, authorized and actually integrated execution points can mediate a target. A policy evaluation, source path finding or operator dashboard decision does not by itself establish network-side enforcement.
Can we start with one network AI system?
Yes. An Enterprise POC can focus on one authorized system and consequential question, such as a slice-policy change or network automation action. Exact source access and qualified adapter scope are agreed before an evaluation.
Make your next autonomous network decision defensible.
Start with one AI-managed network action, its approved authority and the evidence that can establish its real scope. Build on your existing TM Forum, O-RAN and network platforms rather than replacing them.
Read the TM Forum event proof.
Explore control tests, observed governance decisions, open gaps and exact evidence sources from the published workshop archive.
Explore the Evidence Archive ↗