Architecture Ledger · The approved baseline

The system as approved, kept current.

The living, current, approved state of every system, component and interface. It is the baseline every Change Intention is proposed and audited against.

Architecture Ledger · Paymentsapproved baseline
LevelItemState
SystemPaymentsApproved
ComponentLedger serviceApproved
InterfaceVault APIApproved
ComponentNotification workerApproved
BoundaryCard data stays behind the vaultApproved
ComponentRefund serviceIn review
Illustrative mock. Not an actual product screen.
What’s in it

Four kinds of entity, one current picture.

Ledger artifacts describe what actually exists, not what should be true.

Systems

Every system in your architecture.

Components

What each system is built from.

Interfaces

How components talk to each other.

Boundaries

The lines drawn between them.

How it works

From your repos to an approved baseline.

01Point rkito at your repo

Connect GitHub. rkito reads your code, Terraform, Helm, Kubernetes manifests and OpenAPI specs.

02Review the scan

The scan generates a Change Intention with every component, boundary and interface it found.

03Merge your baseline

Architects update what needs updating and merge. That is your living Architecture Ledger.

04Change it one way

From then on the Ledger changes only through an approved Change Intention.

Where it is used

Read before you change, audited at the PR.

Before the changeExplore the Ledger first

See what systems, components and interfaces exist, and which Change Intentions are already active on them.

At the PREvery PR is audited against it

The audit evaluates each pull request against the Architecture Ledger and your Steering principles.

Prepare the ground now. Switch on the gate later.

Starter is free for five members. No credit card.