Platform
Understand your organization's AI posture
A scorecard across inventory, identity, data, models, policies, observability and auditability, with what changed and which systems carry the most risk.
This estate, today
Overall posture
82 / 100
Work on this next
Models
2 need a decision — one blocked, one retiring.
7 categories
Every score here is a fraction, and the fraction is printed under it.
A scorecard is the easiest thing on a website to fabricate — seven plausible percentages in a grid look like evidence and cost nothing to invent. So each of these is a count over something the estate already knows: credentials inside their rotation window, bounds that sit on a real action, systems that emit a trace.
Inventory
+17 improved78
14 of 18 systems in the estate are registered and owned, or were found and resolved.
Identity
0 unchanged80
8 of 10 credentials sit inside their rotation window. No agent holds one directly.
Data
+11 improved89
8 of 9 sources have no path by which directly identifying data could be written out.
Models
-15 declined71
5 of 7 models are approved for a stated use, on a pinned snapshot.
Policies
0 unchanged88
7 of 8 bounds sit on an action an agent actually attempts.
Observability
+13 improved80
12 of 15 systems that can change state emit a trace for every attempt.
Auditability
+6 improved89
16 of 18 systems have a named person who answers for them.
Overall
82
The unweighted mean of the 7 categories. The least actionable number on this page, and the one a report would lead with.
IllustrativeIllustrative scores for the OpsAI sample estate, computed from the fixture data behind inventory, identity, data access and policies. Movement since the last assessment is illustrative.
A score you cannot recompute is a logo, not a measurement.
The overall figure is an unweighted mean of the seven, and it is the least useful thing on this page. Weighting only invites an argument about the weights instead of an argument about the gaps. The categories are what a team can actually act on.
What changed
A category falling is sometimes a control working.
The level and the direction are different facts, and a scorecard that shows only the level cannot tell you which situation you are in. One at 60 and rising needs patience; one at 60 and falling needs somebody today.
Improved
4
categories up since the last look
Declined
1
categories down
Unchanged
2
flat
Overall
82
unweighted mean of 7
The category that moved down, and why that is not bad news.
- Models-15
- 71was 86
- 5 of 7 models are approved for a stated use, on a pinned snapshot.
- 2 need a decision — one blocked, one retiring.
- What it means
- A model was blocked since the last assessment, so the approved share fell. Nothing got less safe — a review reached a conclusion and the estate reflects it. A scorecard that treated this as a regression would be teaching its reader to avoid making decisions.
Coverage should be a score that can fall, not a count that only grows.
A running total of governed systems always looks like progress, even while the gap widens behind it. A fraction cannot flatter you that way: bring in ten new systems without governing them and the number goes down, which is the correct response.
Where the risk sits
Not spread evenly — concentrated in a handful of named things.
A single figure of 82 across an estate says almost nothing on its own. What a team needs is the list underneath it: the specific systems, models and credentials the score is being dragged down by, each with somewhere to go and fix it.
Risk concentration
7 items| What | Why it is on this list | What makes it risk | Where to work on it |
|---|---|---|---|
| Vendor copilot enabled in the CRM tenant | unresolved | It can change state in a system of record and is still in triage with RevOps. | Discovery |
| Scheduled script calling a model API directly | unresolved | It can change state in a system of record and nobody has claimed it. | Discovery |
| Reporting automation with a model call added | unresolved | It can change state in a system of record and is still in triage with Ops. | Discovery |
| Gemini Pro | retiring | Superseded for this use in March. Two agents still call it; both move next sprint. | Models |
| Public web UI | blocked | Reached through a browser rather than an API, so it is governed at the data boundary instead. Pasting customer data into one is the exposure this row exists to name. | Models |
| RazorpayX OAuth client | rotation due | 51 days old against a 60-day policy. | Identity |
| Postgres DB role | rotation due | 27 days old against a 30-day policy. | Identity |
IllustrativeDerived from the same illustrative fixture data as the scorecard above.
This list is the whole point of scoring anything.
A posture report that ends at 7 numbers produces a slide. One that ends at 7 named items with an owner and a link produces work. The score exists to rank the list, not to be reported on its own.
Notice what dominates it: things that were found rather than declared. That is the usual shape. The systems somebody registered are, almost by definition, the ones already being looked after.
Where to start
Start with models, because it is the lowest and the denominator is small.
A posture assessment is worth doing when it produces a shortlist. Two decisions on the models list would move the weakest category further than a quarter of work anywhere else on this page.