Pipeline

What is Pipeline?

Most organisations can tell you a build failed. Far fewer can tell you why delivery is slow this month, which change carries real risk, or what is actually running in production versus what someone believes is running. Pipeline sits above the source-control and CI systems already in use and normalises them into a single delivery graph — commits, reviews, checks, artefacts, deployments — so those questions have answers. A deterministic Delivery Policy Engine, not a model, decides what is allowed to reach production; the AI explains, scores and investigates, and never authorises.

Problems it solves

• Trace a commit through build, review and release to what is running now
• Explain why delivery is blocked rather than just showing a red check
• Score the real risk of a change instead of treating all changes alike
• Verify what a rollout is doing while it is doing it
• Prove what shipped, for an audit that asks later
• Keep release gates deterministic rather than model-decided

Key capabilities

Delivery Traceability

Follow a change from commit through build, review and release to what is running now.

Deterministic Policy Engine

Rules, not inference, decide what is allowed to proceed — so a model can advise and never authorise.

Risk Scoring

Score a change, a lot or a habitat on a published rubric you can read component by component.

Agentic Investigation

Specialist agents pursue a question through several controlled steps rather than answering in one pass.

Evidence Trail

Every figure carries the record it came from, so a reader can check the answer instead of trusting it.

How it is built

One graph, four providers

GitHub, GitLab, Azure Repos and Bitbucket normalise into the same model, so a multi-provider estate has one answer.

Policy decides, AI explains

The Delivery Policy Engine is deterministic. A model can recommend and investigate; it cannot approve a release.

Failure investigation

Correlates a failing check with the change, the environment and prior occurrences of the same failure.

Release readiness

Assembles the evidence a go/no-go decision needs into one view.

How it works

How the work is structured, and what each step's output rests on.

1. 1

   Connect source control and CI

   Source

   Read repositories, pipelines, reviews and releases from the providers in use.

2. 2

   Normalise into one graph

   Observed

   Map four providers' models onto a single delivery graph.

3. 3

   Correlate change to outcome

   Observed

   Link commits to builds, reviews, artefacts and deployments.

4. 4

   Score risk

   AI-inferred

   Rate a change on a published rubric — blast radius, test coverage, prior failures.

5. 5

   Apply delivery policy

   Source

   The deterministic engine decides what may proceed to production.

6. 6

   Verify the rollout

   Observed

   Watch what the deployment is actually doing and report divergence.

Example use cases

Each example has its own page you can read and share.

Ask Pipeline

Illustrative examples. Results depend on your own data.

• “Why is this release blocked?”
• “What changed between the last two production deployments?”
• “Which failing check is the actual cause, and which are downstream?”
• “Is this change safe to ship on a Friday?”

Security, governance and human control

Where the software deliberately limits itself.

Questions

Can the AI approve a release?

No. The Delivery Policy Engine is deterministic and it alone decides. The model explains, scores and investigates.

Does it replace our CI?

No. It reads the CI you already run and makes the result explainable across providers.

What if we use more than one provider?

That is the case it exists for — four providers normalise into one delivery graph.