One enclosure. Six products.
Every Veldris product runs inside the Midgard enclosure and inherits its guarantees: post-quantum sealing, signed lineage, local inference, zero required outbound calls. Each is independently useful. Together they compound.
The enclosure
Midgard Core is the enclosure layer: identity, the object fabric, storage, compute, governance and post-quantum cryptography inside one defended trust boundary. It is the part our competitors call the substrate, and the part they will not show you.
Standing on it
A first deployment is Midgard Core with Mimir and Forseti: AI on sensitive data, with the evidence to prove what it did. The rest expand from there.
Forge · data operations
Forge shapes. Pipelines are declared, versioned and replayable; every transform records its inputs, its code hash and its outputs. Nothing derived loses its lineage.
competes with Palantir FoundryForge →Mimir · local agentic AI
Mimir remembers. Every inference runs on your hardware, under keys only you hold, on approved models pinned by hash. First token in under 800 ms on reference hardware, or none at all.
competes with Palantir AIPMimir →Bifrost · continuous delivery
Bifrost carries. Signed releases travel from build to enclosure with the SBOM attached; nothing deploys that cannot prove where it came from, including across an air gap.
competes with Palantir ApolloBifrost →Heimdall · operational fusion
Heimdall watches. Live feeds fuse into one operational picture where every object on the map traces to its source, connected or disconnected.
competes with Maven Smart System · GothamHeimdall →Gungnir · decision projection
Gungnir strikes ahead. The downstream effects of a decision, projected against live, governed data before it executes, with confidence stated per branch.
replaces offline modellingGungnir →Forseti · assurance
Forseti judges. Signed provenance, named algorithms and inspectable audit lineage for every output, exportable as evidence an accreditor can check.
replaces vendor attestationForseti →The software, recorded
Screen recordings of Forge, Heimdall and the Midgard console, captured in October 2026 from development builds of the public source, newest first: the code behind them is in the midgard-app repository and anyone can build it. All are silent and served from veldris.io, with no third-party player. Counts, tracks, alerts, checks and audit entries are those on screen at the time of recording.
Forge: a new source in, a bad file stopped at the gate
The recording opens on Forge's pipeline view for aircraft: ADS-B positions for the UK and Ireland pulled over HTTPS from adsb.lol every 15 seconds, parsed into 19 typed columns, kept as a versioned dataset of 326 rows and projected into Midgard as 326 live aircraft objects. The side panel shows how it is protected: AES-256-GCM with ML-KEM-1024 at rest, X25519 with ML-KEM-768 in transit, and lineage signed with ML-DSA. Run now re-runs the pipeline and reports it unchanged: nothing has altered since the last sync, so nothing is synced again.
The connector catalogue lists 11 connectors, all healthy, and 0 outbound paths. Each one's trust boundary is spelled out: inbound pull only, no egress.
The operator then adds a source of their own: a CSV of 18 River Thames monitoring stations. Forge previews the file, proposes a type for every column, and asks for an object type name, a key column, the latitude and longitude, a schedule and a marking, which is required. One click creates the connector and runs it. The file is sealed in the worker, the new object type joins the ontology, and the run writes a sealed version and projects 18 station objects into Midgard over post-quantum mutual TLS, with nothing quarantined.
Next, a rule. In data health, 24 checks are passing. The operator adds an expectation that every station's latitude lies between -90 and 90, and marks it blocking: if it fails, the projection stops and Midgard keeps the last good version.
Then the file is replaced with one carrying a bad latitude. Forge still seals the new version, but the check fails on one row, that row is quarantined, and nothing is synced: the connector shows projections blocked, data health shows 25 checks with 1 failing at a 94.4% pass rate, and the quarantine preview names the row, Radcot Lock, with a latitude of 95.699764. Replacing the file with the correct one clears the block, and Forge reports the data unchanged from the version Midgard already holds.
The dataset browser closes the recording: 12 datasets, every one sealed on its main branch, with the station dataset's schema, its lineage from upload to 18 objects, and both versions kept. Time travel compares them by station reference: nothing added, nothing removed, one value changed, the latitude that was blocked.
| On screen | Where to look |
|---|---|
| Pipeline | adsb.lol → aircraft.csv → aircraft → aircraft_live |
| Trust boundary | inbound pull only · 0 outbound paths |
| New connector | Upload a CSV, in the connector catalogue |
| Blocking expectation | -90 ≤ lat ≤ 90 · 1 row quarantined |
| Projection gate | Data health: 94.4% pass rate, projection blocked |
| Time travel | +0 added · -0 removed · ~1 changed |
One fabric, every record governed and signed
The recording opens on the Midgard console's object fabric: 22 object types holding 41,278 instances, with 100% of their lineage signed. Each type lists its properties, instance count and marking, from live air-quality sensors and aircraft to flood warnings, grid frequency, Heimdall alerts and operators. Airport is marked restricted; most types are internal.
Selecting Airport shows what the type allows. Its link types tie an airport to a region and an operator, and its actions (open or close an airport, set the alert level, issue an advisory, divert inbound traffic) each carry a human gate: none runs until a person authorises it. A search for Heathrow returns London Heathrow Airport, and the audit lineage beneath fills in live as the operator reads, every entry signed ML-DSA-65.
The operator then follows the links: a METAR weather report for Heathrow, reviewed through an authorised action; Heathrow's runway 09R/27L, where open or close is a human-gated action; and a Heimdall power-cut alert raised from the distribution network operator's report, whose triage is authorised and recorded, linked to the power cut it reports.
Governance closes the recording. Policies and markings lists 24 enforced policies across 4 marking levels, each shown as a declarative rule, and a dry-run evaluates a request against them, denying by default. The audit lineage holds every record from the session, from the operator's reads to Heimdall's record syncs, append-only and verified, with each entry chained to the one before it and exportable as a chain.
| On screen | Where to look |
|---|---|
| Object types | 22 types · 41,278 instances · 100% lineage signed |
| Human gates | The Action types list for Airport and Runway |
| Linked records | Weather report, runway and power-cut panels on the right |
| Policies | 24 policies · 4 marking levels · dry-run |
| Audit lineage | append-only · ML-DSA-65 signed · chain export |
London traffic: from the road network to one vehicle
The operating picture opens over the south of England with the land layer on, then closes in on London. The road network is coloured green, amber and red by traffic state, and the city's traffic cameras sit on it as objects in the picture.
Selecting the A12 Dyers Hill camera opens its record: the camera's details and a current still. Opening the clip brings up AI analysis of the footage. Every vehicle is boxed and labelled, and the panel beside it counts what is moving and what is stationary, which way the traffic flows, and how the counts have trended across recent results. People are pixelated.
The operator picks one car and follows it. At the next camera along the A12, Church Lane, Heimdall matches the same car as probable, with a confidence of 0.95, and the follow carries across both cameras.
The clip then opens in the enhancement studio, with a before-and-after split. Presets choose between fidelity, classical sharpening and AI enhancement, and each effect, from levels and contrast to upscaling and motion deblur, can be switched on or off and tuned on its own.
| On screen | Where to look |
|---|---|
| Road traffic | The road network over London, coloured by traffic state |
| Camera record | A12 Dyers Hill, in the right-hand panel |
| AI analysis | moving · stationary · flow · trend |
| Following | CAR 6 · probable (0.95) · 2 cameras |
| Enhancement | The studio, with before and after side by side |
Traffic camera imagery: Transport for London JamCams. Powered by TfL Open Data.
Gulf watch: indicators that explain themselves
The recording opens on a public social media post. Heimdall treats social channels as cueing signals: a prompt to look somewhere, which the operator then checks against the governed feeds in the picture. Behind it, the UK and Ireland carry weather and flood warnings pinned to the map alongside their validity windows. The operator follows the cue and moves the focus to the Gulf and brings up the air, events and land layers over satellite imagery.
The Gulf watch panel lists a set of indicators, each measured against a baseline Heimdall has learned for it: civil aircraft over Iraq is rated elevated, GPS interference around the Gulf is still learning, and shipping through the Strait of Hormuz reads normal. Selecting an indicator opens its record: the count now against the normal count and the window it was learned over, its sources, its first sighting and its observations. Nothing on the panel is an unexplained dot.
Asked what has changed in the Gulf watch, Mimir answers in plain language beside the map, from the governed objects in the picture and on local inference.
| On screen | Where to look |
|---|---|
| Social cue | The post that opens the recording |
| Regional focus | UK and Ireland, then the Gulf, from the Regions rail |
| Baseline indicators | elevated · learning · normal |
| Indicator record | Kind, status, baseline window, sources, observations |
| Decision support | Mimir, in the Live picture panel |
From the UK to Western Russia, in 3D
The operating picture tilts into 3D over the UK and Ireland, dense with live air, rail and maritime tracks, while the classification rail counts every object by type and the airborne, on-ground and median altitude figures update with it.
The operator then brings Western Russia into focus. Satellite imagery resolves under the cloud layer, tracks fill in from the newly relevant feeds, and restricted, prohibited and danger airspace rises from the map as 3D volumes, so a track's position against a boundary reads at a glance. The fused feed count in the header climbs from 15 to 20 as the region comes in, and feed authentication stays post-quantum throughout.
| On screen | Where to look |
|---|---|
| 3D picture | The 3D control on the map toolbar |
| Airspace volumes | Extruded over Western Russia |
| Feed status | feeds fused · feeds PQ-auth · sync local |
| Classification | The right-hand rail, click to filter |
If you know their stack
| They sell | We publish | The difference |
|---|---|---|
| Foundry substrate · Ontology | Midgard Core | Open source, self-hosted, post-quantum sealed, air-gap native. |
| Foundry | Forge | Declared, replayable pipelines with signed lineage on every object. |
| AIP | Mimir | Local inference only. Models pinned by hash. No cloud, ever. |
| Apollo | Bifrost | Reproducible builds, signed SBOM per release, offline delivery bundles. |
| Maven · Gotham | Heimdall | Every fused object carries provenance you can open and read. |
| Offline modelling | Gungnir | Decision effects projected against live, governed data. |
| Vendor attestation | Forseti | Signed provenance and evidence packs anyone can verify. |
Each stands alone. Together they compound.