#FAQ — TOTSCo Integration

Connected Services Framework (CSF) — Standalone Companion Document — Version 2.0

These questions were proposed by TOTSCo as part of integration discussions held on 18 November 2025. The FAQ has since been updated to reflect the consolidations and ratifications in the framework — most notably the locked-down per-MAP HMAP interface model (see the TOTSCo HMAP Integration Guide), the CSF-mirrors-TOTSCo directory shape, the OTS/GPLB filter URLs, and the active surfacing of the upside of collaboration for TOTSCo.

This document lives in the standalone section so it can grow over time without being tied to the Part 2 numbering. Cross-references below use paths relative to the standalone folder.

#Q1 — Registering CSF Endpoints

Impact: Zero to Low

No new MAP or CP connections are anticipated — existing OTS connectivity is already operational. Any new MAP or MAP-of-1 must register with TOTSCo following existing procedures (IP allowlisting, OAuth 2.0 / API-key credentials, JAM Specification compliance).

The only addition is a Directory API endpoint URL for TOTSCo to retrieve the MAP's CSF registry. The same OAuth 2.0 credentials and IP security mechanisms apply.

As the CSF matures, some CPs may onboard as MAP-of-1s — a CP operating its own MAP infrastructure (see Part 1 §7.4). Such MAPs also register with TOTSCo using TOTSCo's existing procedures. The volume is anticipated to be modest and the registration process is unchanged.

See Part 2 §6.3 Registering CSF Endpoints and the TOTSCo HMAP Integration Guide for the full operating model — including the dedicated, locked-down HMAP interface that each CSF MAP exposes exclusively for TOTSCo, and the per-MAP dedicated CSF letterbox URLs that mirror TOTSCo's existing per-partner pattern.

#Q2 — The CSF CP Registry — How would TOTSCo use it?

Impact: Medium

TOTSCo collects each MAP's CP Registry (anticipated fewer than 10 MAPs initially) and converges them into a Master Registry. This can be merged with the existing TOTSCo directory or maintained separately.

The CSF CP Registry is JSON-formatted and a strict superset of the TOTSCo OTS / GPLB directory structure, making convergence straightforward. Parsers that don't recognise the CSF-specific additions ignore them; the underlying TOTSCo-compatible shape is unchanged.

Key benefits for TOTSCo:

• SforB process contacts (warranty period and ongoing support) are already included.
• MAP-to-CP, CP-to-MAP, CP-to-CP, and MAP-to-MAP contact points are built in.
• Eliminates the need for paper-based spreadsheets for support contacts.

Virtualised test CPs with synthetic data are available for integration testing.

Sponsorship object. As of CSF v2.x, the CP Registry also carries a sponsorship object (see §5.4.2 Sponsorship Object — Rotation Rules) used by CSF MAPs to coordinate the rotation for onboarding new MAPs. TOTSCo participating as an HMAP is exempt from the sponsorship rotation — onboarding of new CPs to TOTSCo continues under TOTSCo's existing procedures; the sponsorship object is a CSF-internal coordination mechanism.

#Q3 — Handling Different RCPID Formats

Impact: Low

The SforB Message Specification defines identity fields as strings (up to 256 characters). UUIDv4 (36 characters) fits within this constraint.

• CSF → TOTSCo: Uses TOTSCo's 4-character RCPID from the TOTSCo directory.
• TOTSCo → CSF: Uses the UUIDv4 RCPID from its Master Registry (collected from CSF CP Registries).

TOTSCo automatically acquires all UUIDs when collecting MAP registries. Both platforms already accept UUIDv4 for correlation IDs. TOTSCo uses the same 4-character RCPID format for both OTS and GPLB (SforB) today, so this translation is no different from any existing TOTSCo-internal lookup.

OTS RCPIDs remain at TOTSCo. OTS is mandated by Ofcom to use TOTSCo as the single industry platform — no OTS migration to the CSF is contemplated. The translation between TOTSCo's 4-character RCPID and the CSF's UUIDv4 RCPID applies only at the SforB transport boundary. For CPs that operate both OTS and SforB, the OTS Rxxx is independent of any SforB UUIDv4 the CP might also hold on a CSF MAP — TOTSCo retains exclusive control of its OTS allocation.

#Q4 — Are modifications needed to the TOTSCo API?

Impact: Zero

No. TOTSCo uses the industry JAM Specification — the same standard used by the CSF. The CSF validates envelopes identically, uses OAuth 2.0 over TLS 1.3, and returns HTTP 202 for accepted messages.

The CSF's 8xxx PKI error codes are not sent to TOTSCo. The industry 9xxx codes are fully honoured.

The CSF is a bit-pipe transport (see Definitions §2.3) — it carries the JAM envelope between MAPs and does not interpret the message body. This means the JAM messages TOTSCo sends to CSF MAPs (and vice versa) traverse the network unchanged at the body level; the CSF only validates the envelope and the OAuth token. No API modifications on TOTSCo's side are required.

#Q5 — Distinguishing message flow between standard MAPs and CSF MAPs

Impact: Low to Medium

TOTSCo can distinguish between its directly managed CPs (paying subscribers) and CPs discovered through CSF registries (guests). A MAP may have CPs interacting via both TOTSCo and CSF — TOTSCo allocates RCPIDs for its managed CPs and discovers additional CPs through registry collection.

The message flow in each direction is illustrated in §6.7 (CSF → TOTSCo) and §6.8 (TOTSCo → CSF) of the TOTSCo Integration chapter. In the CSF, CP + MAP are treated as a single endpoint at the transport layer — the MAP (or MAP-of-1) handles all CSF message exchange; the CP gives internal instructions and receives internal nudges. The flow visible to TOTSCo is therefore CSF-MAP-to-TOTSCo (or TOTSCo-to-CSF-MAP) at all times; TOTSCo never needs to interact with a CSF CP directly.

A fully worked bidirectional example (NowYoYo / BBBX ↔ Red Company) and a Mermaid sequence diagram are in the TOTSCo HMAP Integration Guide §Phase 3 Test.

#Q6 — CP-to-CP communications tool

Impact: Zero to Low

The OTS CP-to-CP tool was not designed for the kinds of contact patterns SforB requires (multi-purpose, hours-aware, multi-channel). The CSF's contact[] array on every CP and MAP (see §5.6 CP Contact Object) provides exactly that — phone / email / URL with purpose tags (sales, support, technical), availability hours and days, and free-text usage notes — all retrieved via authenticated API.

TOTSCo can re-use this directly. When forwarding to a CSF-side CP, the destination contact details are available in real time from the CSF MAP's published registry. This eliminates an industry pain point without TOTSCo having to build or maintain a CP-to-CP tool itself. CPs already have the tools and contacts they need for sales and technical support; the CSF registry simply makes them discoverable and machine-readable in a single uniform shape across the whole industry.

#Q7 — Availability and Latency Guarantees

Impact: Zero to Low

In the peer-to-peer model, messages travel directly between two MAPs — no forwarding or routing hub — significantly reducing overall latency.

The CSF implements enterprise-grade delivery patterns:

• Retry with exponential backoff and jitter.
• Respect for 503 Service Unavailable and 429 Too Many Requests with Retry-After.
• Circuit-breaker patterns after consecutive failures.

SforB SLAs are significantly longer than OTS (no 60-second Switch Match response requirement), allowing the industry to tolerate lower message rates and support retry policies.

The CSF's industry-wide availability target — 99.95% ("three nines and a five") — is deliberately aligned with the TOTSCo Availability Target so industry-wide SLAs remain consistent across both transports. See Onboarding & Testing Process §8.7 Retry and Delivery Policy.

#Q8 — Outage Calendar

Impact: Zero

The CSF considers traditional outage calendars to be outdated. Modern SaaS and cloud infrastructure should achieve full resilience and near-100% availability. When a CP is temporarily unavailable, the MAP queues and retries.

The CSF registry includes service status URLs and API endpoints for real-time operational monitoring — a more effective alternative to manual outage notifications.

The CSF's map/outage[] array in the CP Registry (see §5.4 MAP Section — Field Reference) carries ITIL-priority outage entries with start/end timestamps, affected services, descriptions, and escalation contacts. TOTSCo collecting the CSF registries automatically receives a real-time outage view for every CSF MAP — strictly more useful than a static outage calendar. See §9.4 Outage Notification for the operational rules.

#Q9 — Diagnostics

Impact: Zero

Audit records and diagnostics remain integral to both OTS and SforB. Through CSF registries, TOTSCo gains direct access to every CSF MAP's diagnostic contacts for prompt issue resolution.

Diagnostic support in the CSF includes:

• The JAM envelope's auditData[] array (correlation IDs, session metadata, test flag) — see Onboarding & Testing Process §5.
• The optional X-CSF-ROUTE HTTP header that records the route a message has taken through the network (each MAP appends a timestamp + MAP name) — useful for HMAP-bridged messages.
• The structured 9xxx industry error codes and the CSF-specific 8xxx PKI codes returned in synchronous responses.
• Per-MAP service-status URLs and operational contact details in the registry.

