There is a conversation that happens in the first week of every new CTO or technology leader role.

You sit down with your predecessor, or with whoever has been holding the keys, and they walk you through what you have inherited. The Salesforce org that nobody has fully understood since the last major configuration change. The SQL Server that the finance team refuses to migrate because the stored procedures are load-bearing. The Active Directory estate that grew through three acquisitions and was never properly rationalised. The M365 tenant where nobody is entirely sure what the DLP policies cover. The AWS account that started as a sandbox and is now running production workloads.

That conversation is the most important thing that happens in the first ninety days. Everything else is noise until you know what you have.

The problem is that the output of that conversation lives in a Confluence page, or a Word document, or a slide deck, or a human brain. It has no score. It has no order of priority. It has no machine-readable evidence. It cannot be queried or tracked or used to drive a remediation plan with any rigour.

It is, in short, a guess. A well-intentioned, experience-backed guess by a person who is about to leave.


What Toyota understood in 1950

The Toyota Production System was not a quality improvement programme. It was a recognition that by the time you find a defect at the end of the production line, the damage is already done. The car was built wrong. The materials were consumed. The time was spent. Post-production inspection does not eliminate defects. It discovers them after you have already paid for them.

The insight — the one that changed manufacturing — was that quality has to be built in. Not inspected in. Not audited in at the end. Built in. The work standard is agreed before any part is touched. The machine detects the abnormal condition and stops itself. The evidence accumulates at every step. The line does not proceed on a known violation.

That is TPS. And the enterprise IT estate in 2026 is exactly where Western manufacturing was in 1950.

Everyone is doing post-production inspection.

The Salesforce org runs for fifteen years. Then something breaks — a data segmentation issue, a compliance audit, a divestiture — and you commission an assessment. By the time you find the problem, the sharing rules have been misconfigured for years. The profiles with Modify All Data have accumulated across three personnel cycles. The architectural decisions that created the problem were made so long ago that nobody remembers why.

You are reworking a fifteen-year-old car.


The net is wider than we thought

When we built the RST scale — Rickety, Sickety, Ticketyboo — we built it to score GitHub repositories. To tell you whether your codebase's engineering practice was in the danger zone (R), improving (S), or genuinely healthy (T).

That framing was correct. The model was sound. The problem was the surface area.

A GitHub repository is one thing with an API. The estate has dozens of things with APIs. Every one of them can be scored. Every one of them has a health state that can be expressed as a number between 0 and 100. Every one of them has findings that can be classified by severity. Every one of them can be placed on the R1–T3 continuum. Every one of them can block others, or be blocked by others, in a dependency graph.

The model does not change. The surface area expands.

Salesforce has a Tooling API and a Metadata API. You can read sharing rules. You can count profiles with dangerous permissions. You can scan APEX classes for known vulnerability patterns. You can assess org separation. You can score it.

M365 has the Graph API and the Compliance Centre. You can read Conditional Access policies. You can assess DLP coverage. You can check MFA enforcement. You can flag licensing waste. You can score it.

Entra ID exposes the Identity Graph. You can enumerate AD forests, check PIM coverage, audit stale privileged accounts, find legacy domain debt. You can score it.

SQL Server has information_schema and sys. You can assess schema ownership, find stale objects, check for unencrypted columns, identify missing referential integrity. You can score it.

AWS has SecurityHub, Config, and IAM Access Analyzer. GCP has Cloud Asset API and Security Command Centre. Google Workspace has the Admin SDK and Reports API.

Anything with an API can be connected. Anything that can be connected can produce findings. Anything that produces findings can be scored. Anything that can be scored can be placed on the continuum. Anything on the continuum can be prioritised, tracked, and remediated with evidence.


The RST framing, widened

R — Rickety. The system is in the danger zone. There are active risks. Known violations are proceeding. The line should have stopped. In a Salesforce org, this means confirmed security or compliance failures with live impact. In an identity estate, this means privileged accounts with no MFA and no audit trail. In a SQL database, this means exposed connection strings, unencrypted PII columns, no access logging. The system needs intervention before it fails.

