Rules, Policies, Models, Intent.

At its Data and Analytics Summit in 2026, Gartner told the AI industry that context is the new critical infrastructure. One of its analysts put a number on the warning: 60 percent of agentic AI projects that rely only on MCP, the Model Context Protocol that connects AI agents to tools and data, will fail by 2028 without semantic foundations underneath, ontologies and knowledge graphs, meaning written so machines can reason over it.

The data world spent 2026 discovering ontologies. Telecom wrote one for network operations years earlier: the TM Forum Intent Ontology, built to carry exactly one kind of meaning, what an operator wants from the network and how the network answers back. This guide is about that idea.

Nine questions, in the order they actually occur to you. One example runs through all of them: your company sells an enterprise customer a premium line between their headquarters and their data center, circuit C-118, with a written promise: one-way delay of at most 20 milliseconds, availability of at least 99.95 percent each month.

Look at your automation for C-118 today. A script reroutes traffic when delay crosses a threshold. A template configures the routers. A controller keeps their settings from drifting. All of it works, and all of it shares one property: every number inside it was written by a person. The threshold, the paths, the timers. Your automation executes decisions your team already made.

That property has a cost that grows with the network. Twice the circuits means twice the thresholds to author, review, and retire when they go stale.

The staleness is the killer: traffic shifts, a road crew cuts a duct, an app misbehaves, and a number that was right in March is wrong in July. Someone has to notice, re-derive, and redeploy it. Multiply by every circuit, cell, and node, and human authorship becomes the scaling bottleneck of operations. Automation made execution cheap. Authorship stayed expensive.

Intent is the industry's name for moving authorship itself into the machine. TM Forum's IG1253 defines it as "the formal specification of all expectations including requirements, goals, and constraints given to a technical system." You state the outcome for C-118, the 20 milliseconds and the 99.95, and the duty to report. The system authors the interior numbers, and re-authors them when they go stale. That re-authoring, without a ticket, is the thing your current automation cannot do.

A word with five owners. Before going further, clear the collisions, because the same word means different things in every industry that uses it:

Only the last one is an object exchanged between accountable parties. Keep the table in mind whenever a speaker changes industry mid-sentence.

And why is telecom the one writing the standard? Structure, in three parts.

An operator never owns both sides of its interfaces: a network is decades of vendors, generations, and domains bolted together, with other operators at every edge, roaming, wholesale, partners, enterprise customers. Companies that own their whole stack keep their contracts internal; telecom can only make things work through public standards, and it carries a century of that muscle, from ITU through 3GPP to TM Forum.

Second, delegation across ownership boundaries needs a contract, and intent is a contract, so the industry's oldest problem already had the right shape.

Third, the economics: events scale with the network while revenue does not, which makes moving authorship into machines a survival question rather than a research interest. The pattern is not unique: the power industry, also multi-owner infrastructure, built its own shared information model, the IEC Common Information Model, a class model with no RDF in it, which is exactly the point. What gets standardized is meaning; the notation is a choice. Industries that share one machine across many owners end up standardizing meaning.

The same intent takes three forms.

As a sentence, the way ETSI's ZSM 011 catalogs them ("Ensure that the end-to-end latency of user in network slice N2 < 10 ms" is a real example from its Table A-1):

"For circuit C-118, keep one-way delay at or under 20 ms and monthly availability at or above 99.95 percent. Report compliance, and tell me the moment you cannot keep the promise."

As a formal object, the TM Forum way (TR290). The language is TURTLE, a text syntax for RDF, the same family of notation the semantic web uses, chosen so machines can reason over it. Simplified and annotated:

ex:PremiumLineIntent  a  icm:Intent ;
    log:allOf ( ex:E1 ex:E2 ) .                    # both expectations must hold

ex:E1  a  icm:PropertyExpectation ;                # a measurable requirement
    icm:target   ex:CircuitC118 ;                  # what it applies to
    quan:atMost  ( ex:onewayDelay "20 ms" ) .      # the outcome number

ex:E2  a  icm:ReportingExpectation ;               # reporting is part of the intent
    icm:reportDestination  ex:ServiceOwner ;       # who gets told
    icm:reportTriggers ( imo:Degrades imo:Complies ) .  # and when

