Purpose before collection
The organisation selects signal sources, purpose, access and retention. Indiscriminate collection is not the default design.
Roadmap architecture · SovereignEU Improvement Loop
Software designed to improve with your organisation—inside your boundary.
Every SovereignEU application is being designed to turn authorised usage and outcome signals into tested, traceable improvements within the customer-operated environment. A time-aware graph will connect workflows, content, permissions, dependencies and results; local AI is intended to identify opportunities and engineer candidate changes under controls defined by the organisation.
Status: Roadmap. The SovereignEU Improvement Loop is a planned shared capability, not a currently available autonomous production system. Its supported signals, change classes, evaluation gates and deployment conditions will be published with applicable releases.
A governed engineering system
An improvement loop—not uncontrolled production mutation.
Self-improving software does not mean code silently rewriting itself in production. It means an accountable pipeline can analyse approved evidence, prepare a candidate change in isolation, evaluate it, obtain the required authorisation, release a version and reverse it when necessary.
Evidence before change
Every proposal is intended to link back to its observations, hypothesis, candidate artefact and evaluation result.
Authority before release
Customer-defined policy controls what remains a suggestion, what needs named approval and what may follow a pre-authorised automatic path.
AI-based graph engineering
From local evidence to a reversible release.
Graph engineering loop is SovereignEU’s working term for a governed process that uses a time-aware graph to connect evidence about software, organisational workflows, proposed changes and measured outcomes.
Observe
Collect only application events, voluntary feedback, quality evaluations and outcomes authorised for a defined purpose.
Connect
Represent workflows, content, rules, dependencies, versions and outcomes in a time-aware evidence graph.
Diagnose
Local AI identifies repeated friction, missing knowledge, outdated rules and improvement opportunities with supporting evidence.
Engineer
Agents prepare bounded changes to content, retrieval, prompts, configuration, workflows, code or models in an isolated workspace.
Evaluate
Candidate changes run against customer-defined functional, security, privacy, accessibility, policy and regression criteria.
Authorise
Named people or narrowly scoped customer policies decide whether a candidate may be promoted and under which conditions.
Release and learn
Deploy a versioned change, monitor the intended outcome, retain the evidence and pause or roll back when required.
Measured outcome The observed result returns to the graph as new evidence; it does not prove that every candidate was an improvement.
The graph is the memory
Keep context across evidence, engineering and operation.
A temporal graph can preserve why a change was proposed, which version and policy applied, how it was evaluated, who authorised it and what happened after release.
Operational evidence
Connect permitted events and outcomes to the workflow, content, role, configuration and software version that produced them.
Engineering evidence
Relate each hypothesis to its candidate branch, changed artefacts, test data, evaluations, exceptions and approvals.
Outcome evidence
Compare released behaviour with a preserved baseline and keep pause, rollback and follow-up decisions reviewable over time.
Across the application portfolio
Each application is designed to learn from evidence relevant to its responsibility.
The organisation chooses which signals are enabled. These examples describe the planned direction, not current data collection or guaranteed outcomes.
Documents
- Authorised signals
- Authorised search, retrieval, correction, approval and lifecycle outcomes.
- Can propose
- Metadata, templates, retrieval quality and document workflows.
Knowledge
- Authorised signals
- Authorised queries, source changes, stale links and owner review decisions.
- Can propose
- Missing graph links, source-backed updates and knowledge-maintenance workflows.
Workplace
- Authorised signals
- Authorised authoring, collaboration, template and accessibility feedback.
- Can propose
- Templates, assistive actions, automations and workspace configuration.
Intranet
- Authorised signals
- Authorised searches, navigation paths, unanswered questions and maintenance outcomes.
- Can propose
- Information structure, discovery and editorial workflows.
Service Desk
- Authorised signals
- Authorised requests, routing corrections, escalations, resolutions and reopened cases.
- Can propose
- Triage, grounded guidance and bounded automation rules.
Projects
- Authorised signals
- Authorised planning changes, dependency evidence, blockers and delivery outcomes.
- Can propose
- Workflows, risk prompts, templates and reporting.
Risk-based autonomy
Automatic where authorised. Accountable throughout.
Observation, pattern detection, proposal generation and evaluation are designed for automation. Production promotion follows the autonomy level and release policy selected by the customer.
Recommend only
The loop records evidence and prepares an improvement proposal, but makes no operational change.
Human-authorised release
A named owner reviews the evidence and evaluations before a versioned candidate can enter production.
Policy-bound automatic release
Only predefined, low-risk change classes may proceed automatically after passing explicit tests, limits and rollback conditions.
Material changes remain governed. Changes to code, permissions, security controls, retention, model behaviour or consequential organisational decisions require stricter evaluation and explicit approval appropriate to their risk.
Intended on-premises boundary
The loop operates where the application operates.
For a verified customer-premises deployment, application signals, the temporal graph, model inference, engineering artefacts, evaluations and change history are intended to remain on customer infrastructure. Any external model, connector or support path must be selected and assessed separately.
- No customer content used for model training by default
- No cross-customer learning path planned by default
- Customer-controlled access, retention, pause and export
- No required SovereignEU telemetry path in the intended local mode
Workplace boundary
Improve software—not score employees.
The standard Improvement Loop is intended to improve application and workflow quality. It is not intended for covert monitoring, individual performance scoring, workplace emotion inference or automated employment decisions.
Customer-authorised application signals can still contain personal data; customer authorisation is not itself a legal basis. Their use requires a defined purpose, an appropriate legal basis, transparency, minimisation, retention and access controls, plus an impact assessment or worker consultation where applicable. On-premises operation supports a controlled data path; it does not create automatic GDPR or EU AI Act compliance.
A practical first step
Define what the software may observe, change and release.
Start with one workflow, its approved signals, acceptance tests and approval gates. Then choose what may be suggested, pre-authorised or always held for accountable human review.