S — Sickety. The system is functioning but showing strain. There are structural gaps that are not yet causing active failures but will. In a Salesforce org, this means accumulating technical debt, profiles with excessive permissions, a configuration history that nobody can fully explain. In an identity estate, this means legacy domains still in use, PIM not fully deployed, BYOD policy partially defined. The system needs a structured improvement programme.

T — Ticketyboo. The system is healthy. The foundations are solid. Monitoring is in place. Remediation is tracked. Evidence accumulates. In a Salesforce org, this means clean sharing rules, least-privilege profiles, a test coverage standard enforced before deployment, org separation maintained. In an identity estate, this means PIM everywhere, no legacy domain debt, ZTA fully closed, external identity planes documented and reviewed. The system can be handed over with confidence.

The three labels are not metaphors. They are positions on a continuum with specific check results behind them. The engine does not care whether it is scoring a repository or a Salesforce org or an Active Directory forest. It takes findings, weights them by severity, computes a score, and returns a label.


The dependency graph is the differentiator

The score alone is not enough. The score without the dependency model is a league table, not a plan.

The identity estate at S3 does not just have its own problems. It blocks the Salesforce remediation. SSO federation through Entra is how users authenticate to Salesforce. If Entra's Conditional Access has gaps, the Salesforce org's security posture cannot be fully certified regardless of what its own sharing rules look like. The identity estate's score is a dependency of the Salesforce score.

The same logic applies across the estate. AWS infrastructure health affects the data platform. The data platform affects the analytics layer. The analytics layer affects the reporting that the business uses to make decisions. The M365 classification state affects whether documents produced in that environment meet data residency requirements. The SQL database security posture affects whether the application it backs can be certified compliant.

When you score each system independently, you get a list. When you map the dependencies between systems, you get an order of operations. The dependency graph tells you: fix this first, because everything else is blocked until you do.

That is the insight Toyota had about the production line. The bottleneck determines the throughput of the whole system. Address the constraint first. Everything else is secondary until the constraint is resolved.


What this changes

The product started with GitHub as the first connector. That was the right place to start — developer-adjacent, familiar territory, easy to demonstrate value.

But the product was never about GitHub. It was always about this:

Any system with an API can be scored. Any scored system can be placed on the continuum. Any system on the continuum can be related to others in a dependency graph. The dependency graph produces a prioritised remediation order. The remediation is tracked with evidence. The evidence accumulates.

The Salesforce connector calls the Tooling API and the Metadata API. The identity connector calls the Entra Graph API. The SQL connector queries information_schema. The M365 connector calls the Graph API and the Compliance Centre. The GCP connector calls Cloud Asset API. The AWS connector calls SecurityHub and Config.

Each connector normalises its findings into the same shape. The engine scores them identically. The scatter plot places them on the same continuum. The dependency graph connects them into a coherent picture of the estate.

The technology leader inheriting that estate does not need a new tool for each system. They need one view of everything, scored on a common scale, with a common evidence model.

That is what this builds.


The sentence

"I can audit all your systems — latest to legacy."

Not: "I can review your pull requests."

Not: "I can check your code for security vulnerabilities."

Not: "I can run a penetration test."

I can audit all your systems — latest to legacy. Score every component. Show you what blocks what. Give you a machine-readable remediation roadmap with evidence at every step. And I can do it in a week, not a quarter.

The product is the automation layer that turns that framework into a repeatable, evidence-backed, commercially-priced service.

The net is wider than we thought. The model was always right.

Related tools and articles

→ See the estate audit demo → Explore the RST scale scatter plot → Governance as code: the Gatekeep story → Scan your repository for governance gaps

ticketyboo scores any system with an API — GitHub, Salesforce, Entra ID, AWS, M365, SQL, GCP. One scale. One evidence model. One remediation order.

Try the scanner See pricing →