Reading the notation, in ninety seconds. RDF is the Resource Description Framework, a W3C standard that writes all knowledge as three-part sentences: subject, verb, object. "This intent (subject) targets (verb) circuit C-118 (object)." Machines can chain such sentences and reason over them, which is why TM Forum chose it. TURTLE is short for Terse RDF Triple Language: a compact text syntax for writing those sentences, the way .ttl files store them. So TURTLE is a syntax for RDF, the way handwriting is a way of putting down language. JSON-LD carries the same sentences in JSON.

The word before each colon is a prefix, and each prefix names the vocabulary a term comes from. Declared once at the top of the file, they let one intent mix vocabularies from different sources without collision. TM Forum calls this model federation:

Read the example again with the table beside it. Every line is now a plain sentence: this intent requires both expectations; expectation one targets your circuit and caps one-way delay at 20 ms; expectation two names who gets reports and on which events. The notation stops being frightening the moment you see it is grammar, three-part sentences with labeled vocabularies.

Do you have to write this? No. The pipeline has two translations, and you sit above both:

A person states the outcome in words. An intent interpreter, today typically built on a large language model, produces the formal object, and you confirm it. From there down, machines exchange the formal object directly and the handler turns it into control information, the concrete numbers the network equipment and software run on. Question 4 returns to who does which step.

As an API payload. TMF921, the Intent Management API, carries that formal expression inside a REST call: create the intent, update it, remove it, receive reports. Other standards bodies encode the same idea their own way: 3GPP TS 28.312 has its own model, and JSON-LD or YAML servings exist. All of these carry the same object. If a vendor shows you an "intent file" that is a list of device settings, you are looking at configuration wearing a costume; the sections below give you the tests.

Take the one number your team touches most on C-118, the reroute trigger, and walk it through every layer you own. The promise is 20; your automation acts at 18 to leave a margin.

Read the last column downward: your numbers retreat toward the outcome, layer by layer, until only the promise itself is yours. That retreat is the whole subject. Each layer keeps its own engines; intent sits on top and re-tunes them.

One more thing intent is different from: your SLA. The SLA is the paper contract with the customer, penalties included. The intent is the machine-held version of its objective, alive inside the operation, pursued and reported on continuously until you remove it.

Why the configuration row sits oddly. Four of these rows name a way of deciding. Configuration names a state you declared, so it decides nothing by itself. What acts is the reconciler, the loop comparing actual against declared and closing the gap, and its logic is rule-grade: if actual differs from declared, apply the difference. That is why configuration carries no autonomy score of its own. Score the reconciler, not the file.

The controller choosing its own steps is real delegation, worth having, and it stops at method. It picks ordering, retries, and error handling. It never picks the target, and it cannot notice that the target has gone wrong. Change the world so your declared state is now the wrong state, and a reconciler will work hard to restore it, because it holds no objective to evaluate the target against.

Is declarative configuration an early form of intent, missing only negotiation? It shares the declarative form, which is why the two get confused. What separates them is the referent. Configuration declares the desired state of resources, naming the interfaces, paths, and parameter values. Intent declares the desired state of an outcome and stays free of the resources that deliver it. Because configuration names the resources, nothing is left for the machine to work out. Adding negotiation to a configuration system produces a configuration system that argues; the missing piece is the freedom to choose the resources, not the ability to haggle over them.

The pocket test: whose number is it? If the machine must honor your number literally, you are in the first three rows. If the machine writes its own interior numbers to keep your outcome true, you have reached intent.

TM Forum gives the two roles names. The intent owner states the outcome and receives reports. The intent handler accepts the intent, operates the stages, authors the interior numbers, and reports back. For C-118, the service owner's function owns the intent; the transport domain's management function handles it.

Three facts about the roles surprise people.

First, both are usually software: an owner function hands intents to a handler function, and that handler can itself own smaller intents it passes further down, so intents cascade machine-to-machine through the layers.

Second, one function can hold both roles at once, handler of what arrives from above, owner of what it sends below.

Third, humans still write intents at the top, and increasingly they write them in plain language: IG1253 defines an intent interpreter at the edge that turns human words into the formal object. Large language models are the first interpreters good enough for open-ended phrasing, which is why this topic became practical recently.

Accountability does not cascade away. When an intent-driven change breaks a service, the trail runs up the chain of owners to the organization, and inside it a person, who set the outcome and the bounds. The machine authored the interior numbers; a person always owns the objective.

Because reporting is part of the intent itself, and in the TM Forum interface it is mandatory: the procedures an owner and handler must support are set the intent, remove it, and report. A handler that cannot report is not a handler.

A report differs from a dashboard. Your dashboard shows measurements, and a human decides whether they are fine. An intent report is a verdict against the objective, delivered by the party responsible for it: complies, degrades, or cannot be met, with the reason attached. Morning report for C-118: "20 ms held all night. One reroute at 02:14. Margin currently 7 ms." Each expectation in the formal object gets its own true-or-false result, so the verdict is computable, and auditable, down to the clause.

The delay promise is managed with a margin; the availability promise is managed as a budget, and it makes a second good example of control information. A monthly availability of 99.95 percent allows about 21 minutes and 54 seconds of downtime. The handler tracks the burn: after an 8-minute outage on the 10th, 14 minutes remain for the month, and a well-built handler turns conservative, widening margins, preferring stability over cost, deferring risky reroutes, because the budget is nearly spent. The 99.95 is yours. The budget arithmetic, the burn rate, and the changed appetite for risk are all interior numbers the handler authors from it.

A digger cuts the duct, and every remaining path to the data center measures 24 ms. Your script-era automation would either flap between bad paths or go silent. A handler holds an objective, so it must speak: "Cannot meet 20 ms; best achievable 24 until the repair completes; estimated 6 hours."

The standard also allows negotiation. The owner can probe feasibility before setting an intent, and the handler can propose the best intent it can honor: hold 24 ms at full availability, or 20 ms with a risk of brief outages. The owner picks, perhaps automatically by its own logic, perhaps by waking a person for a commercial call, since 24 ms breaches a paid promise. Degradation arrives labeled and priced instead of discovered by the customer.

Cannot-be-met is one failure. The one operators actually fear is harmful-but-authorized: at 03:00 the handler finds a cheaper compliant path through a link your change calendar says is under maintenance, or reroutes so aggressively that a hundred other circuits wobble.

The answer is the bounds row from question 3, now doing its real job. Never route via country Z. Never touch nodes inside a maintenance window. Never move more than N circuits per action. These are fences you author and the handler cannot cross, whatever its interior numbers say. In TM Forum's model they ride inside the intent as constraints, with extensions for priority between competing intents (TR291K) and for the business value of partial fulfillment (TR291I).

A vocabulary note that prevents a common muddle: daily speech calls these fences "policies." IG1253 reserves the word policy for if-this-then-that rules. This guide says bounds for the fences and rules for the if-then form, and you should ask any vendor which of the two they mean when they say policy.

And control returns two ways. Tighten the bounds, which the handler must obey on its next decision. Or remove the intent: an intent persists until its owner removes it, which means the off switch is, by definition, in your hand.

Ask for two demonstrations on their own system, live.

First: miss the outcome. Degrade the test network until the objective fails, and watch whether the product re-derives its actions on its own, or waits for a human to edit something. Second: show the report where the product itself says it cannot meet the objective, with the reason. IG1253 states an intent is not a configuration template, and reporting is mandatory; a template-pusher with an intent label fails both demonstrations in the first ten minutes.

Then one question that needs no lab: "Show me the change record of the last threshold this product moved in production. What triggered the change, a ticket or the system?" A ticket means the numbers are still yours, whatever the brochure says.

Small, and with what you have. Pick one service whose outcome already has a number attached, a premium circuit like C-118, a top-tier customer's availability target. Write its intent as a sentence, the question 2 form, with the report clause included. You now have your first artifact, and ZSM 011's Table A-1 is a free catalog of phrasings.

Then run the question 8 audit on your own operation: for that one service, list the interior numbers, the margins, the thresholds, the path preferences, and mark who last changed each one and what triggered the change. The marks show you exactly where authorship sits today, and therefore what a handler would have to take over. When you want to touch the real interface, TMF921 v5.0 ships with a reference implementation you can stand up and send that first intent to.

The distance between your sentence and your marked-up list is your actual road to intent, measured on your own network, in an afternoon.

