Sovera
Concept stage: seeking pilot and R&D partners
Find Public-Sector Knowledge Where It Lives
Across Organizations, Without Moving It
Civil servants should not have to rebuild the same solution in every municipality, ministry, or safety region. Sovera is a concept for a sovereign, federated search and work layer that would let authorized staff query knowledge across participating organizations, while data stays at the source, under local control.
The Structural Problem
Public organizations hold vast policy knowledge, case experience, and operational insight—fragmented across systems, departments, and jurisdictions. The result is duplicated effort, slow coordination, and blind spots on complex cases.
Purpose limitation and data minimisation under GDPR Article 5, confidentiality duties, and BIO security requirements make indiscriminate central copies a poor fit. Cloud copilots and generic search tools lack the federated authorization government work needs.
Reinventing the wheel
When one municipality solves a housing, debt, or youth-care challenge, others rarely benefit. Peers start from scratch on problems already addressed elsewhere.
Legal limits on centralization
Sensitive public data cannot simply be pooled. Separate transparency regimes such as the Woo address public access to government information and are not primarily an anti-centralisation framework.
Tools that do not fit government work
Cloud AI copilots cannot handle much of what civil servants work with daily. Generic search lacks federated authorization. Custom ETL pipelines are slow, expensive, and hard to maintain.
Proposed Design: Local Authorization and Owner-Controlled Access
Sovera proposes rights-aware orchestration at each local node. Search could reach across organizations; data would not move unless policy explicitly allows it.
Data Stays at the Source
Source documents and local indexes remain under the control of the organization that owns them. Only authorized query and result data would cross organizational boundaries.
Authorization Before Disclosure
Every node would evaluate the requester’s RBAC/ReBAC rights locally. A matching result would only be returned when the requester already has permission to access it.
No Hit Signal in the Requester’s Context
If there is no match, nothing is returned. If there is a match but the requester lacks access, exactly the same happens: no content, title, metadata, hit count or status enters the requester’s search context—no requester-side existence disclosure.
Separate Owner-Side Access Workflow
For an inaccessible match, a separate AI-assisted process could contact the document owner, explaining who needs access and why. The owner could approve, deny or request clarification. A denial would remain invisible in the original search; only after approval could the result become available.
How It Is Intended to Work
From a civil servant’s perspective, the proposed design would orchestrate secure, decentralized retrieval in six steps:
Natural Query
The user asks a question in their own secure workspace.
Federated Search
Participating nodes independently search their local indexes.
Local Rights Evaluation
Each node checks both relevance and the requester’s RBAC/ReBAC permissions.
Authorized Result or Silent Response
Authorized matches are returned with provenance. No match and inaccessible match both return nothing to the requester.
Separate Owner Decision
For an inaccessible match, the document owner may receive a separate AI-assisted access request. The owner can approve, deny or ask for clarification without exposing the document.
Delivery After Approval
Only after access is granted can the result enter the requester’s workspace.
Candidate Pilot Scenarios
The first Sovera pilot has not yet been selected. We are looking for public-sector partners to identify one concrete, valuable and legally manageable use case together. The scenarios below illustrate possible directions, not existing Sovera capabilities.
Learning From Peer Municipalities
A municipality faces a novel challenge, say implementing a new social-domain policy. Today, teams often start from scratch. In a Sovera pilot, a policy officer could search federatively across opted-in municipal sources: internal memos stay internal, while published guidance and shared practices from other gemeenten could surface.
Together with a pilot partner, we would select one bounded use case based on public value, available sources, legal feasibility, measurable outcomes and willingness of participating data owners.
What Still Needs to Be Researched and Validated
Sovera is a concept. Before any production deployment, the following would need joint validation with pilot and R&D partners:
Federated retrieval
Relevance, latency, and reliability of cross-organizational search without central indexes or data lakes.
RBAC/ReBAC at the node
Correct local evaluation of requester rights so only authorized matches leave the owning organization.
Owner-controlled access workflows
AI-assisted requests that inform owners without leaking existence or content into the requester’s search context.
Privacy, legal fitness and assurance
Purpose limitation, logging, and a valid legal basis for each use case—plus future conformance testing, security assessment and third-party assurance. Technology does not create permission to share.
Relationship to FDS and Current Policy
The concept would build on Prometheon’s existing work in sovereign, on-premises knowledge search. The proposed federated layer would be designed to implement relevant FDS principles and standards—as an agreements framework, not as a network or platform—so authorized queries could reach outward across Diginetwerk and other approved networks, never through a central data broker.
Policy direction is clear: the Interadministrative Data Strategy (IBDS) and the FDS agreements framework need working tools, not only paper agreements. At the same time, the government’s Microsoft 365 Copilot DPIA identified significant risks concerning transparency and control over personal-data processing. A sovereign, federated concept addresses both gaps.
Designed around relevant FDS principles
Participating Sovera nodes would implement relevant FDS agreements and standards across:
Identity
Requester identity and organizational context under agreed trust patterns.
Secure exchange
Query and authorized result traffic over approved government networks.
Metadata
Minimal, purpose-bound discovery metadata without exposing shielded content.
Local control
Each data owner retains policy, indexing scope, and authorization on their node.
Logging
Auditable records of queries, access decisions, and owner-side requests.
Provenance
Returned results carry clear source attribution.
Proposed Open-Core Model
To support sovereign public infrastructure and prevent vendor lock-in, Sovera is proposed to follow an open-core model. Until repositories are published, open source describes the intended model—not available components today.
Open Source Base Node
The base node and REST API profile are intended to become open source. When published, this page will link directly to the repository.
Commercial Enterprise Modules
Prometheon would license premium components, including advanced AI orchestration, legacy data adapters, and extended ReBAC authorization models.
Future Conformance and Assurance Services
Future conformance testing, security assessment and third-party assurance would help ensure deployed nodes align with the Sovera standard and relevant BIO requirements.
Partner With Us
Two paths are open—starting from a real operational problem, not a slide deck.