Pages
More Information

The grounding substrate and your first loop

What answers are built from, and the path from one domain to a reference asset

Start with one loop. There are many more. Every loop follows the same governed pattern, which is what makes the first one worth starting and the next one cheap to add. Exosphere Agentic runs on Azure and integrates with the Microsoft AI platform, deployed into the customer's own tenant — so context, data and governance stay where they belong.

Updated

Grounded in the published record, cited every time

An Exosphere Agentic answer is not taken from a model's memory. The evidence a loop puts its name to is retrieved from the published record and traceable back to it.

  • TM Forum: Open API and component specifications, the ODA Canvas reference implementation, SID, eTOM and TAM, and the industry guides.
  • Beyond TM Forum: CAMARA network APIs, Mplify (formerly MEF) LSO, ETSI NFV and MEC, Broadband Forum USP and CWMP, 3GPP 5G core and SA5 charging and management, IETF and OpenConfig YANG, and ONAP.
  • The commercial layer: converged charging, mediation and rating concepts, and public BSS and billing product documentation.
  • Operational systems: ERP, CRM, helpdesk and service-management documentation, because a billing question rarely stays inside billing.

Licensed and member-gated material is used for grounding and citation and is never republished. Missing data is stated, never filled in.

Retrieval is how a loop cites the industry. The ontology is how it relates your products, contracts and policies to each other. Both stay inside your tenant.

Three layers of understanding, each owned by the right people

LayerContributesOwned by
Industry foundationSID information concepts, eTOM process context, ODA modular architecture, Open API standards-aligned accessTM Forum and the industry
Customer operating modelYour products, contracts, policies, processes, terminology and system relationshipsYou, the operator
Loop contextThe relevant entities and relationships, rules, required evidence, authority and permitted actionsThe loop's designer

The layers are kept apart because they change at different rates. Every loop inherits all three, and the first loop extends the shared foundation with only the customer context it needs. See SID to entity types, entity by entity.

Three moves from one domain to a reference asset

Exos Systems builds the telecom ontology the way it should be built: one bounded domain at a time, each phase closed by an exit gate, with scope agreed before any dates.

  1. Map one domain properly. Start with product and order: SID Customer and Product ABEs bound to your systems of record. Exit gate: a fixed question set answered with citations.
  2. Cross the boundary. Extend to customer-facing and resource-facing services and the resources beneath them, add telemetry, and act through governed Open API calls. Exit gate: from a fault to customer impact, with a person approving the action.
  3. Make it a reference asset. A versioned telecom ontology pack and a governance runbook, contributed upstream through TM Forum. Exit gate: a second operator adopts it with no new mapping work.

From one domain to a reference asset

flowchart LR
    P1["PHASE 1 · MAP ONE DOMAIN<br/>Product and order<br/>SID Customer and Product ABEs<br/>bound to systems of record"]
    G1(["Gate · fixed question set<br/>answered with citations"])
    P2["PHASE 2 · CROSS THE BOUNDARY<br/>CFS and RFS to Resource<br/>plus telemetry<br/>governed action via Open APIs"]
    G2(["Gate · fault to customer impact<br/>a person approves the action"])
    P3["PHASE 3 · REFERENCE ASSET<br/>Versioned telecom ontology pack<br/>Governance runbook<br/>Contribute upstream"]
    G3(["Gate · second operator<br/>no new mapping work"])
    P1 --> G1
    G1 --> P2
    P2 --> G2
    G2 --> P3
    P3 --> G3
    classDef exos stroke:#0077B6,stroke-width:2px
    classDef human stroke:#009688,stroke-width:3px
    classDef std stroke:#005F8A,stroke-width:1px
    class P1,P2,P3 exos
    class G2 human
    class G1,G3 std
The engagement path: every phase ends at a gate, and the asset is proven when a second operator needs no new mapping.

Questions for a first workshop

The first conversation is about your outcome, not our technology. Come ready to discuss:

  1. Which revenue, service or growth outcome is material enough to improve first?
  2. Which handoffs slow that outcome today?
  3. Which systems remain authoritative?
  4. What policies and approval points govern action? Bring your delegation-of-authority matrix.
  5. What evidence would show the loop worked?

The design review that follows

  • Map the source systems, events and Open APIs for the chosen outcome.
  • Identify the entity relationships and the customer-specific rules they depend on.
  • Define the identity, permissions, approval point and audit evidence for every tool action.
  • Specify failure handling and compensation for every step that changes a record.

Measures that fit the outcome

OutcomeExample measures
Protect revenueCash, leakage, exposure
Reduce cost to serveEffort, resolution, backlog
Accelerate revenueConversion, cycle time, time to bill

Establish the starting measure with your team, run one loop, and review the change before expanding.

From workshop to first loop

flowchart LR
    W1["Pick the outcome<br/>to improve first"]
    W2["Map the systems<br/>that stay authoritative"]
    W3["Encode policy<br/>and authority"]
    W4["Set the<br/>approval point"]
    W5["Agree the measure<br/>and the baseline"]
    W6["Run one loop<br/>review, then reuse"]
    W1 --> W2
    W2 --> W3
    W3 --> W4
    W4 --> W5
    W5 --> W6
    classDef exos stroke:#0077B6,stroke-width:2px
    classDef human stroke:#009688,stroke-width:3px
    class W1,W2,W3,W5,W6 exos
    class W4 human
The approval point is designed in from the first workshop, not added afterwards.

From this wiki to a running loop

  1. Explore. This wiki and the library introduce the approach, open to everyone.
  2. Join. Request member access. Exos Systems approves member access, and each colleague requests their own.
  3. Go deeper. Members also get briefings for their role, cited search across approved Exos material, and proposals.
  4. See it run. A demonstration walks one governed loop end to end.
  5. Scope it. A workshop maps one candidate loop to your priority, systems and approval model.
  6. Prove it. The first loop runs through its exit gates, then the foundation is reused for the next.

What a demonstration shows

  • The one line behind an invoice jump, found and explained.
  • Missing data stated plainly, not guessed.
  • Policy checks passed before the action is offered for approval.
  • A single-use approval bound to exactly that action, executed once.
  • The result confirmed on the next invoice.
  • Restraint: an expected charge recognised and left alone.

Demonstrations run on synthetic accounts; any figures shown illustrate the mechanism and are not a performance claim.

Exos Systems is a TM Forum member and aligns to ODA. Standards bodies named here describe the context we work in; they are not an endorsement by those bodies.

Take the next step

Bring one outcome and your approval model, and we will map your first loop with you.