---
title: "Changemkr: four systems became one platform"
description: "Four inherited systems became one AI platform for change management, around one schema authority with gates that hold it. Measured to June 2026."
url: https://torn.studio/en/work/changemkr-four-systems-one-platform
locale: en
published: 2026-09-01
updated: 2026-06-30
---

# Changemkr: four systems became one platform

> **Short answer:** Torn Studio held the product role at Changemkr and owns part of the platform. Four inherited systems became five deployed services around one schema authority of 63 tables, and eight AI environments share a single LangGraph service with versioned prompts. This page describes the work up to June 2026, where the studio’s period ended.

**Client:** Changemkr · **Delivered:** 2026-06-30

**The studio’s relationship to the client:** Changemkr is a platform Torn Studio owns part of. The studio held the product role from January 2025 to June 2026 — first as CPO, later on a fractional basis — and built in the codebase alongside the role. Work after June 2026 belongs to others and is left off this page.

## The brief

Changemkr needed one platform where survey, analysis, planning and follow-up hung together, with AI running through the whole chain. The product then lived in four codebases that had grown apart and described the same concepts differently.

## What made it hard

- The planning hierarchy existed as seven separate models in a Django API, and the same word meant different things across the four systems — one change took four edits by four people who each read the model differently.
- The AI layer spoke its own vocabulary, so the assistant proposed objects the canvas could not accept. That was one of two blockers standing before launch.
- The Python service’s database models were maintained by hand beside the TypeScript-defined schema, so the two descriptions of the same tables could drift apart silently.

## Figures a reader can count

| Figures a reader can count | | |
| --- | --- | --- |
| 4 | inherited systems merged | The migration report in the repository lists them one by one, with what each owned and what replaced it. A build script holds imports from them at zero. |
| 63 | tables under one authority | Countable in the schema directory at the June boundary. The Python models are generated from the same definition, and a gate fails the build once they diverge. |
| 5 | deployed services | Web, business API, AI service, admin console and a job runner. All five appear in the repository’s compose file and in the Azure infrastructure code. |
| 8 | AI environments on one service | Countable in the prompt registry. Each environment carries its own model, its own tool set, and its own prompt versioning with one-click revert. |
| 80 | end-to-end specification files | Countable in the test directory at the June boundary. The page quotes the file count, because the repository has itself withdrawn its pass-rate figure from that period. |

## How it was done

### One schema authority, everything else derived

Drizzle was made to define all 63 tables, and the Python service’s models are generated from that same definition by a script. A build gate compares the generated file with the committed one and fails on divergence, so two systems describing one table differently cannot be committed.

### Hard domain boundaries

NestJS owns business data — accounts, organizations, surveys, plans. The Python service owns the AI domain — threads, embeddings, memory, the supervisor. The web app calls both directly, and the boundary is written in plain language in the repository’s instruction file, which makes it a decision other people can follow.

### Seven models became one

The planning hierarchy was reshaped into one table with a type discriminator, plus a table for key results and one for relationships. The vocabulary was closed, and the AI layer was made to speak exactly the words the canvas uses. The blocker covering that closed on the tenth of June 2026.

### Gates carry the boundaries

One script holds imports from the inherited systems at zero and fails the build on the first relapse. Another fails the schema once the generated models have drifted. The consolidation holds because it is checked on every change.

### The organization’s own data, in the prompt

Survey results, weak motors and the organization profile are now injected into the system prompt for the environments that need them. That information used to sit behind tools the model had to choose to call, which it sometimes skipped.

**Stack:** NestJS, FastAPI, Next.js, Drizzle ORM, SQLAlchemy, LangGraph, PostgreSQL, pgvector, BullMQ, Azure Container Apps

## The limits of this proof

This shows that four systems can be merged into one and held together by gates. It shows nothing about a market: the platform had not launched at the June boundary, the verdict in the repository’s own readiness log was deployable with caveats, and one of those caveats was a manual security task that no code closes.

## Common questions

### Is Changemkr a Torn Studio client?

The studio owns part of the platform and held the product role there, which the page states at the top. The difference matters: an engagement for someone else and a product the studio part-owns are different claims, and a reader is owed the distinction before any result.

### Why does the case stop in June 2026?

The studio’s product role ran to then. The platform has developed further since under other hands, and counting that work would be taking credit for someone else’s. Every figure on the page is measured at that boundary and can be checked there.

### Why is there no figure for how many tests passed?

The repository re-measured its suite in August 2026 and withdrew the earlier figure as void. A number the source has retracted has no place here, so the page quotes what was stable at the boundary: tables, services, AI environments and specification files.

### What does one schema authority mean in practice?

That a single definition holds all 63 tables and everything else is derived from it. The Python service’s models are generated by a script, and a build gate fails once the generated file and the committed one diverge. Two systems describing one table differently becomes impossible to commit.

### How much of the code did the studio write?

The studio built large parts of the product during the period and originated most of the ideas and features, while others also worked in the codebase. So the page claims a role and a period, and the figures describe the delivered system at the boundary.

### Can a client buy this kind of work?

Yes, in two shapes. Consolidation and AI integration sit under AI and automation; the product role — decision material, prioritisation, architecture calls — sits under Product Management. An engagement opens with a fixed-price review before anything gets built.
