User Guide — ANN (Autonomous Network Navigator)

This guide is for anyone who has just gotten access to ANN and is wondering where to start. It describes what the tool does today, in the order you'll actually use it.

What ANN does, and what it doesn't

ANN tools the TM Forum Autonomous Networks maturity journey: it assesses where you stand on high-value scenarios (HVS), generates a progress roadmap, and prepares the evidence pack for a certification request.

ANN is not the TM Forum and does not issue the ANLAV certificate. The tool helps prepare the evidence pack; the TM Forum validates the self-assessment and issues the certificate.

This sentence isn't a legal precaution. It describes exactly where the line sits: ANN helps you measure your maturity and assemble a dossier. Certification itself is a third-party act.

Three distinctions you'll find throughout the interface, because they change the meaning of what you're reading:

Roles and what each one sees

Five roles, with real access boundaries, not just declared ones:

A client-side role (administrator, contributor, auditor) is always confined to its own organization — never a leak into another client organization, even by manipulating a URL. A CEVIA consultant can work across several client engagements in parallel, but only on those they've been explicitly granted, not the whole portfolio.

The path through an assessment

1. Pick a scenario (HVS)

Assessments → a scenario marked "Start assessment". Each scenario represents a TM Forum High Value Scenario: RAN fault management, service continuity, etc. Only genuinely tooled scenarios show this button — see "The HVS (High-Value Scenario) catalogue" below for the others (HVS: High-Value Scenario).

2. The questionnaire, by sub-scenario and IAADE task

The questionnaire is organized as tabs, one per sub-scenario. Each tab shows a progress badge (green at 100%, grey otherwise) and lists the tasks of the IAADE cycle: Intent, Awareness, Analysis, Decision, Execution.

For each task, you pick a maturity level from L0 to L5. One click is enough: the answer saves automatically, no separate "Save" button (the text "Saving..." then "Saved" confirms it). A free-text comment is available under each task, also autosaved a few moments after you stop typing.

A "See the 6 maturity levels (L0-L5)" disclosure recalls the explicit criterion for each level, in case the line between an L2 and an L3, for instance, isn't obvious.

Under a task's name, chips show, when the reference framework knows them, the task's reference standard (for example 3GPP TS 28.532 or TMF642). Hover over a chip, or focus it with the keyboard, to read its scope. A chip marked "CEVIA proposal" is a mapping proposed by CEVIA that does not yet come from a sourced annex: it is not an official TM Forum table. Chips never change the score, and most scenarios do not have any yet.

3. AI-assisted pre-fill

Pre-fill with AI, available per sub-scenario. You paste an excerpt of an operational document (alarm export, network policy, audit report...); the AI proposes an L0-L5 level per task, with a short justification citing a concrete element from the excerpt.

Rather than pasting text by hand, you can also import one or more files — the "Import files" button, or drag and drop directly onto the field. Accepted formats: .md, .txt, .csv and .log (text files only, 2 MB maximum per file) — .csv in particular covers alarm or counter exports produced by active network equipment, a common input format for this use case. Selecting several files at once combines their content automatically (each clearly identified by its name), and the AI takes the whole set of evidence into account for its suggestions, not just the first file. A file in an unsupported format (an image, for instance) is flagged clearly rather than being inserted as-is into the field.

Every suggestion carries the label "AI suggestion — to validate" until confirmed. It counts toward no score before that — clicking Validate, or choosing a level yourself (which counts as implicit validation), brings it into the calculation.

If no MISTRAL_API_KEY is configured for your deployment, or if the call fails, ANN falls back to an offline demo mode: the suggestion stays purely indicative, and the justification says so explicitly. A cap of 50 AI pre-fills per day per organization guards against disproportionate use; past that, ANN invites you to enter the remaining levels manually for the rest of the day.

4. Evidence

Under each task, you can attach one or more pieces of evidence, typed as Declarative or Technical — the distinction matters for the coverage calculation (see "Preparing for ANLAV certification"). Attaching evidence requires that a level has already been chosen for the task.

The type menu, next to the add button, is pre-selected to the type recommended by the task's "Concrete example" box (you can still change it). If the file you attach is already on the same task (same content), ANN tells you — "This file is already attached to this task" — and offers to change the type of the existing evidence instead of uploading it again. The same file remains possible on another task.

Fixing an upload mistake. On an evidence row:

• Change type (declarative ↔ technical). If the evidence was validated, it goes back to pending validation: its weight in the coverage changes.
• Remove, with a mandatory reason. The evidence is never deleted: it is removed — the file and its history are kept. It no longer counts in the coverage rate or the evidence coverage, and is hidden by default. The Show removed evidence button (visible when there is any) displays it, with its reason, to administrators, CEVIA roles and auditors (read-only).