#Q10 — Support and Ticketing Arrangements

Impact: Zero to Low

The CSF registry provides CP and MAP support hours, contact points (phone, email, URL), and purpose tags (sales, support, technical). URLs can link to targeted web forms or ticketing systems.

The CSF's contact object (used at both MAP and CP level — see §5.6) uses a single uniform structure across the industry: type (phone, email, URL), value, purpose[] (sales, support, technical), availabilityFrom / availabilityTo / availabilityDays[], and a free-text comment. This means TOTSCo's existing support tooling can consume CSF MAP and CP contact data with no additional parsing — the same JSON structure CSF MAPs expect.

#Q11 — Service-Level and other commitments

The TAG is prepared to define and agree specific SLAs with TOTSCo once concerns are understood. The CSF already operates to the same availability standards expected of all OTS MAPs.

TAG governance now publishes an annual aggregated transparency summary of network activity (see §10.6.7 Anti-Competitive Safeguards) — volumes, participants, success rates. Test traffic is excluded from production telemetry per the JAM audit test=true rule. TOTSCo as an HMAP can rely on the same transparency view if it elects to participate in the transparency-reporting flow; this is optional and there is no obligation.

#Q12 — What benefits does TOTSCo get from being an HMAP on the CSF?

TOTSCo gains four concrete benefits as an HMAP on the CSF:

1. Real-time outage and service-status view. TOTSCo collecting CSF registries automatically receives every CSF MAP's map/outage[] and map/serviceStatusServiceURI data, replacing the need for any outage-coordination spreadsheet (see Q8 above). Strictly richer than any static outage calendar.
2. Real-time CP-to-CP contact data. Every CSF-side CP publishes a contact object (phone, email, ticketing URL with purpose tags) reachable via authenticated API; eliminates an industry pain point without TOTSCo building or maintaining a CP-to-CP tool (see Q6 above).
3. Bridge revenue / participation positioning. TOTSCo remains the SforB hub for CPs who choose to stay on the TOTSCo subscription model; the CSF interoperability is a value-add for those CPs, not a competitor. The framework is a market-expansion mechanism for TOTSCo, not a market-share threat.
4. Industry standing as a forward-looking participant. Being an HMAP on the open framework signals to industry, regulators, and TOTSCo's own customers that TOTSCo is supporting industry transformation, not blocking it. Reputationally significant in the v2.0 publication cycle.

#Q13 — Will TOTSCo's existing OTS commercial relationships be affected?

No. OTS is mandated by Ofcom to use TOTSCo as the single industry platform. The CSF does not interact with OTS at any level — see §7.4.1 Definition and Scope for the formal scope statement.

TOTSCo's OTS subscriptions, OTS RCPID allocation, and OTS hub operations continue exactly as today. The CSF integration is strictly for SforB and other non-OTS protocols; the OTS hub and the SforB hub on TOTSCo's side are operationally independent and the CSF interaction touches only the SforB side.

#Q14 — Will TOTSCo lose SforB CPs to CSF MAP-of-1s?

Some CPs may choose to migrate SforB traffic to a CSF MAP-of-1; most won't.

The migration path documented at §7.4 is technically demanding — it requires the CP to run TLS 1.3, OAuth 2.0, DNS management, the Letterbox and Directory APIs in-house, plus 24×7 on-call cover. Most CPs prefer to remain with TOTSCo's managed service.

The CSF supports this co-existence:

• A CP staying with TOTSCo continues exactly as today, with the additional benefit that CSF MAPs become reachable via TOTSCo's HMAP role.
• A CP that chooses to migrate SforB to a CSF MAP-of-1 retains the right to do so (the framework explicitly supports it), but takes on the operational obligations that come with running their own MAP.

For TOTSCo, the CSF is a market-expansion mechanism, not a market-share threat — it brings new CSF-MAP CPs into reachability with TOTSCo's customers, not the other way around.

#Q15 — Does the CSF impose any new obligations on TOTSCo's OTS operations?

None. The CSF interaction touches TOTSCo only at the SforB transport boundary. OTS message routing, OTS RCPID allocation, OTS process flows, OTS commercial arrangements, and OTS regulatory reporting all continue exactly as today and are explicitly out of CSF scope (see §7.4.1 Definition and Scope and Part 2 §6.1 Overview).

The CSF transport is process-agnostic — it carries JAM envelopes between MAPs and does not interpret the message body — so it cannot retroactively impose process-layer obligations of any kind.

The locked-down HMAP interface that each CSF MAP exposes exclusively for TOTSCo (see the TOTSCo HMAP Integration Guide §1) provides an additional architectural commitment: CSF version increments do not propagate through the dedicated TOTSCo endpoints, so TOTSCo's integration is a one-time build, not an evergreen one.

#Q16 — How does the CSF's "bit-pipe" model preserve TOTSCo's operational control?

The CSF is defined as a bit pipe in Definitions §2.3: "a network provider that simply moves data without adding value or examining content". This has three practical consequences for TOTSCo:

1. TOTSCo's internal CP-to-MAP relationships are unchanged. The CSF carries TOTSCo-originated messages between TOTSCo and CSF MAPs, but how TOTSCo serves its own CPs internally is unaffected.
2. Process-layer business state stays with the parties. Customers, SORs (Switch Order References), ServiceIdentities, billing, and support live with the CP and (for TOTSCo's CPs) with TOTSCo. The CSF carries the envelope; it does not see the body.
3. Industry-process control stays with the industry bodies. TOTSCo continues to control OTS process documentation; GPLB-SG continues to control SforB process documentation; the TAG controls CSF transport only.

The bit-pipe principle is what makes TOTSCo's existing operating posture safe under CSF integration: every layer above the transport is owned by TOTSCo or by its industry counterparts, not by the CSF.

#Q17 — How does CSF participation enhance TOTSCo's value proposition for SforB CPs?

TOTSCo's SforB hub already provides a managed service to its subscribed CPs. By participating in the CSF as an HMAP, TOTSCo extends that managed service's reach: subscribed CPs gain direct interoperability with CSF MAPs (and the CSF MAPs' CPs) without TOTSCo needing to negotiate bilateral connections with each one. TOTSCo CPs get:

• Wider counterparty reach — every CSF-connected CP becomes addressable through TOTSCo, with no additional commercial work for the CP.
• Real-time contact data for every CSF-side CP they need to operationally reach — replacing the OTS CP-to-CP tool, which is not mandated for SforB.
• Future-protocol readiness — when the TAG adds new industry protocols to the CSF baseline (for example, OTS Porting), TOTSCo CPs can adopt them via TOTSCo's HMAP role without additional bilateral integration.
• Continued use of TOTSCo's existing JAM tooling — the CSF uses the same JAM envelope, OAuth 2.0, and TLS 1.3, so TOTSCo's existing implementation just works at the CP side; no CP-side code change is required.

#Q18 — What message delivery policy applies at the HMAP boundary between TOTSCo and a CSF MAP?

The CSF's Part 2 §4.7 Message Delivery Policy explicitly addresses this. The HMAP boundary is asymmetric by design:

• TOTSCo's hub-side behaviour follows the OTA2 GPLB Message Delivery Principles V0.2 — the same delivery rules TOTSCo already applies for any hub-mediated SforB traffic. Match Requests fail-fast in 30 seconds (linear retries at 5/10/15/20/25 s); other SforB messages retry for up to 12 days (initial burst at 10/20/30/60 s then 60 s cadence). Single-flight per endpoint with queue ageing; async failure notifications back to the sender's pre-configured failure endpoint. No change for TOTSCo — this is hub behaviour today.
• The CSF MAP receives those async failure notifications as a standard TOTSCo hub client — exactly how any TOTSCo-subscribed MAP handles them now. No new mechanism to design.
• The 1 s connection timeout and 3 s response timeout are aligned across both sides — universal good practice irrespective of transport.
• The HMAP interface is locked-down per §6.3.1. CSF version increments — including any future change to §4.7 itself — do not propagate through the dedicated TOTSCo endpoints. The asymmetric behaviour at the boundary is stable and bilateral by design.

Critically, the GPLB hub schedules do not propagate into the wider CSF P2P transport. On the CSF MAP-to-MAP side, the CSF retains exponential backoff with jitter (the industry-standard distributed-systems pattern); persistent failure escalates via inter-MAP operational engagement (map/outage[] / map/contact[]) rather than silent multi-day queueing. See the analysis report at wiki/syntheses/csf-compliance-with-gplb-message-delivery-principles for the full architectural framing.

For TOTSCo this means: integrate the HMAP interface exactly as you would any other hub-side delivery target. No new delivery semantics; no surprise behaviour. The CSF's own delivery policy is something the CSF MAP applies on its side of the boundary, and it stays there.

#Document Control