Yesterday I was back on stage at the Open Source in Finance Forum in New York, presenting Governing the Agentic SDLC with Aaron Searle. It’s always good to be back at an OSFF, and it was great to see so many people in the room. Architecture and controls aren’t usually what fills a room, so I’ll take that as a sign that more people are asking the same question we are.
That question is: when AI agents are writing and reviewing the code, who decides which changes need a human?
Our answer is that the architecture should decide.
The Problem: Controls That Live in Someone’s Head
Most organisations already have SDLC controls: peer review, separation of duties, approved dependencies, evidence retention. What they rarely have is a machine-readable link between those controls and the system they’re supposed to protect. The rule “changes to anything that touches the client ledger need a second pair of eyes” usually lives in a CODEOWNERS file, a wiki page, or the memory of whoever has been there longest.
That was tolerable when humans wrote every change at human speed. It isn’t when agents can open dozens of pull requests an hour. If the controls aren’t tied to the architecture, either everything needs a human (and the agents gain you nothing) or nothing does (and you’ve built a zombie).
The Pieces
The demo brings three open source projects together:
- FINOS CALM (repo): the Common Architecture Language Model. It describes the system’s nodes, the connections between them, and the controls attached to each, all as versioned JSON.
- FINOS SDLC Common Controls (repo): a shared, open catalogue of software delivery controls, with IDs such as
SDLC-PREV-001(Code Review) andSDLC-PREV-017(Service Dependency Control), so the industry stops reinventing the same control frameworks. - ergo from Kosli (repo): an open source language for explainable policy-as-code that runs on Open Policy Agent. A plain pass or fail isn’t enough here. Every ergo decision comes with a report of what was checked, what value was read, and why each check passed or failed.
How It Works
The example system is a small trade capture platform: a Trade API, a Position Service, a Trade Store, and a Client Ledger as the book of record. The architecture is modelled in CALM, and controls from the SDLC Common Controls catalogue are attached to it. Some apply to the whole architecture, and some to individual nodes, such as a rule on the Client Ledger that any change to a service connected to it needs a human approver.
Each control holds its rule as an ergo policy. A merge gateway reads the architecture on main, runs every pull request against those policies, and posts an Architecture controls check. Because ergo explains its decisions, the gateway can tell the author why a change merged, needs a person, or was blocked, and it records each decision back onto the architecture as a CALM decorator.
The demo then plays out live:
- An agent adds an endpoint to the Trade API. The Trade API doesn’t touch the ledger, so the change merges automatically.
- An agent adds an endpoint to the Position Service, which writes to the ledger. The change needs Aaron’s approval, and the rule comes from the architecture, not a
CODEOWNERSfile. - An agent takes a shortcut and has the Trade API read the ledger file directly. That connection isn’t in the architecture, so the change is blocked.
- I add a designed connection from the Trade API to the Client Ledger, which takes the architecture to v1.1.0. Changing the architecture needs a human too, so Aaron approves it. The gateway then re-evaluates the blocked PR by itself. It no longer gets refused; it now needs a person, and it merges once Aaron approves.
That last step is the point of the talk: when the architecture changes, the controls follow. Nobody had to update a policy file, a CODEOWNERS entry or a runbook. The architecture was the policy.
Explainability Is the Feature
Auditors, risk teams and the engineers whose PRs get blocked all ask the same thing: why? A gate that returns false with no explanation gets bypassed or ignored. With ergo, each decision says which control applied, which component it was attached to, which commit was evaluated, and which check failed and why. That explanation goes into the PR comment and into the CALM decorator, so the evidence for SDLC-PREV-014 (Test Evidence Retention) is produced as a side effect of the gate doing its job.
Get the Code, the Slides and the Video
Everything from the session is in rocketstack-matt/agentic-sdlc-blueprint:
- All of the code from the demo: the CALM architecture and controls, the ergo policies, the merge gateway and the services. It runs locally with just Node and git, and
npm run demotakes you through the whole scenario. - The slides.
- A video of the demo, if you weren’t in the room or want to watch it again.
The pull requests from the live run are in rocketstack-matt/osffny-sdlc-calm, if you want to read the gateway’s explanations for yourself. It’s a teaching blueprint, not a product, so fork it, break it and tell me what you find.
ergo Is Heading to FINOS
Kosli have raised a contribution proposal to bring ergo into FINOS as a Labs project. I think it fits well. CALM describes the architecture, the SDLC Common Controls describe what good looks like, and ergo explains whether a change meets it. Having all three under the same open governance would make it much easier for banks, vendors and regulators to share one vocabulary for software delivery controls. If you have a view, add it to the issue.
And One More Thing: CALM Is on the Thoughtworks Tech Radar
To finish on some news: CALM has been added to the latest Thoughtworks Technology Radar (Volume 35) in the Assess ring of the Languages & Frameworks quadrant. The Radar describes it as providing “a machine-readable foundation for architectural compliance and programmatic governance”. That’s exactly what the demo above relies on, and it’s great to see it recognised outside the FINOS community.
If you’re at OSFF today, come and find me. If not, the repo is a good place to start.