#10. Governance

Connected Services Framework (CSF) — Part 1: Framework — Version 2.0

#10.1 Standards Landscape

The CSF operates within a multi-layered governance structure. Each layer has its own standards body, documentation, and change control process. The CSF leverages these existing standards rather than duplicating them.

#10.2 Standards Bodies

#10.2.1 OTA2 — Office of the Telecommunications Adjudicator

Accountable for:

• RCPID Standards
• JSON Asynchronous Messaging Specification (JAM Spec)

The industry has established RCPIDs and the JAM envelope as standards that MUST be implemented by all current and future transport providers, including TOTSCo and the CSF. These standards enable consistent addressing and routing of messages. The use of specific envelope fields may vary across industry processes (OTS, SforB) but the fields themselves are standardised.

All documentation is published on the OTA2 website.

#10.2.2 TOTSCo — Telecoms One Touch Switching Company

Accountable for:

• All OTS-related Message Process and Message Specification documentation
• OTS Best Practice Guidance
• Transport Delivery Policy and Response Codes (9xxx)
• TOTSCo Hub API Specification v2.0

The Industry Process Group (IPG) and Operations Group (OG) generate original documentation and proposed changes. All documentation is under change control and published on the TOTSCo website.

#10.2.3 GPLB-SG — GPLB Steering Group

The GPLB Steering Group (GPLB-SG) is an independent body of industry stakeholders working alongside the OTA2. It guides and facilitates the steering meetings and the publication of the Switching for Business (SforB) process documentation via FCS. The group retains the historical "GPLB" label even though the underlying process has been renamed from Gaining Provider Led Business switching to Switching for Business (SforB) to better describe the protocol.

Accountable for (via FCS publication):

• Switching for Business (SforB) Process documentation
• Switching Open Orders specification
• Matching Summary and Validation Process
• SforB Response Codes and Asset List Guidance
• Customer Matching Guidance
• Best Practice Guide for Avoidance of Erroneous Transfers
• SLAs

All documentation is under change control from 30 September 2025 and published on the FCS website.

#10.2.4 TAG — Telecom Technical Architecture Group

Accountable for:

• Connected Services Framework (CSF) — this documentation
• CSF Transport Delivery Policy and Response Codes (industry 9xxx + CSF 8xxx enhancements)
• Testing and Onboarding of MAP documentation
• Hub Implementation Overview Plan

The TAG maintains autonomy to manage and iterate specific areas of the CSF. All changes to CSF documentation are undertaken by the TAG group, which meets via its steering group call weekly.

#10.3 Change Control

#CSF Documentation

All CSF documentation builds on existing OTS message exchange standards, including directory elements and TOTSCo 9xxx codes, to maintain consistency and avoid misunderstandings. Where additional response codes are required for security and signalling between MAPs and CPs, these are introduced using the 8xxx series.

Changes to the CSF follow this process:

1. Proposal: Any TAG member can propose a change
2. Review: The TAG steering group reviews the proposal at its weekly meeting
3. Consensus: Changes require consensus among TAG members
4. Publication: Approved changes are published and versioned
5. Adoption: MAPs adopt changes incrementally through API versioning and feature releases

#Industry Process Documentation

Changes to industry process documents (SforB process, JAM Spec, RCPID standards) follow the change control processes of their respective standards bodies (GPLB-SG, OTA2, TOTSCo). The CSF does not control these processes but references them.

#10.4 Memorandum of Understanding

The MAPs and CPs that participate in the CSF are bound by a Memorandum of Understanding (MoU). The MoU:

• Makes it simple to join and contribute to the CSF
• Reflects the CSF's nature as an open standard
• Is licence-free for any CP or MAP to use for any purpose
• Outlines the collaborative responsibilities of participants

#10.5 Decentralised Governance

The CSF deliberately decentralises governance responsibilities:

• No centralised administrator: Controls are distributed to CPs and MAPs
• Self-regulation: The framework promotes good behaviour and discourages bad behaviour through its design (e.g., DNS-based CP control, PKI verification, directory transparency)
• Commercial independence: MAPs and CPs are free to establish their own commercial relationships; the CSF has no impact on these arrangements
• Cost reduction: Decentralising basic functions reduces costs for all parties and makes message exchange more transparent

#10.6 Governance Controls

The governance controls below were ratified by the TAG steering group on 2026-04-29 and form the operational baseline for the CSF's decentralised model. Each control leverages the framework's existing peer-to-peer architecture and the TAG's weekly steering group, without introducing heavy central administration.

#10.6.1 TAG Decision-Making and Voting

The TAG steering group operates by consensus wherever possible. Where consensus cannot be reached, the following formal procedure applies:

• Quorum: A formal vote MUST be attended (in person or by recorded proxy) by at least 60% of currently onboarded MAPs. A vote held below quorum is invalid and MUST be rescheduled.
• Voting weight: One MAP, one vote, regardless of MAP size, footprint, or seniority. A MAP that operates as a MAP-of-1 carries the same single vote as a MAP serving many CPs.
• Voting threshold: A simple majority of votes cast is sufficient for operational decisions. Specification changes (additions to or breaking changes in the CSF documents) require a supermajority of votes cast.
• Decision records: All TAG decisions MUST be recorded with the date, attendees, proposal summary, vote tally, outcome, and dissenting views. These records are accessible to all MoU signatories.
• Observer status: Organisations that are not yet MAPs but have a legitimate interest (e.g., prospective MAPs, industry bodies, OTA2, TOTSCo) MAY attend TAG meetings as observers. Observers contribute to discussion but do not count toward quorum and have no voting rights.

#10.6.2 MAP Compliance and Periodic Review

Onboarding validates a MAP at a point in time, but ongoing compliance must also be assured:

• Annual self-certification: Each MAP SHOULD submit an annual self-certification to the TAG confirming continued compliance with the CSF requirements, including PKI key hygiene, SLA adherence, and CP Registry accuracy.
• Peer review: The TAG SHOULD establish a lightweight peer review process where MAPs periodically verify each other's CP Registry accuracy, DNS record consistency, and endpoint availability. This can be automated through existing registry collection and DNS verification mechanisms.
• Evolving exit criteria: As the TAG updates onboarding entry and exit criteria to reflect new use cases and lessons learned, existing MAPs SHOULD be required to demonstrate compliance with material changes within an agreed adoption window.

#10.6.3 Version Adoption Policy

API versioning enables incremental change, but without adoption timelines the network could fragment:

• Minimum support window: When a new CSF version is released, MAPs MUST continue to support the previous version for six months from the release date, to allow all participants to upgrade.
• Deprecation notice: The TAG MUST provide at least 3 months' notice before deprecating a CSF version.
• Adoption tracking: The TAG SHOULD track which CSF version each MAP supports (visible in the CP Registry) and follow up with MAPs that have not adopted within the agreed window.

#10.6.4 Dispute Resolution

Disputes between MAPs (e.g., over CP ownership, message delivery failures, or onboarding decisions) need a resolution path that does not require legal action as a first resort:

• Tier 1 — Direct resolution: The MAPs involved attempt to resolve the dispute directly using the contact details published in their CP Registries.
• Tier 2 — TAG mediation: If direct resolution fails within 5 working days, either party can escalate to the TAG steering group, which will mediate at its next meeting. The TAG may appoint a subset of uninvolved MAPs to review the facts.
• Tier 3 — Independent adjudication: If TAG mediation fails, the dispute MUST be referred to an external, independent body appointed by the TAG to act as the standing Tier-3 adjudicator for the CSF. The adjudicator's decision is binding on the parties to the dispute. The TAG's preferred candidate for this role is the Office of the Telecommunications Adjudicator (OTA2) — see §10.2.1 — given its established independence and history of binding industry dispute resolution; the appointment is subject to formal acceptance by the candidate body. The TAG will engage the appointed adjudicator directly and provide the case file, supporting evidence, and the result of Tier 1 and Tier 2 attempts. Until an external Tier-3 adjudicator has formally accepted the role, the TAG SHALL document the route used for any Tier-3 case (typically bilaterally-agreed commercial arbitration between the parties) so the audit trail is unaffected.
• Interim measures: During any dispute, both MAPs MUST continue to exchange messages normally. A dispute MUST NOT be used as a reason to block or degrade service to CPs.

#10.6.5 Incident Response Coordination

While each MAP manages its own security, coordinated response to network-wide incidents is essential:

• Security contact: Each MAP MUST publish a dedicated security contact in its CP Registry (separate from general support) for reporting vulnerabilities and incidents.
• Coordinated disclosure: If a MAP discovers a vulnerability that affects the CSF specification or other MAPs, it MUST notify the TAG within 24 hours. The TAG will coordinate disclosure and remediation across all MAPs.
• Breach notification: If a MAP suffers a data breach that could affect CP data or message integrity, it MUST notify all connected MAPs, the TAG, and affected CPs within 72 hours of becoming aware, in alignment with the wider industry standard set by UK GDPR / Data Protection Act 2018 Article 33 personal-data breach notification. Notifications MUST include the nature of the breach, categories and approximate volume of data affected, the likely consequences, and the mitigations taken or proposed.
• Post-incident review: Significant incidents SHOULD trigger a post-incident review at the TAG steering group to identify systemic improvements.

#10.6.6 MAP Suspension and Removal