Who can do what: the client administrator and the CEVIA roles can validate, reject, change the type of, or remove any evidence. A contributor can change the type of, or remove, their own evidence while it is pending. An auditor cannot modify anything. Every action is logged, with the old and the new value.

5. The score and the export

The assessment's overall score (Lbase/Lextra/Lscenario, IG1252 methodology) appears on the Results screen, with an IAADE maturity radar by category and the list of gaps per sub-scenario. As long as no sub-scenario is complete, the overall score shows "Not assessed" rather than a misleading number.

Mark as complete appears once 100% of tasks have been answered, to formally close the assessment. A PDF export (scoring summary and gap analysis) is available from the Results screen.

Data Request Pack. For the scenarios whose reference framework describes them (today: Gestion des pannes RAN, GB1523A), the "Data Request Pack" button on the Results screen opens the list of data to request from the operator to start collecting evidence: code, data item, IAADE categories, tasks concerned, likely source, standard interfaces, granularity and sensitivity, plus the "What we do not ask for" block (no subscriber data). The "X / N via a standard interface" counter is computed from the list. It can be exported as PDF or XLSX, with the same content as the screen and CEVIA's legal notices, by the client administrator, the auditor and the CEVIA consultant; the contributor can read it but cannot export it. Every export is logged. The content of the list is written in French, whatever the interface language.

6. Comparing several scenarios: cross-cutting capabilities

The Cross-HVS Comparison (HVS: High-Value Scenario) screen offers, after the maturity matrix, the compared radar and the evidence guide, a Cross-cutting capabilities tab. It answers a simple question: which IAADE categories hold back several scenarios at once? For each scenario (HVS), the tab reads a single assessment: the most recent completed one, otherwise the most recent incomplete one, flagged in that case by the banner "Incomplete assessment — partial values". A draft with no answer at all is listed as "Not assessed". For each IAADE category, the table gives the number of scenarios where it is the bottleneck (the category with the lowest average; in case of a tie every tied category counts, so the total can exceed the number of scenarios), its average, and the simulated gain if all its answers gained one level (capped at L5). A zero gain is normal: no gain until the bottleneck is lifted, because a scenario's level is capped by its weakest capability (IG1252 rule). Everything computed here is labelled "CEVIA method" and the simulation "Simulation — not measured": nothing is saved and no score is modified. The tab is read-only for every role.

7. Closed loops and their governance

The TM Forum Autonomous Networks framework describes four closed loops: User, Business, Service and Resource (IG1218 v3.0.0, § 4.1). ANN sets them against your scenarios (HVS, High-Value Scenario) to answer two questions: where does each loop stand? and how far is autonomy authorised there?

The loop map of an assessment. On the Results screen, the "Loop map" button (shown only for scenarios whose reference definition attaches sub-scenarios to a loop) opens four cards. Each gives the loop's maturity, its "share of the HVS score: X%", its bottleneck (the weakest IAADE category), the attached sub-scenarios and the governance defined. The (i) icon next to the loop's name shows its definition, reworded by CEVIA, with the IG1218 reference. A loop with no attached sub-scenario shows "Not covered by this HVS": never a 0. A loop's maturity is the average of the scores of its attached sub-scenarios, weighted by their renormalised weights. Only complete sub-scenarios count; when some are missing, the banner "Incomplete assessment — partial values" says so, and when none is complete the card shows "Not measurable". This is a CEVIA method (the TM Forum defines no "per loop" formula): when everything is complete, the sum of "share of score × maturity" over the loops gives back exactly the scenario's IG1252 score. Nothing is saved and no score is changed.

The organisation view. The "Closed loops" menu entry (just before "ANSP strategy") opens, for each loop, the scenarios that contribute to it and its average maturity: the simple average of the per-scenario maturities (every scenario weighs the same), computed on one assessment per scenario (the most recent completed one, otherwise the most recent non-completed one). The User and Business loops show "Not covered: no governance can be defined until an HVS contributes to this loop".

Governance. For each (scenario, domain) pair of a covered loop, the organisation can define: the maximum authorised autonomy (L0 to L5), a human validation point (who validates, when, before which action) and guardrails (emergency stop / intervention capability, automatic-action thresholds, rollback, logging), each with its status: In place, Partial, To confirm or Absent. Nothing is pre-filled: until it is entered, autonomy shows "Not defined". Badges say where each field comes from: "Source: IG1230 v1.1.0" for the human validation point and the emergency stop, "CEVIA proposal" for the rest (to be validated; this is not an official TM Forum requirement).

The "above authorised" alert. When a maximum autonomy is defined, ANN lists the loop's tasks whose observed level (validated answers) exceeds it. The alert is computed task by task, never on the average: an average under the limit can hide tasks above it.

Who can do what. Every role can view the loops and their governance. The client administrator, the CEVIA consultant and the CEVIA administrator can change it ("Edit" button); the contributor and the auditor do not see that button. Every change is logged with the old and the new value. If someone else changed the same governance in the meantime, ANN refuses the save and asks you to reload the page, so that their work is not overwritten.

The ANSP strategy (planning the network's autonomy)

The ANSP (AN Strategic Planning) is the TM Forum practice used to define an operator's autonomy strategy. The Autonomous Networks framework (IG1218 v3.0.0, § 4.4) builds it on four key elements: the KEIs (effectiveness indicators), the autonomy levels, the target architecture and the AN Map (the landscape of scenarios the HVS, High-Value Scenarios, come from). ANN offers the "ANSP strategy" menu entry (the last one): you prepare the strategy, submit it, and the operator's administrator approves it.

Where the fields come from. The TM Forum describes the structure of a Level 4 AN strategic plan in the IG1443 white paper (p. 29): vision and value objectives over 3-5 years, list of HVS and a roadmap with annual objectives, investment budget. It provides no input template and defines no formula. Each ANN field therefore shows its provenance: "IG1443 p. 29" when it follows that structure (ambition, value objectives over 3-5 years, investment budget, a domain's list of HVS, a milestone's value objective); "CEVIA method, inspired by IG1443 p. 29" for an HVS's numeric target level (IG1443 describes value objectives, not a numeric level per horizon); "CEVIA method" for what CEVIA adds (observed level per domain, level targets per domain, sponsor, committee date, approval workflow). The detailed strategic planning methodology (IG1433) is not part of ANN.

The four steps. They are built on the four key elements: 1. Levels, 2. KEIs, 3. Scenarios (AN Map, HVS — High-Value Scenarios) and 4. Trajectory are available; The target architecture, the fourth key element, is available: one block per domain, under step 1 (IG1251 and IG1230 references).

The vision and the sponsor (before the steps). The first block of the screen, placed before "The four steps": it is not part of step 1. It contains the ambition, the value objectives over 3-5 years, the sponsor (CTO or equivalent), the committee date and the investment budget (a note). Clicking "Save" shows "Saved." next to the button, as for targets and milestones.

Step 1, levels per domain. One block per domain of the HVS catalogue (Multi-service, Fixe, Entreprise, Mobile, IoT, Core, Transport, IP: ANN's labels, with the exact AN Map term and its reference in a tooltip ("i"), IG1339 v2.4.0 §2.1, fig. 2.1-2 p. 11; table 2.2-1 p. 12; for example "Mobile" matches "Wireless"). A domain with no available HVS stays visible, "Not covered" (Fixe, Entreprise, IoT and Transport today); Business and User stay on the closed-loops screen:

• the observed level: calculated, never typed in. It is the simple average of the levels of the domain's assessed HVS (tooltip "Simple average of the domain's assessed HVS (CEVIA method)"; the "n of N HVS assessed" indicator says how many of the available HVS contribute) (for each HVS: average of its complete sub-scenarios, weighted by their renormalised weights), on each HVS's retained assessment (the most recent completed one, otherwise the most recent incomplete one, flagged "Incomplete assessment — partial values"). With no usable assessment: "Not measurable", never a 0. An unvalidated AI suggestion never enters it;
• the level targets for Year 1, Year 2 and Year 3 (12, 24 and 36 months in the tooltip), from 0 to 5 in steps of 0.5. The Year 1 ≤ Year 2 ≤ Year 3 order is mandatory (saving is refused otherwise, with the message "The order Year 1 ≤ Year 2 ≤ Year 3 is required.", with no technical field name). If all three targets are "Not set" while the domain has none saved, "Save targets" answers "Nothing to save" (and does not show "Saved."); clearing targets that are already saved remains possible. A target below the measured level only raises a warning, never a refusal (an operator may aim to hold a level);
• the domain's HVS (High-Value Scenarios), each with its milestones per year: a value objective (the expected benefit, 280 characters) and a numeric target level, chosen in the "Level targeted by this milestone" menu (distinct from the domain targets, Year 1, 2 and 3, at the top of the block). Nothing is pre-filled. A milestone can be removed ("Remove milestone") while the plan is a draft: the removal is logical, the milestone disappears from the screen but is kept and traced, and a revision does not carry it over. Core Network Stability is listed under Core with the "CEVIA classification" badge: absent from the AN Map and from table 2.2-1 of IG1339, it is classified by CEVIA under the Core domain (close to GB1523B) and is never presented as a TM Forum standard. A domain key from an older plan that is no longer in the catalogue (RAN, for example) shows as "Unrecognised domain", read-only, with nothing deleted. The ANSP never writes to the IG1252 score: it complements it, it does not change it.

Step 2, effectiveness indicators (KEIs). You choose the plan's indicators, each with its baseline and target (optional: "Not set"), optionally linked to an HVS (High-Value Scenario); at most 30 indicators per plan (CEVIA limit) and one per indicator / HVS pair. The measurement is read, never typed: "No measurement" is shown until data has been imported (collection arrives in a later version). Until the full reference is activated, only indicators cited by a public document are offered: MTTR (Mean Time to Recovery) and FHOR, with their source; the rule is the same for every role, CEVIA accounts included. Like the rest of the plan, step 2 can only be edited in a draft, by editor roles; in a submitted, approved or archived plan, with an inactive subscription or with a read-only role, it is shown without buttons, with the reason. "Revise" carries the indicators over, and the ANSP PDF includes the section.

The indicator reference. The "Indicators" menu entry (the last one) opens the reference. Until it is activated, it shows MTTR and FHOR (abbreviation, full name, public source) and the message "Full reference available": ANN includes the full TM Forum AN indicator reference, and full display is available upon activation. It shows nothing more, to any role. Once the full reference is activated, every screen that shows it carries the TM Forum copyright notice and a link to the "Notice" page of the source standard. Activation is a CEVIA decision (a CEVIA administrator, recorded in the audit log), never one taken by a client account.

Step 3, priority scenarios. You choose the scenarios to tackle first, ranked by rank (1, 2, 3…). There are two kinds:

• an HVS whose definition is loaded in ANN (a "Coming soon" HVS is not offered), shown with its domain and the observed level of its retained assessment (read, never typed in; "No assessment" when there is none);
• a custom scenario (free name, 3 to 120 characters), always marked "Outside the TM Forum reference — not certifiable for ANLAV": it is not counted among the HVS, is not certifiable and has no domain in this version.

For each scenario you choose a value and a feasibility, from 1 to 5: this is a CEVIA method (the TM Forum defines neither a formula nor a prioritisation grid); the value × feasibility product is only an aid. The rank is the one you set: "Move up" and "Move down" shift it by one step; "Propose the order" replaces it (after confirmation) with the order value × feasibility descending, then value, then name. A plan holds from 1 to 12 scenarios, and an HVS (High-Value Scenario) appears only once. Nothing is added automatically: value and feasibility are always entered by you. A scenario can be removed while the plan is a draft (logical removal: it disappears from the screen with its intents but is kept and traced).

Each scenario carries its intents (objectives expressed as intents; at most 20 per scenario: a CEVIA limit, a safeguard of the screen, not a TM Forum rule):

• a layer: Business, Service or Resource (the three operational layers of IG1251, p. 19);
• a statement of 10 to 500 characters, with no person's name and no customer data (it is never written to the audit log);
• linked tasks of the HVS (High-Value Scenario): the intent's closed loop is deduced from these tasks (the HVS's "sub-scenario → loop" mapping), it is never typed in; an intent with no linked task is "Not attached to a loop" (never a zero or a default loop); a custom scenario has no tasks;
• a "Target KEI" field, chosen among the indicators of step 2 ("None" by default; the field stays inactive while step 2 has no indicator). Removing the last row of a KEI from step 2 unlinks the intents that targeted it.

An intent has a status: Open, then Achieved (declared), then Achieved (evidenced); it can also be Abandoned (from "Open" only). "Achieved (evidenced)" and "Abandoned" are final. A declaration made by mistake is corrected with "Cancel the declaration": the intent goes back to "Open" (same roles and plan states as for advancing, traced without any text); the statement, the layer and the linked tasks can only be changed on a draft, never on an approved plan. "Achieved (evidenced)" requires at least one validated piece of evidence on a linked task, in the retained assessment of the HVS (High-Value Scenario). Advancing an intent's status is the only change allowed on an approved plan: it goes through dedicated buttons, reserved for the roles that prepare the ANSP (with an active subscription), it creates no new version, never changes the statement and is traced without any text; every change is visible in the history (date, time, author, old → new status) and logged. On a submitted or archived plan, nothing can be changed. An achieved intent never enters the IG1252 score: the observed level stays that of the assessment, with a "Suggest a reassessment" link to the HVS's results.

Step 4, trajectory in stages. You split the trajectory into 1 to 8 stages: a label, a start month and an end month (from 0 to 60, the start before the end) and the stage's objective. Stages follow one another without overlap (a stage may start in the month the previous one ends): saving is refused otherwise. While there is no stage, ANN suggests three rows "Year 1, 2 and 3" (0-12, 12-24 and 24-36 months; these default labels are shown in the language of the screen or of the export, a label you type stays as typed); nothing is saved until you write the objectives and save. A stage's target level is never typed in and is not an average: it is the list of the per-domain targets of step 1 for the year that contains the stage's end (for example "RAN L3.5 · Core L3"; a domain without a target is not listed), or "—" when no domain has a target or the stage ends after 36 months. Provenance: "CEVIA method, inspired by IG1443 p. 29" (the split into months is a CEVIA method).

The target architecture. In each domain of step 1, a collapsible block "Target architecture of the … domain" (chevron and "Show" / "Hide", by keyboard as well as by mouse) describes the intended architecture. It follows the structure of the IG1251 reference architecture and the IG1230 People / Systems reading; the operator fills it in, and each field shows its provenance:

• the operational layers covered: Business, Service, Resource (IG1251, p. 19);
• the domain type (atomic or composite) and its federation with other domains (IG1251, p. 21);
• the domain's boundary, that is the autonomous platforms included (IG1251, p. 19-20 for the definition; the field itself is a CEVIA method);
• the domain's functional blocks (IG1251, Tables 7 and 8, p. 23-24): Intent Management, Domain Intelligence, Knowledge Governance, Knowledge Optimization, the local knowledge base, Domain Control Loop Management (it carries the domain's closed loop: awareness, analysis, decision, execution), Awareness, Analysis, Decision and Execution, then, if the Resource layer is covered, Network Element and Site Intelligence. Each block has a declarative status: in place, to build (with year 1, 2 or 3) or out of scope ("CEVIA method, inspired by IG1443 p. 29");
• the Knowledge & Intelligence platform (IG1251, Table 9, p. 24-25): Application Catalog, Model Training, the K&I knowledge base (not to be confused with the local knowledge base) and Data Services, with the same status;
• the reference points that concern the ticked layers (IG1251, Table 10, p. 25-26): I1, I2 and I3, intent-driven interactions that are required; F1, F2 and F3, intents that are possible to federate domains (optional); K1, K2 and K3, with no intent: interfaces for collecting training samples and delivering AI models between the layer concerned and the K&I platform ("interface in place", "interface planned" with the year, or "no"). The block also reminds, for information, that the Intent Management API Suite (TMF921) applies to points I1 to I3 and F1 to F3 (IG1251, Table 11, p. 26);
• the expected People / Systems split, read and never typed in (IG1230 v1.1.0, §4.3, Table 4, p. 41): for each year's level target in step 1, ANN shows for Execution, Awareness, Analysis, Decision and Intent/Experience whether the task is a matter for people (P), systems (S) or both (P/S), with the "Applicability" row. A whole-number target reads its column; a half-level target (3.5, for example) shows the two neighbouring columns ("between L3 and L4") and never invents an intermediate cell. It is neither a score nor an architecture gap: nothing links it to the observed level;
• a free architecture comment.

