Why we built this site — and the agentic project tracker behind it

A grant-funded consortium project, even a relatively focused one like Ai26.10, has hundreds of small obligations. The PIC PM Guide alone is around 80 pages. The Master Project Agreement is another forty. Schedule A defines milestones, deliverables, financial categories, change-control procedures. There are quarterly claim packages with hard deadlines on the 20th of April / July / October / January. There are Steering Committee meetings with a five-business-day notification requirement, an agenda template, a minutes template, and decisions that need to be routed and recorded. There are intellectual-property disclosures that have to go to the PIC Director of IP within a defined window. There are publication clearance reviews that have to go through Steering Committee with a thirty-day lead time.

Most of these obligations recur. They're knowable in advance. They don't require human creativity to handle correctly — they require somebody to remember to do them on the right day, in the right format, with the right cross-references.

So we built that somebody.

The directory at the centre of everything

If you peel back the website, the actual artifact at the centre of Ai26.10 is a directory called .project-state/ that lives in our repository. It contains, in plain YAML and JSON:

• A manifest.yaml declaring the project's identity — funder, program, project number, total value, dates, governing document.
• A state.json capturing the live status — current phase, RAG health, counters for milestones / risks / decisions / publications / claims, pointers to "next claim due" and "last SC meeting".
• A folder per entity type: milestones/, risks/, decisions/, people/, publications/, ip/, lessons-learned/, change-orders/, reports/, and so on.
• A cadence.yaml describing the recurring meeting rhythm.
• A documents/ tree that classifies everything we touch — proposals, signed schedules, PIC templates, working drafts.

Every file is small, plain text, version-controlled. Nothing about the project is hidden in someone's email or in a SaaS tool we don't control. If you want to know the truth about Ai26.10, you read this directory.

This site you're reading is just a view onto that directory. The dashboard reads state.json. The milestones page reads milestones/*.yaml. The risks page reads risks/*.yaml. The reporting page reads the docx and xlsx files we generated as the planning baseline. Within five minutes of any change to the directory, the change shows up here.

Why a directory beats a tool

We considered the tools. There's a generation of project-management SaaS — Asana, Linear, Monday, Notion, ClickUp, Smartsheet, MS Project. There's a slightly newer generation aimed specifically at grant-funded research consortia. They're all fine. None of them solved our problem.

Our problem wasn't tracking work. It was managing the obligations of a specific governance regime — the PIC PM Guide, our MPA, our Schedule A — over twelve months, while building a real product. SaaS tools assume your processes are flexible enough to fit their data model. Our processes are mandated, not flexible. And the cost of getting them wrong isn't a missed Linear deadline; it's a clawback on a $607K co-investment.

A plain-text directory does three things SaaS doesn't:

1. It's auditable. Every change is in git log. Every reviewer can see the provenance of every milestone update, every risk re-score, every decision.
2. It's portable. When the project closes and we have to hand the archive to PIC, we don't export it from somewhere. It already is the archive.
3. It's executable by an LLM. This is the bit that changes everything.

The agentic layer

Sitting on top of .project-state/ is a constellation of about twenty Claude skills, each owning a specific lifecycle area. The full list is on the Agentic State System page. The shortlist:

• project-state — the foundation. Schema-validated CRUD over the directory.
• project-orchestrator — the conductor. Decides what to do next based on the calendar.
• project-phase-gate — manages LOI → Approval → Planning → Execution → Closeout transitions.
• project-milestone-manager — milestone updates, percent-complete, technical progress.
• project-status-reporter — weekly reports, SC decks, status summaries.
• project-claim-prep — quarterly PIC claim packages.
• project-sc-meeting — full SC meeting lifecycle.
• project-change-register, project-publications, project-ip-tracker, project-document-curator, project-blog-publisher, project-onboarder, project-notifier, project-lessons, project-archive.

Each one is small. Each one knows how to read and write a slice of .project-state/. Each one has explicit inputs, outputs, and validations. Together they cover most of the recurring obligations of running a PIC-funded project.

What does that look like in practice? When somebody says "draft this week's status report", they're not opening a document template. They're saying it to a system that:

1. Reads the current state of every active milestone.
2. Reads the latest weekly retro notes.
3. Reads any decisions or risks that have changed since last week.
4. Composes a report against the project's standard format.
5. Writes it to reports/weekly/.
6. Surfaces it on this site within five minutes.

When somebody says "log the decision we just made about X", the system writes the YAML, increments the counter in state.json, links the decision to the relevant milestones and risks, and (optionally) drafts a notification to Slack and an entry for the next SC meeting agenda.

When the calendar hits April 15th and a quarterly claim is coming due in five days, the orchestrator surfaces it in the dashboard's "hot items" without anyone having to remember.

This wasn't the goal — but it might be the bigger artifact

Here's the thing. We didn't set out to build a generalized project-state system. We set out to build a fermentation AI. But the meta-project — running a PIC consortium for twelve months, hitting every obligation, having a full audit trail at the end — turned out to be tractable enough that we automated most of it, and the resulting system is reusable.

Ai26.10 is the first production deployment. We expect to use the same system on the next PIC project, the next NSERC project, the next IRAP claim. The infrastructure that helped us deliver the science is, in the long run, probably as valuable an output as the science itself.

Why the site, then?

Two reasons.

Communication. The team needs a clean window into the state of the project — one that's accurate, fast, and doesn't require a login dance. A static directory is great for the agents that maintain it. It's not great for a team member who just wants to know if M03 is on track.

Trust. A team trusts a system more when they can see what it's doing. When a milestone's percent_complete jumps from 30 to 45, the team should be able to look at the dashboard, see the change, click through to the milestone, see the linked technical progress note, and (if they want) jump to the commit that did it. The site closes the loop between the agentic system and the humans who depend on it.

What's next

A few things on the roadmap for the site itself:

• Weekly retros flowing into the blog automatically, with the meeting cadence and notes captured by project-blog-publisher after the Friday retrospective.
• Steering Committee artifacts surfaced as a first-class section under reporting once we have an SC pack.
• Live KPI charts wired up to the actual production data once M01 / M02 deliver the data infrastructure.
• The wiki glossary — extensive technical reference material on the AI stack, the digital twin, the soft sensors, and the math behind the controller. (See it under Wiki.)

For anyone reading this from outside Ai26.10: the structure is portable. If you're running a PIC project, an NSERC-funded consortium, or any other grant-driven research engagement, and you'd like to take this approach, get in touch. The skills are reusable, the schema is documented, and we'd happily talk through what worked and what didn't.

For the team inside Ai26.10: thanks for trusting this approach. Now let's go ferment something.