Skip to content

Cookie preferences

Choose which cookies and similar technologies this site may use. The strictly necessary ones keep the site working and remember this choice, so they cannot be turned off; they store nothing that identifies you or follows your browsing. Read the cookie notice

Continuumship
Menu

System graph

Know what a change touches before it ships.

Continuumship maps services, interfaces and their consumers across your repositories. Every brief says what a change touches, three hops out, and the owners are involved before the review starts.

Talk to us Features
The change, the three hops it reaches across repositories, and the owners of each service it touches.

Why a graph

The review is the wrong time to find the other team.

  • We learn about consumers when they page us.

    An interface changes in one repository, and the service that depended on it finds out in production.

  • Ownership lives in a spreadsheet nobody updates.

    Who owns what is tribal knowledge. The right reviewer is found after the merge request is open.

  • Agents change code they cannot see around.

    An agent sees one repository. It cannot know which other team reads the interface it just edited.

How it works

Map it, put it in the brief, act on it.

Services, interfaces, consumers

The graph joins services, interfaces and their consumers across repositories, from records the platform already keeps. Each edge says how it is known.

  • Declared, discovered or observed, and labelled so
  • Across repositories and code hosts
  • Owners by team and Area

What this touches, in every brief

Impact analysis walks at most three relations from what a change is known to touch, and writes what it found into the brief before work starts.

  • Three hops out, and no further
  • The same context for the person and the agent
  • Impact items proposed, for a person to accept

Owners involved, facts put to work

The owners of what a change touches are involved before the review. The same facts feed change risk and guardrails.

  • A breaking interface change can require architecture approval
  • Three owning teams can raise a change's risk
  • Each fact names its source

Try it

Pick a change, see what it touches.

Choose an element of the graph as the change. Continuumship walks at most three relations out — to its consumers, or to what it depends on — and names the owners to involve before the review starts.

Walk towards

Choose an element on the graph. The walk stops three hops out.

In the brief

payments-api has 5 consumers within three hops, across 2 repositories; involve Payments, Checkout, Billing and Messaging before review.

What this touches

  1. Hop 1
    • refunds-workerservice refunds-worker calls payments-api · observed in traces
    • checkout-webweb app checkout-web calls payments-api · discovered in the OpenAPI file
    • billing-serviceservice billing-service calls payments-api · observed in traces
  2. Hop 2
    • invoice.issuedevent billing-service publishes invoice.issued · declared by its owners
  3. Hop 3
    • notificationsservice notifications subscribes to invoice.issued · declared by its owners

Owners to involve

  • Payments refunds-worker
  • Checkout checkout-web
  • Billing billing-service and invoice.issued
  • Messaging notifications

Questions about the system graph

Does it predict what a change will break?
No. It says what a change touches, from facts it can show you, and how each is known. What that means is for the owners it involves to decide.

Do we have to model our architecture first?
No. The graph is built from what your connections and repositories already hold: code locations, interfaces and their consumers. Owners correct what is wrong.

How does the graph change a review?
The brief lists what the change touches and who owns it. Those owners are asked before the review, and a guardrail can require their approval for a breaking change.

What does the graph read, where, and who acts on it?
Repositories are read on your runners, where the code is. The platform keeps facts about services, interfaces and consumers, never the source. The graph proposes impact; the owners it involves decide.

Keep reading

The rest of the control plane.

Design how your company ships software.

Start with a thirty-day shadow pilot on one Area: connect, observe, read the report together, decide.

Talk to us Pricing