The project site is now a live dashboard — here is how it works

As of this week, the Trusted Data Rail consortium has a password-gated project site at ledger-rail-project.netlify.app. This post is a build log: what the site shows, how it stays current, and why the architecture matters for how we work between now and the June 17 submission.

What is on the site

Seven pages, all reading from the same substrate:

• Overview — the project hero, a deadline countdown, and a live milestone progress board.
• Milestones — all 16 milestones from consortium lock to submission, each with a percent-complete bar, owner badge, task list, and at-risk flag.
• Decisions — the decision log. Every architectural or strategic decision recorded with date, rationale, made-by, and confidence rating.
• Risks — the risk register, sorted newest-first. Likelihood, impact, mitigation, and owner per entry.
• Team — consortium members grouped by organisation, showing DND 4807 role, formal discipline, and email.
• Documents — the full chain-of-custody index: every document the project has received, generated, or registered, with source, status, and significance.
• Proposal — a live DND 4807 checklist, described in detail below.

The site is password-protected. The password is solid. If you are reading this and do not have it, ask in #ledger-rt.

The project-state substrate

The site does not have a CMS or a separate data-entry layer. Every page reads directly from the .project-state/ directory: a set of YAML and JSON files that live alongside the proposal working document in the repository.

The structure is straightforward:

.project-state/
├── manifest.yaml          → project metadata, consortium, funder
├── state.json             → counters, phase, harvest cursors
├── milestones/*.yaml      → one file per milestone
├── decisions/*.yaml       → one file per decision
├── risks/*.yaml           → one file per risk
├── people/*.yaml          → one file per named investigator
├── orgs/*.yaml            → one file per partner organisation
└── documents/index.yaml   → chain-of-custody registry

Before each build, a sync script copies these files into a data/ directory inside the site. The build runs, Next.js server components read the YAML, and static HTML goes to Netlify. No database, no API token, no CMS login.

The practical consequence: updating a person's ORCID in people/ishtiaque-ahmed.yaml and triggering a build is all it takes to move a checklist item from amber to green on the proposal page. The site is a rendered view of the file system.

How information reaches the substrate

Three routes, roughly in order of how they have been used so far:

Meeting harvests. After each consortium call, the transcript or notes are placed in .project-state/documents/inbox/ and registered in the document index. From there, a harvester pass extracts decisions, risks, and milestone updates — turning a Google Meet transcript into structured state entries. The May 7 meeting, for example, produced four new risk files, a decision record (UofT no overhead, IP retained by consortium), and updates to seven milestone YAML files.

Inbox documents. The proposal working document itself lives in the project inbox. It is a Markdown export of the collaborative Google Doc — the master DND 4807 mirror document. When the document is updated and re-exported, the new version lands in the inbox and is registered. The proposal checklist page reads from the same people and org files, so any field filled in the source YAML shows up immediately on the checklist.

Slack and Gmail harvesting. The project has a dedicated Slack channel (#ledger-rt) and a Gmail harvest cursor. When a harvest runs, it reads new messages from the channel and relevant email threads, extracts signal-worthy items (partner confirmations, technical discussions, ecosystem signals), and writes them as structured documents to the inbox. This is how the April 30 kickoff transcript, the May 5 UofT lock confirmation, and the May 6 pitch-deck feedback all entered the state system without anyone having to manually log them.

The proposal checklist page

The /proposal page is the most directly useful part of the site for the next four weeks.

It mirrors all 16 parts of DND Form 4807 as a live checklist. Items are coloured by status: green for confirmed from state data, amber for pending or TBC, grey for not yet started. The status is computed at build time from the actual YAML files — there is no separate checklist to maintain.

At the top, a pre-submission compliance radar shows the mandatory gate items: lead institution, investigator eligibility, disciplinary mix, TRL declaration, GBA+ scenario, CPC Connect conversation, UofT Research Services sign-off. As of today, eight are confirmed, four are pending, eight are missing. That will change as the team fills in the corresponding YAML fields.

Part 9 (the investigator capabilities table) renders directly from people/*.yaml. When Ishtiaque's ORCID lands in his file, the amber ORCID TBC cell in the table turns green on the next build. Same for publications, hours per week, and total months.

Parts 3 through 13 and Part 15 are linked to drafting milestones (M09 through M12). As those milestones advance in percent-complete, the progress bar on each section moves. The page will show actual drafted content as soon as it lands in the state.

What this means for the next four weeks

The site exists to reduce the overhead of staying aligned across three organisations. Instead of status-update emails, link to the milestones page. Instead of asking who owns the SecDev legal name task, check the Part 2 partner block on the proposal page. Instead of wondering what decisions have been made about IP, read the decisions log.

The system updates on every deploy. Deploys happen on demand and take about 90 seconds. If you update a YAML file in the project state, post a note in #ledger-rt and someone can trigger a build.

The next build log — likely published after the May 28 meeting — will cover the first drafting pass on Parts 3 through 5.

— David Olsson, Atomic47