Three questions from practitioners deserve more than the expert corner's four lines. They are the ones that decide whether this model survives contact with your OSS.

The handler's loop is finer-grained than watch-analyze-decide-act. Operators break it into stages, and every stage consumes two different things that both get called "policy" in daily speech.

The working logic is the engine that performs the stage: a rule, a policy tree, or a model, built by people, scored on the engine ladder. The governing parameters are the control information fed to that engine: targets, margins, bounds, priorities. The intent handler authors the second kind. For C-118:

Two rows deserve a flag. Execution verification (the last row) confirms the action applied and held: one action, one check. Intent fulfillment is a different judgment: is the 20 ms promise true, continuously, reported to the owner. A change can verify perfectly while the intent degrades, and vendors blur the two constantly.

And a third kind of policy exists that this table deliberately excludes: product policies inside your OSS and BSS applications, approval workflows, data retention rules, subscriber policy in the policy server, security hardening baselines. They are configuration of software products. They enter an autonomy assessment only where they sit inside the operational loop of the scenario being scored. A retention rule never touches the loop; a change-approval workflow sits directly on the execute stage and therefore counts. The test is the same as always: is this artifact part of who watches, analyzes, decides, or acts for this scenario?

The architecture behind question 4's cascade has names, and they come from TM Forum's IG1218 and IG1251. Operations run as four nested closed loops: a resource loop inside each autonomous domain, a service loop across domains, a business loop above it, and a user loop that is the main thread running through all three, the loop of loops. Intents are the messages between them, and each layer holds its own: business intent (revenue, SLA commitments, experience), service intent (connectivity, latency, availability), resource intent (per-domain performance targets).

The interfaces have labels you will meet in architecture reviews. I1 connects consumers to business operations, and this is where the user's intent enters, at the top. I2 connects business to service operations. I3 connects service to resource operations. F1, F2, and F3 run horizontally, federating peer autonomous domains at each layer. That is how your own home broadband and mobile broadband domains hold one customer outcome between them when neither can give the other orders. The same points carry federation with a partner's domains, which the level definitions reserve for the top rung. The same intent interface, TMF921, is specified at all six points, so the grammar stays constant at every boundary.

For C-118 the cascade reads: the enterprise customer's need enters at I1. The business layer holds the contract as a business intent and passes a service intent over I2: 20 ms, 99.95, circuit C-118. The service layer decomposes it over I3 into resource intents per domain: the metro domain holds its delay share, the long-haul domain holds its share. If the circuit crosses into a partner's network, F-interfaces carry the peer-to-peer piece. Reports flow back up the same points, so the customer-facing verdict at I1 is composed from verdicts below.

Every document cited in this guide was first written before the generative AI wave: the levels framework in 2019, the intent guide and ontology from 2020 onward, the 3GPP model in 2022. The technical architecture, IG1230, went to production on 7 November 2022, the same month ChatGPT appeared. So a fair question, and one experts ask sharply: did the wave break the definitions?

No, and the reason is the thread of this whole guide: the definitions were written about who, never about how. Levels measure delegation. Intent is a relationship between an owner and a handler. A new mechanism, however powerful, slots into a who-frame without moving it.

The evidence is already published: TM Forum absorbed agents through IG1251D (agent architecture) and IG1251E (multi-agent architectures) without redefining intent. The AI world's new vocabulary maps onto components operations people already had names for:

What is genuinely new is the generality of the mechanism: open-ended language in, generated logic out. That raises how much a handler can take on. It moves nothing in the contract, and the contract is what the standards define.

TM Forum's level table (IG1230) tracks five task families per level: execution, awareness, analysis, decision, and intent/experience, that last one defined as translating intent into operations and evaluating fulfillment. Person and system share the intent/experience work at level 4; the system carries it alone at level 5. That single cell answers several arguments at once.

An intent object also has a lifecycle (IG1253): detect the need for it, investigate feasibility, define it formally, distribute it, operate it.

Today, at scenario-scope autonomy (what IG1401 calls Level 4 Phase 1, and what current assessment tools measure), the split runs: a person detects the need and drives the investigation; definition is shared, an interpreter drafts and the person confirms; distribution and operation are system work, the API call and the handler's loop. This is why assessment questionnaires still name a person in the network operations center or the service operations center as the one expressing the intent per scenario: at Phase 1, that is accurate, and each scenario receives its intent separately.

