Your platform, surveyed — not typed.

1Summary

Every engineering organisation already records the truth about its platform. It is spread across Git hosts, CI/CD pipelines, Kubernetes, service registries, the CMDB and incident tooling. What no organisation has is a single view of that truth that it can trust.

Developer portals tried to fix this by asking teams to write the catalog themselves. Trignal takes the opposite approach. It reads the systems you already run, cross-checks what each one says about every service, and only treats a fact as true when independent sources agree. Where they disagree, it shows you both answers. People confirm or correct; they never type the catalog from scratch.

• Under an hourfrom read-only access to a first Map of your estate
• Read-onlyby default, with one container or Helm chart
• Every factcarries its sources, timestamps and values

2The problem

Catalogs rot

A hand-written catalog is accurate on the day it is finished. After that, it depends on hundreds of engineers remembering to update YAML files and forms as services are renamed, split, handed over and retired. Within months it describes a platform that no longer exists, and people stop trusting it.

Systems disagree, and nobody notices

Consul says the checkout service belongs to one team. The ServiceNow CMDB says another. CODEOWNERS names a third, and the Kubernetes labels were copied from a template two reorgs ago. Most tools pick one source and silently ignore the rest, so the disagreement is never seen and never fixed.

Portals take quarters to pay off

Rolling out a developer portal usually means weeks of data modelling and mapping before anyone sees value. Many rollouts stall before the catalog is complete enough to be useful.

Delivery metrics lack context

A lead time figure means little if you can't see how many deploys it was computed from. Most tools show DORA numbers without saying how complete the underlying data is, which makes them easy to dismiss.

3Survey, don't type

Britain was mapped from a network of concrete pillars called trig points. Surveyors raised a signal, a beacon or target, over each one so that other stations could take a bearing on it. A position was only trusted once bearings from several stations agreed. Where they didn't, the gap was called a misclosure, and it was measured and resolved, never ignored.

Trignal (trig + signal) applies the same method to your platform. Each connected system is a station. Each fact it reports is a bearing. The map is trusted where the bearings close.

4How Trignal works

Station

A connected source system: GitHub, GitLab, Jenkins, Argo CD, Kubernetes, Consul, ServiceNow, PagerDuty, a cloud provider or OpenTelemetry. One station per configured connection.

Bearing

One piece of evidence: a single attribute value, from one station, at one time. Bearings are immutable and kept in an append-only store, so every fact has a full history.

Survey

A collection run. The first survey reads everything after install; resurveys run incrementally, every 15 minutes by default.

Triangulation

The engine that works out which records across stations describe the same real service (for example, pay-api in Kubernetes and PAY-SVC-01 in the CMDB) and reconciles their bearings.

Fix

A reconciled fact with the bearings that support it, scored 0 to 100 for strength. Strength rises with the number of independent stations that agree and falls as bearings age.

Datum

Trignal's current best answer for each service, after triangulation and any human corrections. It powers the Map, service pages and benchmarks.

5Misclosures and witnesses

Trignal never silently picks a winner. When stations disagree, the fact is flagged as a misclosure and each station's value is shown side by side. A person can then witness the correct value. The witness records who made the call, when and why, and it overrides the computed fix while keeping every underlying bearing visible.

Every fact about every service has exactly one of five statuses:

If a witnessed fact later receives conflicting bearings, it shows both statuses. Trignal also flags unsurveyed services: things it can see evidence of in traffic, deploys or traces that no catalog-type station claims, or that have no owner.

6Closure: a trust score for your platform

Closure is the share of required facts across in-scope services that are triangulated or witnessed and free of misclosure. The proposed required facts are owner, tier, repository, runtime and on-call.

Closure gives platform teams one number to track and improve, and it points directly at the work that raises it: resolve this misclosure, add that station, witness these facts.

7The Field Book and DORA

The Field Book is Trignal's change ledger. It traces every change through its full chain:

1. commit
2. PR
3. build
4. artifact
5. deploy
6. environment
7. incident / change request

The artifact digest (the container image digest or build artifact hash) is the join key that links builds to deploys across tools. The commit SHA links pull requests to builds. Incidents and ServiceNow change records are linked to a deploy by service, time window and artifact digest.

All five DORA software delivery metrics are computed from the Field Book, using DORA's current names:

Every figure is shown beside its Field Book coverage: the percentage of production deploys with a fully traced chain. Unattributed deploys are counted and explained, for example "212 deploys unattributed: Jenkins jobs missing commit SHA", so teams know exactly how to improve the data.

Metrics are reported for services and teams only. Trignal never ranks or scores individual engineers.

8From install to first Map

Trignal ships as a single container or Helm chart. Each station needs only a read-only token, and the hour starts once those tokens are issued. For a mid-size estate of a few hundred services, the first survey is designed to finish in under 60 minutes and produces three things: a Map of services, dependencies and ownership; a list of misclosures; and a closure score.

$ helm install trignal trignal/trignal
$ trignal station add github --token $GITHUB_RO_TOKEN
$ trignal station add servicenow --instance acme --token $SN_RO_TOKEN
$ trignal survey --initial
First survey complete: 412 services found. 37 misclosures. Closure 64%.

To get there quickly, the first survey reads only what the Map needs: current services, owners, repositories, runtimes and on-call. Change history for the Field Book is backfilled in the background over the following hours, so DORA metrics fill in after the first Map, and their coverage figure shows how far along they are. Estates with consistent naming triangulate fastest; messier ones start with more single-bearing facts and misclosures, which is exactly the work Trignal is there to surface.

Stations at launch, in priority order:

1. Git hosts GitHub, GitLab: repositories, CODEOWNERS, PRs, commits
2. CI/CD GitHub Actions, GitLab CI, Jenkins, Argo CD: builds, artifact digests, deploys
3. Kubernetes workloads, labels, annotations, image digests
4. Consul service registry, health, tags, metadata
5. ServiceNow CMDB configuration items, change requests, incidents
6. Incident tooling PagerDuty, Opsgenie, incident.io
7. Cloud provider tags AWS, GCP, Azure
8. OpenTelemetry (optional) dependency edges and unsurveyed-service discovery

CLI commands and figures above are illustrative of the planned experience.

9Principles

• Evidence over authorship. Every fact carries provenance: which stations reported it, when, and with what value.
• Disagreement is a feature. Conflicts are surfaced, never silently resolved.
• Read-only by default. Trignal never writes to your systems unless you explicitly enable a write-back action.
• Fast to first value. One install and read-only tokens, then a first Map in under an hour.
• Honest metrics. Every DORA figure shows how much data it was computed from.
• Teams, not individuals. No developer scores or productivity rankings, ever.

10How it compares