This page describes our research agenda. Status labels show what is planned, in progress or complete.
HOPN Lab
Trustworthy AI under constraint.
How do we build AI systems that organizations can trust, audit and afford to run themselves?
HOPN Lab studies AI systems that stay reliable, private and verifiable under real-world constraints: limited compute, no cloud access, sensitive data, regulated domains and physical safety. Our work is organized as three layers (Route, Ground, Assure), one foundation program and one physical-world track.
Why it matters
- Frontier labs optimize capability at scale. Few groups own the question of verified deployment under constraint.
- In Europe, GDPR, the EU AI Act and data sovereignty make constraint a requirement, not a weakness.
- We publish our protocols and raw logs, and we disclose our commercial relationships.
Vision
A lab that builds AI organizations can trust, audit and run themselves under constraint.
The agenda is to design inspectable systems: policies you can read, knowledge you can source, quality you can refuse, compute that stays inside the organization, and monitors where a wrong move is physical.
The lab designs and studies five research objects. They are planned artifacts on the agenda, not products with published measurements.
Lab objects (conceptual)
Five illustrated research objects: Route policy, Ground provenance graph, Assure quality contract, Foundation private-compute stack, Physical runtime monitors. Each links to its program page. Conceptual. No measured values.
- Route policyThe Route policy: a decision object that chooses a provider under cost, latency, privacy and quality rules.
- Provenance graphThe Ground provenance graph: a knowledge object that records what the system knows and where it came from.
- Quality contractThe Assure quality contract: a control object that decides whether an output is good enough before it ships.
- Private-compute stackThe Foundation private-compute stack: an efficiency object for quality per watt and per euro when data stays inside the organization.
- Runtime monitorsPhysical runtime monitors: safety objects that apply the same stack where errors have physical consequences. Planned paths are D1 to D4.
View as table
| Object | Program | Role | Status |
|---|---|---|---|
| Route policy | Route (Track A) | The Route policy: a decision object that chooses a provider under cost, latency, privacy and quality rules. | In progress |
| Provenance graph | Ground (Track B) | The Ground provenance graph: a knowledge object that records what the system knows and where it came from. | In progress |
| Quality contract | Assure (Track C) | The Assure quality contract: a control object that decides whether an output is good enough before it ships. | Planned |
| Private-compute stack | Foundation (Track F) | The Foundation private-compute stack: an efficiency object for quality per watt and per euro when data stays inside the organization. | In progress |
| Runtime monitors | Physical (Track D) | Physical runtime monitors: safety objects that apply the same stack where errors have physical consequences. Planned paths are D1 to D4. | Planned |
Research architecture (conceptual)
Stacked diagram. Route, Ground and Assure are layers from top to bottom. Foundation is the base. Physical is the side track. Each block links to its program page.
How do we compose many models and providers behind one reliable interface?
Policy-driven routing across cost, latency, privacy and quality
Layer 2Ground (Track B)What does the system know, and how do we prove where it came from?
Provenance-first knowledge graphs
Layer 3Assure (Track C)How do we know each output is good enough, at runtime, before it ships?
Quality orchestration with contracts and service levels
What quality per watt and per euro is possible when data never leaves the organization?
Private and efficient AI
How do Route, Ground and Assure apply where errors have physical consequences?
Verified physical autonomy
Route: How do we compose many models and providers behind one reliable interface? Ground: What does the system know, and how do we prove where it came from? Assure: How do we know each output is good enough, at runtime, before it ships? Foundation: What quality per watt and per euro is possible when data never leaves the organization? Physical: How do Route, Ground and Assure apply where errors have physical consequences?
View as table
| Block | Place | Question | Direction |
|---|---|---|---|
| Route | Layer A | How do we compose many models and providers behind one reliable interface? | Policy-driven routing across cost, latency, privacy and quality |
| Ground | Layer B | What does the system know, and how do we prove where it came from? | Provenance-first knowledge graphs |
| Assure | Layer C | How do we know each output is good enough, at runtime, before it ships? | Quality orchestration with contracts and service levels |
| Foundation | Base | What quality per watt and per euro is possible when data never leaves the organization? | Private and efficient AI |
| Physical | Side track | How do Route, Ground and Assure apply where errors have physical consequences? | Verified physical autonomy |
Track A · In progress
Route
How do we compose many models and providers behind one reliable interface?
Track B · In progress
Ground
What does the system know, and how do we prove where it came from?
Track C · Planned
Assure
How do we know each output is good enough, at runtime, before it ships?
Track F · In progress
Foundation
What quality per watt and per euro is possible when data never leaves the organization?
Track D · Planned
Physical
How do Route, Ground and Assure apply where errors have physical consequences?
End-to-end pipeline (conceptual)
Flow: Extract, Ground, Route, Assure, Learn. Learn feeds back into Route and Assure. Each step links to a program page.
Feedback: Learn → Route and Assure.
View as table
| Step | Order | Opens |
|---|---|---|
| Extract | 1 | /research/ground/ |
| Ground | 2 | /research/ground/ |
| Route | 3 | /research/route/ |
| Assure | 4 | /research/assure/ |
| Learn | 5 | /research/assure/ |
| Learn to Route / Assure | Feedback | /research/assure/ |
Project to program mapping
Rows are public projects. Columns are programs. A marked cell means the project contributes to that program.
| Project | Route | Ground | Assure | Foundation | Physical |
|---|---|---|---|---|---|
| AI-Pass | Linked | No | No | No | No |
| TEAOA | Linked | No | No | No | No |
| SLDE-AFT and offline LoRA extraction | No | Linked | No | Linked | No |
| Semvec | No | Linked | No | No | No |
| ServAlign | No | No | Linked | No | No |
| Invoice automation | Linked | Linked | Linked | No | No |
| Sovra | No | Linked | No | Linked | No |
View as table
| Project | Route | Ground | Assure | Foundation | Physical | Role |
|---|---|---|---|---|---|---|
| AI-Pass | Yes | No | No | No | No | Infrastructure layer for the other tracks |
| TEAOA | Yes | No | No | No | No | Trust model for orchestration |
| SLDE-AFT and offline LoRA extraction | No | Yes | No | Yes | No | Corroborated extraction feeding the knowledge graph |
| Semvec | No | Yes | No | No | No | Temporal and versioned memory |
| ServAlign | No | No | Yes | No | No | Constraints and policy as machine-checkable objects |
| Invoice automation | Yes | Yes | Yes | No | No | Shared testbed |
| Sovra | No | Yes | No | Yes | No | Compute-spectrum efficiency, private RAG, graph pruning |
Twelve-month plan (summary)
Agenda status (plan counts)
Bar lengths are counts of programs, roadmap items and planned artifacts marked planned, in progress or done. These are agenda counts, not measured results.
Click a status to highlight matching plan rows. Counts are agenda status, not measurements.
Status: Planned (pattern), In progress (accent border), Done (filled).
View as table
| Status | Count |
|---|---|
| Planned | 12 |
| In progress | 7 |
| Done | 0 |
Twelve-month roadmap
Horizontal bars mark intended start and end months on a 0 to 12 scale. Status labels sit beside each bar, not inside it. Status comes from the data file.
0 to 3 months | 3 to 6 months | 6 to 12 months
AI-Pass submission
Route
0 to 2 months · In progress
Quality orchestration charter and shared invoice benchmark
Assure
0 to 3 months · Planned
Simulation baseline with fault injection (ROS 2, Gazebo)
Physical
0 to 3 months · Planned
Graph-pruning study
Ground
3 to 6 months · Planned
First quality-routing results
Assure
3 to 6 months · Planned
Sovra raw data and scoping
Foundation
0 to 3 months · In progress
Status: Planned (pattern), In progress (accent border), Done (filled).
View as table
| Item | Program | Months | Status |
|---|---|---|---|
| AI-Pass submission | Route | 0 to 2 | In progress |
| Quality orchestration charter and shared invoice benchmark | Assure | 0 to 3 | Planned |
| Simulation baseline with fault injection (ROS 2, Gazebo) | Physical | 0 to 3 | Planned |
| Graph-pruning study | Ground | 3 to 6 | Planned |
| First quality-routing results | Assure | 3 to 6 | Planned |
| Sovra raw data and scoping | Foundation | 0 to 3 | In progress |
Planned measurements
Planned measurements
Empty axes chart. Each series is a planned metric from the data file. Values read from research-results.json. Series stay pending until a measurement exists. No invented points.
Measurements pending
View as table
| Program | Metric | Value |
|---|---|---|
| Route | Routing regret | Pending |
| Route | Cost per request | Pending |
| Route | Latency overhead | Pending |
| Route | Policy-violation rate | Pending |
| Route | Time to onboard a provider | Pending |
| Ground | Provenance coverage | Pending |
| Ground | Contradiction rate | Pending |
| Ground | Update cost | Pending |
| Ground | Answer accuracy per unit of graph size | Pending |
| Assure | Cost per correct answer | Pending |
| Assure | Abstention-adjusted accuracy | Pending |
| Assure | Calibration error | Pending |
| Assure | Escalation rate | Pending |
| Assure | Time to detect drift | Pending |
| Foundation | Quality per watt | Pending |
| Foundation | Quality per euro | Pending |
| Foundation | Locality constraint adherence | Pending |
| Physical | Mission completion under injected faults | Pending |
| Physical | Time to re-plan after losing an agent | Pending |
| Physical | Unsafe-plan interception rate | Pending |
| Physical | False-block rate | Pending |
How we publish
The lab publishes an agenda and, later, artifacts. We do not present unpublished numbers as results.
HOPN Lab evidence disciplineGovernance
Conflict-of-interest, dual-use and safety wording is prepared and will be published after director review.
HOPN Lab
Work with HOPN Lab
Enterprise buyers, academic collaborators, students and funders in Europe can write to us.