Phase 2 is autonomy across scenarios under an intent contract: the business-to-service-to-resource cascade of the previous section runs machine to machine, and the human sharing concentrates at the top of the user loop, stating outcomes and judging fulfillment. No published assessment instrument measures Phase 2 yet, so treat any Phase 2 claim as currently unverifiable by questionnaire, and ask for the cascade's change records instead.

At level 5 the table's intent/experience cell reads system alone, and notice that it is the only cell that changes between level 4 and level 5: intent handling is the last task family to be delegated, and its full delegation, across all scenarios and domains, is what level 5 is. Nobody authors formal expressions or evaluates fulfillment by hand, and the system derives intents from business goals and experience signals. Two things survive even there. The formal intent layer stays, machines still exchange RDF objects between loops. And the outcome itself stays human: somebody still decides that 20 milliseconds is what the customer is owed. What level 5 removes is the human's hand in translation and evaluation, never the human's ownership of the destination. One more consequence, further out: the scenario map itself, the named partitions like RAN fault management or home broadband assurance, stops being the structure work is organized by, since the system decomposes outcomes into whatever loops a situation needs, and it remains what it always was for humans, the lens for accountability and assessment. The standard still defines level 5 on that map, as all scenarios; no one has demonstrated a loop forming around a scenario nobody enumerated, and any claim of it today is a claim without an instrument.

Every layer has numbers and thresholds, so what really separates them? The role of the number, and above all its author. Trigger, setting, fence, or outcome: ask who wrote it and who rewrites it when it goes stale. The change record answers, and it settles arguments no architecture diagram can.

Does design time count, or only runtime? Only runtime, and for a structural reason: every system that ever ran was designed by humans, so counting design time would score everything at zero. Autonomy is the migration of authorship into runtime. Whatever must be finished before deployment is precisely the part that is not autonomous yet. The workplace parallel: you do not measure an employee's autonomy by who trained them, you measure what they decide without calling you.

An AI agent wrote our rules. Is that autonomy? Score the authoring as a task: who triggers it, who performs it, who supervises it. An agent a person prompts in a session made authoring cheaper; the person still gates every change. An agent in production that detects a stale rule, rewrites it within bounds, deploys, and reports has moved authorship into runtime. An agent you summon is a tool. An agent that summons itself is an operator.

Can a deterministic translator, with no AI at all, be an intent handler? Yes. A template-based decomposer that turns a formal intent into concrete settings is a fixed function producing new control objects, the way a compiler is a fixed program producing new programs. Its limit is narrowness, the intents its templates anticipated, and that is a coverage problem rather than a logic problem.

Where do SLO and SLI fit? An SLO (service level objective) is the internal target your team derives from the SLA, usually tighter. An SLI (service level indicator) is the measured value itself. An SLO commonly becomes one expectation inside an intent, and reports cite SLIs as evidence. The intent can carry more than the SLO: constraints, delivery requirements, reporting duties.

"An agent loops toward a goal, so an agent has intent by definition." A goal inside a prompt is one party's internal state. An intent is an interface object between two parties: formally expressed, negotiable, reported on by obligation, removable by its owner. An agent can hold an intent as handler or issue one as owner; looping toward a goal makes it neither. The audit is the payload: when a vendor says "agents, A2A, and we support TMF921," ask to see the intent payload and the report it produced. Today real machine-readable intent payloads live almost entirely at the resource layer, through the 3GPP interfaces, and the business layer is nearly empty. The first business-layer extension to the TM Forum Intent Ontology, the Business Intent Extension Model, with worked TMF921 payloads carrying business priority, came out of a 2026 TM Forum catalyst and sits with the Intent workstream for review. A vendor that cannot produce the payload is paying the standard lip service.

What happens if we skip RDF and the ontology altogether? The contract survives: 3GPP TS 28.312 carries expectations and reporting in a plain class model. What you lose is what RDF was chosen for. Conflict detection between intents becomes hand-coded per case instead of derived. Cross-domain references need identifier mapping tables instead of global IRIs, and mapping tables drift. Extensions become schema forks that every party must version together. And meaning moves out of the payload into documentation and adapter code, so with N parties you approach N squared bespoke integrations. Skipping the ontology relocates its work into adapters; it never removes the work.

Is the ontology wasted in a single-vendor network? Split the value in two. The contract, outcome plus mandatory report plus negotiation plus removal, pays at any vendor count, because it is about delegation and accountability. The federation layer, RDF and the shared vocabularies, pays at boundaries. If one vendor owns both sides of every interface forever, a proprietary contract carries you. Boundaries arrive uninvited, though: a second vendor, a partner service, an acquisition, a regulator wanting auditable delegation records. And proprietary intent semantics deepen the lock; the standard is also your exit option, priced now rather than under duress.

Can another industry reuse the TM Forum intent stack? By construction, yes. The mandatory core, the Intent Common Model, contains no telecom terms; the base layer is W3C standards; extensions can be created by any organization without TM Forum approval; domain knowledge enters through information models plugged into the federation. A factory's yield expectation reads the same as a circuit's delay expectation. What does not port: the handlers, because fulfillment logic is domain knowledge, and the information models themselves. The ontology travels; the muscle behind it is rebuilt per industry. Check the publication terms of the TIO model files before a commercial port; the TMF921 API itself is Apache 2.0.

How do TIO, RDF, and TURTLE relate, and must I use them? RDF is the sentence form: all knowledge as subject-verb-object triples, a W3C standard. TIO, the TM Forum Intent Ontology, is the dictionary and the grammar written on that form, the terms plus the rules for combining them: the common model of TR290, the TR291 extensions, the management vocabulary. TURTLE and JSON-LD are handwritings that put the same triples on paper. You must use them only when exchanging intents over TMF921, which carries the ontology payload; only the common model is mandatory, every extension optional, and 3GPP TS 28.312 proves the concept survives in a plain class model with no RDF at all. Extensions reach practice as extra vocabularies inside the same object (a utility function on an expectation, a priority on a requirement) and a handler's capability profile (IG1253D) declares which of them it understands before you send.

Where does the human end up? At the top of every chain. Machines play owner and handler toward each other all the way down, and every rung receives its bounds from the rung above. The chain terminates at a person accountable for the outcome. Intent is the rung where the human stops: below it, machines choose; at it, the human speaks.

• Rule (ECA): event, condition, action. When something happens and a condition holds, a pre-written action fires.
• Declarative configuration: a target state a controller continuously enforces on devices, correcting drift.
• Bounds: fences on a machine's choices, authored by people: forbidden paths, load ceilings, maintenance windows.
• Intent owner / intent handler: the role that states the outcome and receives reports / the role that fulfills it and reports back. Both are usually software; one function can play both.
• Intent interpreter: the translator at the edge turning human language into the formal intent object.
• SLA / SLO / SLI: the customer contract with penalties / the internal target derived from it / the measured value itself.
• RDF and TURTLE: the data model and text syntax TM Forum chose for formal intents, so machines can reason over them.
• TMF921: the REST API through which owners and handlers exchange intents and reports.

This guide explains how the published work applies in practice. It does not restate or revise the documents below, which carry the normative text.

• TM Forum IG1253 v1.3.0, Intent in Autonomous Networks. The intent definition, the five properties (declarative, composable, persistent, infrastructure-agnostic, measurable), intent owner and handler, the mandatory set/remove/report procedures and optional negotiation, the intent interpreter, and the statement that an intent is not a configuration template.
• TM Forum TR290 v3.7.0, Intent Common Model. The formal classes behind the TURTLE example: Intent, PropertyExpectation, ReportingExpectation, Target, Context; compliance computed as true-or-false per clause.
• TM Forum TR291K v1.0.0 and TR291I v3.7.0. Priority between competing intents; utility, the business value of partial fulfillment.
• TMF921 v5.0, Intent Management API. The REST interface; the formal expression rides inside it as an ontology-based payload (TURTLE is one serialization).
• ETSI GR ZSM 011 V1.1.1 (2023-02). Table A-1, natural-language intent examples; Annex B, a declarative intent model. Predates LLM-based interpretation.
• 3GPP TS 28.312. The 3GPP model for intent-driven management; IG1253 Appendix B maps TM Forum terms to 3GPP terms.