Welcome to Trusted Data Rail

We started this project on the first of May, with a tight deadline and a thesis we believe in. The thesis, in one line: most of the AI assurance world is staring at the model, and missing the more basic question of what the model is being fed and what is coming out the other side. A Trusted Data Rail gives every data object a verifiable identity and lineage — who made it, under what conditions, what touched it, what it spawned. The pieces exist. Stitching them into a rail an operator in a contested environment can actually rely on is still open ground.

We could keep that work in shared drives, calendar invites, and inboxes. We've done it that way before. It's how good projects fall behind their own thinking — by the time you sit down to write the thing up, half of what you would have said is gone.

This blog is the place we'll write it down as we go.

What you'll find here

There are five kinds of post we'll be running. Not all in every cycle, but the mix should hold over time:

Architecture notes. What the rail looks like under the hood — signed state transitions, evidence graphs, post-quantum-aware checksums, the long tail of attestation primitives. These are the technical entries. They'll get nerdier than is polite.

Harvest dispatches. What the project's signal harvesters pull in each cycle — newsworthy items from the threat landscape, regulatory shifts, ecosystem signals (other DND IDEaS calls, NATO DIANA challenges, peer-reviewed work that intersects with the thesis). Short, tagged, dated.

Partner spotlights. Who we're working with and what they bring. The consortium is small — Atomic47, SecDev, the University of Toronto — but the surface area each partner exposes is broad. These posts give credit where it's due and put the right faces next to the right work.

Build logs. Milestones moving. Risks closing. Decisions made and the reasoning behind them. Less "we shipped" and more "here's what we learned." If a milestone closes flat, we'll say so. If a risk materialises, we'll write the autopsy.

Editorial. The longer pieces — half-essay, half-position-paper — about why data-side assurance matters, what we mean by "calibrated trust," and where we think the field is going wrong. These are the pieces we'd want to write whether we were running this project or not. They'll be slower to produce and worth the wait.

Rhythm

The newsletter ships weekly on Thursdays. Not because Thursday is special, but because we already do a Thursday consortium check-in, and the discipline of having a publication deadline immediately afterward forces the writing to happen while the conversations are fresh.

Each weekly issue is one substantive post plus a short links-and-signals section. Outside the weekly cycle we'll publish architecture notes and editorial pieces as they're ready — those don't follow the calendar, they follow the work.

If you subscribe (form below, or further down the home page), you'll get the weekly via email. If you'd rather just check in, the blog itself is the canonical archive. We're publishing to the web first; the email is a courtesy.

Who writes here

The named bylines you'll see most often:

• David Olsson (Atomic47) — project lead, harvest curator, most of the architecture notes.
• Fulvio Ciano (Atomic47) — CTO; the cryptography and post-quantum pieces are his.
• Rafal Rohozinski (SecDev) — operator-side framing, threat-model context, defence and IC perspective.
• Ishtiaque Ahmed (University of Toronto, Third Space) — HCI / AI intersection, accountability, the trust-calibration research side.

Other named contributors will appear as the consortium pulls them in. Co-bylines are normal and welcome.

Editorial discipline

Three rules we're holding ourselves to:

1. Publish review-not-author. First drafts get circulated internally before any public post. The consortium reads the working draft, points out what's wrong, and the published version is the one that survived that pass. This is a discipline borrowed from how we've run prior multi-stakeholder projects, and it works.
2. Cite our sources. When a post references a paper, a regulatory filing, a piece of correspondence, or a piece of code, the link is in the post. The rail is a thesis about provenance — it would be hypocritical to publish here without it.
3. Don't publish anything that can't be defended in the open. This blog is consortium-internal today, behind an access gate. That means we can be candid in ways a public site couldn't. But we'll write each post as if it might one day be public — because at some point, after the project announces, much of it will be.

A note on access

This site is password-gated and unlisted in the community index. It exists to give the consortium a single shared archive of how the work is moving without the overhead of email distribution lists, doc-sharing permissions, or "is this the latest version" — link to a post, the link is current.

The reading audience is the consortium plus invited stakeholders. If you've been given the password, you're invited. If you've stumbled here through some other route and don't have the password, the front door is the front door — there's no back gate.

Issue zero

This is the welcome. The next post — issue one — will be a working architecture note on what we mean by signed state transitions over a structured evidence graph, since that phrase has been the through-line of every internal conversation since the project started. After that, we'll find the rhythm.

Subscribe below. Or don't, and check back when you're curious.

Either way — glad you're here.

— David Olsson, on behalf of the Trusted Data Rail project