Open source · MIT · Postgres + Temporal

A true line from north star to running system.

Truline is an enterprise-architecture platform where the service model and the software delivery that changes it are one graph. Every capability, requirement, release, task, pull request and change is a typed, lineaged record. Temporal workflows move them through their lifecycles, and the build fails the moment the model, the code and the running system disagree.

View on GitHub Run it in ten minutes
One continuous cobalt line runs from a north-star mark through a row of hollow nodes, turns, and returns along a lower track to a server rack; a faint dashed line curves from the rack back to the star.
north star canon capability application requirement release outcome task pull request change record running system observation drift between intended, built and running is a finding the gate: a fresh-context verdict before anything merges
Whether a person or an agent made the change, the line holds. A pull request without a task, a task without a requirement, or a running system that disagrees with its record is a finding, and findings are records too. beads on Postgres · workflows on Temporal
13architecture conformance checks on every pull request
21engineering principles, binding on every task the factory dispatches
14typed record types, from capability to observation, in one store
1gate: a fresh-context verdict before anything merges
Which door

Three ways in, one graph underneath.

The repository holds the record store, the factory, the gateway and a worked vertical. Start where your problem is.

An organisation-chart hierarchy in the upper left and a chain of nodes in the lower right, joined by a single cobalt line that visits nodes in both, so they read as one graph.

You run coding agents and want them governed.

A task record becomes a pull request through an isolated worker, a scanner, containment and a release gate that is a separate, fresh-context agent. Tidy-First is enforced on the PR body. Green CI is a precondition, never a verdict.

Read the operating model →

You do enterprise architecture or ITSM.

A dependency-free CSDM core: capabilities, applications, services and the relationships between them, with state machines and a conformance checker you can run against your own repository in CI.

See csdm-on-beads →

You want the primitive.

Beads: typed, namespaced, lineaged records with governed state machines and an append-only event log, behind one API and one MCP gateway with an identity contract.

Open the substrate →
How a change travels

What has to be true before agent-written code becomes operational truth.

This is the order a change moves in. Each step leaves a record linked to the one before it, so the question "why does this exist" always has an answer.

Isometric line drawing of six flat platforms in a row. A bead sits on the first; a cobalt line runs through all six, passing under a gate at the fourth, and ends at a small server rack on the sixth.

  1. A requirement is filed against a capability.

    It carries acceptance criteria testable by someone who was not in the conversation, and a dated conformance verdict that sprints burn down.

  2. A release charters the outcome.

    One objective, decomposed into outcomes with a work class: feature, enabling, blocking, risk or security. Balance is reported, not asserted.

  3. A task bead is dispatched to an isolated worker.

    Temporal owns the workflow. The worker gets a clone, a persona and the spec, and nothing else. It cannot merge.

  4. The pull request is scanned and gated.

    Private identifiers, conformance checks and the Tidy-First declaration run in CI. Then a fresh-context gate agent writes the verdict: merge, merge with changes, or do not merge.

  5. The merge becomes a change record.

    What was merged, under which verdict, for which outcome. The running system is observed against it.

  6. Drift becomes a finding.

    When the model, the code and the cluster disagree, a finding is filed and dispositioned: backlogged, ruled, already fixed, or not a defect. Rules that prevent recurrence go back into the doctrine.

Quickstart

The store, the gateway and the console, in ten minutes.

$ git clone https://github.com/grantbest/truline && cd truline
$ cp quickstart/env.example quickstart/.env   # set SUBSTRATE_ENCRYPTION_KEY
$ docker compose -f quickstart/docker-compose.yml up --build
$ ./quickstart/seed.sh                         # one task bead, through the gateway
$ open http://localhost:8080/factory           # the board

That brings up Postgres, the bead store, the MCP and REST gateway and the console, with one seeded task on the factory board.

It does not start the factory worker, which needs Temporal and a repository to work on. The dispatcher README is the next step, and everything a real deployment must supply is configuration: the code refuses to start without it rather than guessing.

Deployed from a k3s cluster with ArgoCD and Cloudflare Access at the edge. Those manifests stay with the operator; the platform does not care which cluster it runs on.

Isometric line drawing of four outlined boxes joined in a simple topology, with one cobalt line entering from the left, passing through each box, and ending at an empty browser window.
The framework ships. Your record stays yours.
Three tracings of the same rounded rectangle, slightly offset; where they fail to overlap the gap is hatched in cobalt, and one cobalt line leaves the gap to a small hollow node.

Truline was exported from a private monorepo as a framework: the code, the harness, the metamodel, the doctrine, the personas and the skills, with example charters and registries in the shape the tooling validates. The operator's own charters, measurements and amendment log never leave their repository, and the exporter's record scan fails the build if any of it leaks.

Hosts, domains and people are rewritten to neutral names, and a private-identifier scanner runs on every pull request so your deployment's names stay out of your published trees too.