Statuses are never deduced from assessments and no coverage percentage is calculated. Like the rest of the plan, the architecture can only be edited in a draft, and "Revise" carries it over.

The PDF export. The "Export as PDF" button (in the version box) downloads the plan shown: vision, steps 1 to 4, target architecture and workflow history. The step 1 domains carry the same labels as on screen (AN Map term and reference, "Not covered", "CEVIA classification", "Unrecognised domain"). Every page carries a header (organisation, title, version, status, generation date and time with the time zone, Brussels time; a draft or submitted plan shows "Not approved" prominently) and a footer (CEVIA, an operating unit of Kimani Group SRL, address and VAT; "Confidential — for use within the engagement only"; page number, a short export identifier that lets you find the export in the log). The workflow history gives the time and time zone of each step. Each field recalls its provenance there; the send-back comments are not included. The export is open to every role that sees the ANSP, including when the subscription is past due or cancelled; it is refused during the trial. The file is named ANSP_organisation_vN_date_en.pdf (the language code fr, en or nl tells the three exports apart).

The workflow: draft → submitted → approved.

• A draft is prepared and edited; only a draft can be edited. If a draft was created in the meantime in another session, "Create the ANSP" is refused ("A draft or submitted ANSP already exists") and the screen refreshes by itself to show that draft.
• Submitting locks it and puts it forward for approval. A CEVIA consultant can prepare and submit, never approve. While the plan is submitted, the screen reads "Awaiting the operator administrator's decision (approve, or return to draft with a comment)." (not the "Revise" invitation, which is only for an approved plan).
• The client administrator approves, or sends it back to draft with a mandatory comment (shown on the draft and in the history).
• An approved plan is locked (except advancing an intent's status, see step 3) and stays in force. To change it, "Revise (new version)" creates a new draft (version + 1) that takes over the content (vision, targets, milestones, scenarios and their rank, intents with their status at that moment, stages): the approved plan stays in force during the revision and remains viewable; it is archived only when the client administrator approves the new version. There is only one approved plan and one draft or submitted plan at a time.
• "Abandon this draft" archives it (traced), it is never deleted. As for removing a milestone, a scenario or an intent, the confirmation appears in the page ("Confirm" or "Cancel", Escape cancels), with no browser window. Archived plans remain viewable ("Versions and history" list, with the workflow steps and comments; each step shows its date and time with the time zone, Brussels time ("05:58 (UTC+2)"; UTC+1 or UTC+2 depending on the date of the step) and its author: "date time · transition · display name (organisation)", the organisation not being repeated when it is the same as the display name, with no email address; a step taken by the CEVIA team through delegated access reads "CEVIA team"). A plan is only deleted if the organisation itself is erased on request (right to erasure, end of contract): that erasure is traced.

Who can do what.

The buttons are only a convenience: these rights are also enforced on the server. Advancing an intent's status is open to the same roles as preparing the plan, on a draft and on an approved plan.

Depending on the subscription. During the trial, the module is closed (the menu entry reads "Active subscriptions only" and leads to the subscription page, which says the ANSP strategy is reserved for active subscriptions). If the subscription is past due or cancelled, the ANSP becomes read-only: approved and archived plans remain viewable (the PDF export remains allowed), but no editing, no new plan, no transition, no advancing of an intent's status. An active subscription gives full access. At every subscription change (activation, suspension, reactivation, cancellation), the client administrator receives a short e-mail, with no reason and no amount, with CEVIA's contact (info@cevia.ai). While online payment is not open, a subscription is activated on request from CEVIA: the subscription page then offers "Contact us" (a pre-filled email to CEVIA whose subject is "ANN subscription –" followed by the organisation's name) instead of "Subscribe".

Data collection (importing an alarm export)

The Data collection entry of the menu lets you import an alarm export from your network for scenario GB1523A (radio access network fault management). ANN derives the failures from it, then two measures: the mean time to recovery (MTTR, Mean Time to Recovery) and the fault handling on-time ratio (FHOR, Fault Handling On-time Ratio). These measures feed step 2 of the ANSP strategy (the "Measure" column).

Importing a file. Choose a CSV or JSON file of 15 MB at most, its format (TMF642, the canonical format, or an export shaped like a vendor fault manager), the time zone of the export if the file contains local times without a time zone (for example Europe/Brussels), and the recovery time limit in minutes. This limit is a parameter of your organisation: the reference sets none, ANN never guesses it, and it is shown next to the FHOR value.

What ANN keeps, and what it does not. The file is analysed in memory and then deleted straight away: neither its content nor its name is kept. What remains is the file's fingerprint (the same file is not counted twice), a count report (rows read and rejected, duplicates, symptoms and maintenance set aside, flapping merged, failures, unrecovered failures, personal columns ignored, personal values masked) and the measures. If the file contains personal data (subscriber number, customer name…), the columns are ignored (never read) and the values masked before any processing, all of it counted; if there is too much of it, the file is rejected.

How failures are counted. This is a CEVIA calculation rule, not a TM Forum rule: duplicate alarms, symptoms attached to a parent alarm, noise and planned maintenance are set aside; alarms that flap (resuming within ten minutes) form a single failure; unrecovered failures are counted and shown but excluded from the calculation.

Summer time and winter time. A time with an offset (2026-10-25T02:50:00+02:00, …Z) or in Unix seconds is always exact, including for a failure that straddles a clock change (durations are minutes actually elapsed, not the difference between the clock readings). A time without an offset is read with the declared time zone: exact outside clock changes; inside the repeated hour of the return to winter time (02:00 to 02:59 on the last Sunday of October, which exists twice), ANN keeps the shortest positive compatible duration; a time that does not exist (the switch to summer time) is moved forward by one hour. These rows are counted in the report ("Local-time rows touching a clock change"): if that number is not zero, the measure from that import carries the "Measure to be confirmed" warning ("Data collection" screen, ANSP step 2): ask for an export with an explicit UTC offset.

Importing again. The same file with the same parameters writes nothing ("already imported"). Fixing a rejected file, or changing the limit or the time zone, replaces the previous import.

The four states of the screen. Empty: with no import, the screen explains it and invents no value. Loading: "Analysis in progress…" during the analysis. Error: a general message, never the technical detail; a rejected file says why (required column missing, time zone to declare, empty or too large file…). Insufficient permissions: the auditor can view without importing; a read-only subscription suspends import; the demonstration organisation receives none.

"Simulated data". In CEVIA's simulation organisation, the demonstration files are fictitious: any measure that comes from them carries the Simulated data label. These values illustrate a story; they are neither a market benchmark nor a value of the standard.

Preparing my evidence

For each available scenario, ANN describes what is concretely expected as evidence at each stage of the IAADE cycle — not just a generic sentence, a concrete example of what other operators have provided for that type of task.

Two places to find it:

• In the questionnaire, directly under each task, right above the evidence upload zone — you see the example at the moment you drop your file.
• In Cross-HVS Comparison (HVS: High-Value Scenario), under the Evidence guide tab: the full checklist for all your active scenarios, grouped by domain then by IAADE phase — consultable before you even start answering the questionnaire, to prepare your evidence pack ahead of an engagement.

Each entry states whether the expected evidence is rather Declarative (attestation, documented policy) or Technical (system export, execution log) — the same distinction used when uploading evidence (see "Evidence" above). A completed assessment's PDF/ZIP export includes this same checklist for the evaluated scenario.

This evidence guide is a preparation aid built by CEVIA from operator practice and applicable TM Forum/3GPP/ETSI/O-RAN references — it is not an officially published TM Forum evidence nomenclature. A scenario without an evidence guide isn't scored better or worse: it simply hasn't been documented at this level of detail yet.

The strategic roadmap

Generate the roadmap, from the Results screen once the assessment is far enough along. ANN builds three phases from the measured gaps:

1. Close the critical gaps
2. Align with the target level
3. Consolidate and aim for advanced autonomy

Each phase carries an AN Journey stage label (Gap Analysis, Solution Design, Implementation & Validation) and a list of actions, whose status cycles through three states by clicking: To do → In progress → Done.

The 3K indicators

• KBI (Business Impact) — always shows "Not measured". This isn't an oversight: pricing the business impact requires data specific to the client (hourly intervention cost, incident volume, revenue per service) that ANN has no way to know on its own. The method explains this rather than inventing a plausible figure — to be scoped with you in a dedicated workshop if you'd like.
• KEI (Zero Wait / Zero Touch / Zero Trouble) — three percentages computed live from your questionnaire answers (awareness → Zero Wait, execution → Zero Touch, average of analysis/decision → Zero Trouble), compared against a 90% target.
• KCI (Capability Index) — percentage of tasks already at or above the target level, recalculated every time you view it from the real state of your answers, never frozen at generation time.

The timeline

As long as no phase has both a start and an end date, the timeline stays empty rather than inventing a schedule. Fill in a phase's dates (the "Dates" control) to see it appear, positioned proportionally between the earliest and latest phase.

A PDF export of the roadmap is available from this screen.

Preparing for ANLAV certification

ANLAV Readiness (menu entry, or the "ANLAV Readiness" button of an assessment's roadmap). This screen answers one question: are we ready to submit our assessment to the TM Forum for ANLAV validation? ANN helps you prepare for the ANLAV assessment: it does not deliver it and does not certify. The assessment and the certification are part of the TM Forum programme (IG1392); a banner at the top of the screen says so.

Evidence coverage (formerly "Cert-o-meter") shows an overall evidence coverage rate, weighted by type: technical evidence counts in full, declarative evidence alone only counts for half. A badge shows whether the configured threshold is met. It is not a certification score (the (i) tooltip next to the label says so). This weighting (technical 100% / declarative 50%) is CEVIA's own methodology, validated internally — it is not part of the official TM Forum IG1252 scale and never affects the maturity score (Lscenario) itself, only this coverage rate.

The coverage threshold is configurable (80% by default), editable by anyone with write access to the assessment — not reserved to a specific role.

The compliance checklist lists the deliverables expected before an official certification request: scoring report, evidence pack, validated roadmap, and coverage threshold met. The first three are checked manually; the fourth checks itself as soon as the real threshold is met — it can't be checked by hand before that's actually true.

The Evidence Vault lists every piece of evidence deposited, timestamped, with its type and who deposited it — the audit trail that goes with the submission to the TM Forum. Removed evidence does not appear in it (it stays viewable from the questionnaire).

Export the evidence pack downloads a ZIP archive containing:

The export is immediate — no background generation to wait for.

The HVS (High-Value Scenario) catalogue

The TM Forum catalogue lists 23 High-Value Scenarios in IG1339 v2.4.0 (January 2026). As of today, only a subset is actually tooled in ANN — the others carry a "Coming soon" button rather than a simulated access.

For active scenarios, ANN honestly states the nature of its source: a real ANLAV report where one exists, or a reconstruction documented by CEVIA from published TM Forum questionnaires when no public ANLAV report is available. A reconstructed scenario is never presented as an official TM Forum table if it isn't one.

A methodology grounded in standards you already know. The CEVIA/TM Forum methodology doesn't start from a blank page: for most active scenarios, it builds on 3GPP and ITU-T technical standards that network engineers already know — the ITU-T X.733 alarm model, 3GPP fault management specifications (TS 28.111), or automated radio optimization (the SON family, TS 32.5xx), for example. Where this link is strong, it's shown next to the relevant scenario; where it isn't (some IP/transport domains sit closer to IETF standards than 3GPP), ANN says so rather than forcing a connection.

Account security

You manage your account security from Security, available from the menu in the top right.

Enabling two-factor authentication (2FA)

Enrollment uses an authenticator app (TOTP — Google Authenticator, 1Password, etc.). ANN first asks for your account password again: a session left open is not enough to enroll a device. Then scan a QR code and enter a first code to confirm your app is synced. Once enabled, you are given 10 single-use backup codes — shown only once, keep them somewhere safe: they let you sign in if you lose access to your authenticator app.

When you enable 2FA, your other open sessions are signed out: you stay signed in on the device you are using, not elsewhere.

Once 2FA is enabled, signing in takes two steps: email and password first, then the 6-digit code from your app (or a backup code). The password alone is no longer enough to open a session. A code from the app works only once; so does a backup code (it is used up as soon as it serves, on whichever screen you use it).

Who must enable it

• CEVIA accounts (CEVIA Admin and CEVIA Consultant): 2FA is mandatory. Until it is enabled, only the Security screen is available (a banner explains why); everything else in ANN, the Operations view included, stays closed. These accounts cannot disable it.
• Other roles: 2FA stays optional; you can disable it by entering a code.

If you enter the wrong code

After a correct password, 5 wrong verification codes lock the second factor for 15 minutes: even a correct code is then refused. You receive an e-mail, and you can try again when the 15 minutes are over. A wrong password, however, never locks your account (otherwise anyone could lock you out); but after 10 wrong passwords in 15 minutes from the same address, that address is refused for 15 minutes, for every account.

Changing phone: "Replace device"

On the Security page, "Replace device" asks for your password and a current code (or a backup code, which is then used up), then shows the QR code of the new device. Enter a code from the new device to confirm. Your old device stays active until that confirmation: you are never without 2FA, and if you give up or the request expires (10 minutes), nothing changes. On confirmation, 10 new backup codes are shown once; the old ones stop working, and your other sessions are signed out.

Lost device and backup codes

If you no longer have your device or your backup codes, contact CEVIA: an administrator resets your 2FA on the server. You then sign in again with your password and register a new device (for a CEVIA account, the enrollment screen opens).

Security e-mails and language

ANN e-mails you when 2FA is enabled, when the device is replaced, when CEVIA resets it and when the second factor is locked. These e-mails never contain a code or a secret; if it was not you, contact CEVIA immediately. They are written in your account's language: the one of the interface at your last sign-in, or of your last language change (FR, EN or NL); French by default. The subscription-change e-mails sent to your organisation's administrators follow the same rule.

Changing your password ("Forgot password?") also signs out all open sessions of your account.

My profile

At sign-up, ANN asks for "Your name" (2 to 120 characters, no e-mail address and no link): it is the name shown for you in ANN and in your organisation's history. You can change it at any time from "My profile", available from the menu in the top right. The e-mail address is shown read-only: it cannot be changed here.

If your account was created before this name was requested, a banner invites you to complete your name; it disappears as soon as the name is saved and never blocks the use of ANN. Changing your name is logged without keeping the text (neither the old nor the new name).

When something's not right

A task stays "Not assessed". This isn't a failure: no answer has been given yet, or its only answer is an AI suggestion never validated. The score doesn't count it as satisfied, but doesn't count it as a zero either.

AI pre-fill responds in "offline demo mode". No AI key is configured for your deployment, or the call failed (timeout, service unavailable) — ANN tells you explicitly rather than showing a silently degraded suggestion. Levels proposed in this mode remain purely indicative.

"Daily AI pre-fill quota reached". 50 calls per day per organization. Past that, enter the remaining levels manually — the limit resets the next day.

Evidence upload stays blocked. A level must be chosen for the task first — ANN never attaches evidence to an answer that doesn't exist yet.

A screen is empty, slow to appear, shows an error or an "Insufficient permissions" box. Four states exist on the data request list, loop governance, the comparison and the transverse capabilities:

• empty: a text explains why nothing appears (for example, no assessment exists yet) and offers a way out, such as "See assessments";
• loading: "Loading…" is shown while your data is read;
• error: a general message and a "Try again" button, with a technical reference to pass to your administrator; ANN never shows the detail of the error, which could contain data;
• insufficient permissions: a box says why you cannot act (export the data request list, change the governance of a loop, start an assessment) and reminds you that viewing remains possible.

This guide describes the real state of the application at the time it was written. Any feature that doesn't exist yet in the code isn't described here as if it did.