The CSF must have a clear, proportionate process for dealing with MAPs that persistently fail to meet their obligations or act maliciously:

• Warning: The TAG issues a formal written warning identifying the non-compliance and a remediation deadline (typically 10 working days).
• Probation: If the MAP fails to remediate, the TAG may place the MAP on probation. During probation, the MAP's status is flagged in other MAPs' Master Registries, and the MAP loses its voting rights in TAG decisions.
• Suspension: For serious or persistent non-compliance, the TAG may vote to suspend a MAP. Suspended MAPs' CPs are treated as if the MAP were in distress — the CP emergency migration process (see Commercial Scenarios) applies, and CPs are encouraged to move to another MAP.
• Removal: A suspended MAP that does not remediate within 30 days may be permanently removed from the CSF by TAG supermajority vote. The MAP's CP Registries are no longer collected by other MAPs.
• CP protection: At every stage, the priority is CP continuity. No enforcement action against a MAP should leave CPs unable to exchange messages for longer than necessary. The CSF's built-in ability to migrate CPs — including their in-flight orders — between MAPs via the RCPID Status export process (see CP Transitions) is an integral safeguard here. Where a MAP is suspended or removed, the TAG SHOULD proactively coordinate with affected CPs and receiving MAPs to ensure that the CP Emergency Migration Process (export inflight orders) is initiated promptly, in-flight order exports are completed before the MAP is taken offline, and CPs are re-established on new MAPs with minimal disruption to end consumers.

#10.6.7 Anti-Competitive Safeguards

The CSF's open, free-to-use nature must be actively protected:

• No exclusionary behaviour: No MAP or group of MAPs may act to exclude a legitimate new entrant from the CSF. Sponsor MAPs MUST NOT unreasonably refuse or delay onboarding.
• No preferential routing: MAPs MUST NOT give preferential treatment to their own CPs' messages over messages routed on behalf of other MAPs' CPs.
• No information misuse: Information obtained from other MAPs' CP Registries (e.g., CP lists, contact details, switching volumes) MUST NOT be used for competitive advantage, marketing, or customer solicitation.
• Telemetry collection: Every MAP MUST collect telemetry data for all messages sent and received between ACTIVE-status MAPs and on behalf of ACTIVE-status CPs only, including: message type (routingID), date/time, source CP (RCPID), destination CP (RCPID), source MAP, destination MAP, and delivery outcome (success, failure code). Messages where either endpoint MAP carries map.status = TEST or SUSPEND, where either CP carries processSupport[].status = TEST or SUSPEND, or where the JAM envelope's auditData carries the explicit test marker ({ "name": "test", "value": "true" }) MUST be excluded from telemetry counted toward industry statistics. This ensures that onboarding traffic, bilateral test runs, and post-incident soak testing never pollute reporting or KPIs. Telemetry data MUST be stored securely and handled in accordance with GDPR and the data retention policies agreed by the TAG. Test-flagged messages MAY still be logged separately for audit and onboarding evidence, but MUST be tagged as such and held outside the production telemetry corpus. See Onboarding & Testing Process §5 for the audit-flag rules and §4 for status semantics.
• Transparency: The TAG SHOULD publish an annual summary of CSF network activity — including aggregated message volumes by message type, number of active MAPs and CPs, onboarding activity, and delivery success rates — to demonstrate openness and healthy competition. Each MAP MUST contribute its aggregated telemetry to this summary, drawn solely from production traffic between ACTIVE participants as defined above. Individual CP-level data, message content, or commercially sensitive patterns MUST NOT be disclosed — only aggregated, anonymised statistics are published. Detaile on this will follow in subsequent revisions for options on how telemetry can be collected and shared without revealing sensitive data or breaching GDPR.

#10.6.8 CP Representation

While the CSF primarily governs MAP-to-MAP interactions, CPs are the ultimate beneficiaries and should have a voice:

• CP feedback channel: The TAG SHOULD establish a mechanism for CPs to raise concerns or propose improvements, either directly or through their MAPs.
• CP rights charter: The CP Rights Charter is published as a standalone document, written in plain language, so CPs can understand their entitlements without reading the full CSF specification. It is derived from the formal requirements in Principles & Requirements — CP Right to Move.

#10.6.9 Documentation and Transparency

• Public documentation: The CSF specification (this documentation) SHOULD be publicly accessible to any interested party, not restricted to MoU signatories. Transparency builds trust and encourages adoption.
• Change log: All changes to the CSF specification MUST be recorded in a versioned change log with dates, descriptions, and the TAG meeting reference where each change was agreed.
• Archived versions: Previous versions of the CSF specification MUST be retained and accessible so that MAPs running older versions can reference the specification they implemented against.

#10.7 Supporting Documents

The following documents support the CSF and are maintained separately: