> For the complete documentation index, see [llms.txt](https://docs.cortex.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cortex.io/solutions/drive-framework.md).

# DRIVE framework

<div align="left" data-with-frame="true"><figure><img src="/files/1bgwuTpq9xViFH6r0qXX" alt=""><figcaption></figcaption></figure></div>

Not long ago, a human reviewed every change before it shipped. Every problem traced back to a decision someone made. It was slow, but legible. That world is gone.

Now AI agents are opening PRs your team didn't write. Background processes are fixing bugs nobody watched get fixed. Deployments are happening faster than any human can track. The path from requirement to production is a black box, and it's getting more opaque.

Output is up. Velocity is real. But more shipping doesn't mean the system is healthy, and most engineering leaders already sense the gaps.

The old developer productivity metrics give a false read. Sprint velocity, story points, and PRs per engineer were built for humans doing human-speed work. What does it mean to make a developer 5% more efficient when agents are doing the work in the background? Individual productivity metrics don't just fail to capture what's happening, they actively obscure it. The bottleneck isn't individual output anymore. It's whether the whole system (people, agents, infrastructure, processes) can sustainably absorb and deliver what the factory is producing.

So the measurement layer has to move up. From the commit, to the pull request, to the organization itself. Speed, reliability, security posture, and cost are emergent properties of a system you can't fully see from the inside. The only way to understand them is to observe from the outside, consistently, at the right level. That's what DRIVE is for.

> [Get the full DRIVE framework authored by Cortex's Ganesh Datta](http://cortex.io/report/drive-framework)

## What DRIVE is (and what it isn't)

DRIVE is a framework for measuring engineering organizational health in the age of AI, built specifically to be used at Operational Excellence (OpEx) reviews (regular, structured check-ins at the leadership level) to answer a single question: Is our organization sustainably delivering high-quality software?

It breaks that question into five pillars, each targeting a different dimension of organizational health. Reviewed together on a recurring cadence, they tell you whether you can keep pushing, or whether you need to pull back somewhere.

DRIVE works alongside productivity frameworks like DORA. Where DORA and similar tools measure specific engineering data, DRIVE is the structure for bringing that data into a room with the right people and the authority to act on them. Metrics without that meeting, and without someone empowered to reallocate resources, are just numbers. It also doesn't answer the question of what to build. As shipping gets faster and easier, that question becomes more consequential, not less, but it's a separate conversation.

DRIVE is also not just for organizations already deep into AI adoption. For teams earlier in the journey and actively building the AI software factory, it's the right framework to have in place from day one. It surfaces the key levers early, so you know whether you can keep increasing the pace or whether something needs to be addressed first.

More of a visual learner? Learn about the DRIVE framework in this short video.

{% embed url="<https://youtu.be/zHGhq7RuXYU>" %}

## DRIVE use cases

#### Engineering leadership OpEx reviews

DRIVE was designed for this. Run a weekly or bi-weekly review where engineering directors look at the Scorecard across all services or by domain. Bronze/Silver/Gold levels give an instant read: which teams are healthy, which need support, and what specific rules they're failing. The action items from each review can be tracked as Cortex Initiatives, so follow-through is visible at the next meeting.

#### Accountability for AI adoption

Most organizations adopting AI coding tools are measuring lines of code or "time saved", not whether the downstream health of their software is improving or degrading. DRIVE measures both sides of the equation: are teams shipping faster (Delivery), but also are they maintaining reliability (Reliability) and staying in budget (Efficiency)? Organizations using AI tools without this kind of backpressure are flying blind on whether the investment is actually paying off.

#### Security and compliance posture at scale

For organizations with hundreds of services, staying on top of vulnerability SLAs and compliance baselines without Cortex typically means quarterly manual audits or a dedicated security team running spreadsheet-based reviews. With DRIVE Vigilance rules automated in Cortex, every service is evaluated on every Scorecard cycle, and those that slip below threshold are surfaced at the next OpEx review without anyone having to look for them.

#### Migration and modernization progress

Platform migrations (VCS migrations, package upgrades, runtime EOL remediations) are among the highest-risk initiatives in an engineering org because they're easy to deprioritize. The DRIVE Initiatives pillar makes them visible at the leadership level on a recurring basis. Teams at 45% completion show up as Bronze failures at every review until the migration is done, rather than going unnoticed until the deadline.

<br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.cortex.io/solutions/drive-framework.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.