Technical approach
Shared maintenance. Local authority.
This note sets out how the proposed service would separate what participating Nations share from what each Nation controls. It describes a design to be validated with participating Nations, not a system in operation.
Hear this note in four voices
The same administrator, governance lead, builder and member work through it. Read the transcript.
Status: specification v0.1 and visual concepts prepared. No production network, enrolled Nation, endorsement, uptime record or security certification exists.
1 · Architecture
One operated service, many Nation spaces
The initial service would be centrally operated. Each participating Nation receives a Nation space: a logical access boundary inside that service, with its own administrators, roles, channels, members and approved applications.
- Managed core. Common account services, maintenance, updates, backups and the supported interfaces applications connect through.
- Nation space. Configured by the Nation's own administrators. One Nation's configuration does not change another's.
- Open clients. Independent applications connect through published interfaces. An application supports the features the interface defines, and every request is checked against the user's permissions; an application cannot widen them.
- Federation. Selected public content can be offered to other compatible nodes. It is a separate policy, off unless a Nation enables it, and it never carries restricted or member content.
Independent hosting by an individual Nation is a future pathway. It is not part of the initial service and is not presented as a delivered capability.
2 · Operators and access
Who can see what, including us
Access to content is decided by each Nation's sharing levels: Staff only, Nation members or Public. Public content is public; switching federation off stops it being sent to other nodes and does not make it confidential.
- Operator access is restricted and audited. Managed infrastructure needs people who can maintain it. Their access to Nation content would be limited to defined maintenance and support purposes, logged, and reviewable by the Nation.
- Coordination is not access. A coordinating body, including FSIN in a possible pilot, would not automatically gain access to private Nation records. A Nation grants access explicitly or not at all.
3 · Export, exit and pilot scope
A way out, designed in from the start
Export is part of the pilot foundation, not the roadmap. A Nation should be able to take its records, membership and files with it, in documented formats, and an exit arrangement forms part of the service agreement.
- Pilot foundation. Community channels, restricted staff spaces, member invitations, announcements, file attachments, notifications, local administration and export.
- Connected-service roadmap. Email and shared mailboxes, calendars and resource booking, collaborative documents, voice and video, departmental applications, finance and reporting integrations. A social feed is not a mailbox, an event post is not a booking service, and integration with financial systems keeps their controls.
- Existing systems. Departmental software already in use is assessed for integration. Nothing that works has to be replaced to take part.
- What a pilot would measure. Practical workflows with participating Nations, interoperability across independent clients, access-control tests and measured operations, before any expansion.
Transcript