OBD-II Data Access

Skip key takeaways

Updated September 28, 2026

• The access condition separates the four paths A dongle depends on the owner's permission and an emissions-bound connector, a J1979-2 vehicle on a reader that detects the variant, an OEM API on the manufacturer's field set and the user's consent and raw CAN on access to the right DBC.
• Detect the OBD protocol variant before polling A reader built only for classic J1979 cannot assume a J1979-2 vehicle will answer, and a mandatory protocol-variant field on every record stops a classic decoder from quietly misparsing UDS responses.
• An OEM API returns only what the manufacturer's backend stores Coverage, sampling interval and field set are the manufacturer's choice, values often arrive as last-known snapshots and the user can revoke consent from the manufacturer side.
• Provenance on every value makes mixed paths workable One canonical signal model with path, adapter, decoder version and source timestamp on each value lets features read a signal rather than a path and keeps an API odometer apart from a distance-since-cleared counter.
• A dongle is a network endpoint inside the vehicle In a 2016 announcement the FBI and NHTSA warned that third-party diagnostic-port devices can give an attacker remote access to vehicle systems and driver data, so device firmware should refuse write and control requests and the backend should never expose a raw diagnostic command.

Copy takeaways

In short: a fleet or app platform gets OBD-II data access through one of four paths: a dongle polling SAE J1979 PIDs, the same dongle speaking J1979-2 (OBDonUDS) to newer vehicles, an OEM connected-car API or raw CAN logging decoded with a DBC file. Each path returns different data under a different access condition and breaks in a different way, so the comparison table below is the place to start. A platform that runs more than one path has to normalize them into one signal model with provenance on every value.

This guide is for the team building the platform side, not ECU firmware: the device fleet, the ingestion pipeline and the data model features read from. The regulatory and standards sources cited below set what the diagnostic connector has to do and, in the EU, who may ask for vehicle data. They say nothing about backend design, so every engineering recommendation here is the design we recommend for automotive software development platforms, not a requirement of any regulator or standards body.

Four Ways to Get Vehicle Data

The four paths differ most in who controls the read. A dongle reads what the vehicle answers on request, an OEM API returns what the manufacturer's backend chose to store and a CAN logger records whatever flows on the bus.

Data path	What it returns	Access condition	What breaks	Backend ingestion shape
OBD-II PIDs through a dongle	Emissions-related live data from the classic SAE J1979 services, such as engine speed, vehicle speed and coolant temperature, plus readiness monitors, trouble codes, freeze frame data and the VIN	Physical access to the diagnostic connector and the vehicle owner's permission to install a device	Supported PIDs vary by vehicle, request-response polling caps the sample rate, a vehicle that answers only J1979-2 goes quiet to a classic-only reader and the device can be unplugged or moved to another car	Device-pushed batches of timestamped samples with per-device sequence numbers, store-and-forward while offline, decoded against a versioned PID table
J1979-2 (OBDonUDS) vehicles	The legislated OBD content, carried over UDS (ISO 14229) diagnostic services instead of the classic J1979 services, with different trouble-code and readiness structures	Same connector and permission, plus a reader that detects which variant the vehicle speaks	Classic requests may go unanswered, and trouble-code and readiness structures differ, so a classic decoder either fails loudly or quietly misparses	Same transport as the dongle path, with a protocol-variant field on every record and a separate decoder table per variant
OEM connected-car API	Whatever data points the manufacturer's backend retrieves and chooses to expose, with the field set and interval set by the manufacturer	The user's authorization for each vehicle, usually given through the manufacturer's own flow, plus contract terms with the manufacturer or, in the EU, a request under Article 4 or 5 of the Data Act, by the user or on the user's behalf	Coverage varies by make, model, model year and market, values often arrive as last-known snapshots rather than a stream, consent can be revoked and field names and units can change between API versions	Server-to-server webhooks or scheduled pulls into one adapter per manufacturer, idempotent upserts keyed on vehicle, field and source timestamp, consent state held in its own table
Raw CAN logging with DBC decoding	Every frame on the tapped bus, including proprietary signals no diagnostic service exposes	A physical tap on the bus or the connector, and a DBC file for that vehicle's messages held by whoever operates the logger	Without the right DBC the frames are undecodable bytes, message layouts change between model years and software releases and a gateway can hide internal buses from the connector	Bulk log files uploaded in batches to object storage, then decoded by a separate job against a versioned DBC

OBD-II PIDs Through a Dongle

A dongle's connector exists because emissions law requires it. In the US, 40 CFR 86.1806-17, the section that applies to current model years, incorporates California's 2013 OBD-II requirements by reference and states the purpose of OBD in one line: "OBD systems must generally detect malfunctions in the emission control system, store trouble codes corresponding to detected malfunctions, and alert operators appropriately." So the standardized data set is built around emissions diagnosis, and anything beyond it, such as door state or tire pressure, is outside what the connector is obliged to answer.

The request vocabulary comes from SAE J1979, which the EPA's incorporation-by-reference list in 40 CFR 86.1 titles E/E Diagnostic Test Modes. J1979 defines a small set of services, still often called modes, covering current data identified by a parameter ID (PID), freeze frame data, stored and pending trouble codes, monitoring test results, vehicle information such as the VIN and a code-clear request. Each PID has a defined length and scaling, and most are optional, so a reader first asks which PIDs the vehicle supports. EPA's inspection rules use the same vocabulary. Under 40 CFR 85.2231 an inspection test system has to communicate with the standard data link connector and read readiness the J1979 way: "The test system shall be capable of checking for OBD monitors and the evaluation status of supported monitors (test complete/test not complete) in Mode $01 PID $01".

Under the connector, modern vehicles carry these requests over CAN. ISO 15765-4, Road vehicles - Diagnostic communication over Controller Area Network (DoCAN) - Part 4: Requirements for emissions-related systems, sets the requirements for CAN-based communication between the in-vehicle network and the vehicle's diagnostic link connector. Older vehicles may use one of several earlier serial protocols, which is why a general-purpose adapter runs automatic protocol detection before its first request. An ELM327-class adapter or a purpose-built telematics unit hides that detection behind its own interface. The firmware should report the detected protocol anyway, because a vehicle on a slower legacy protocol usually delivers a lower sample rate than a CAN vehicle.

Polling budget

Classic OBD-II is request-response. Every request costs a round trip to the vehicle's emissions-related controllers and back, and even though one request on CAN can carry several PIDs, a device polling twenty PIDs as fast as it can gets a low sample rate on each of them. The practical design is a tiered schedule: a fast tier for the few signals a feature needs in near real time, such as vehicle speed and engine speed, a slow tier for fuel level and coolant temperature, and one-shot reads for the VIN, supported-PID list and trouble codes at ignition-on. The device should report the schedule it actually ran, because the backend cannot otherwise tell a vehicle that stopped answering from a device that stopped asking.

What a platform reads that the standard never promised

Product teams often ask for mileage, and it is easy to build on the wrong PID. J1979 includes counters such as distance traveled since trouble codes were cleared, which resets whenever codes are cleared again, by a workshop or by any other scan tool, and is not an odometer. Not every vehicle exposes a true odometer over the classic PID set either. A platform that bills or schedules maintenance by distance needs a vehicle-specific source, an OEM API odometer or a GPS-derived distance, and the data model has to record which one produced each figure.

Ingestion shape

Dongle data arrives as device-originated batches over a cellular link. The device buffers out of coverage and uploads later, so batches arrive out of order and sometimes twice. Each sample carries the device timestamp and a per-device sequence number: the sequence number makes deduplication exact, and the time-series store indexes on device time, not receive time. Re-reading the VIN at every ignition-on catches a dongle moved to a different car before it merges two vehicles' histories under one device ID.

J1979-2 OBDonUDS Vehicles

SAE J1979-2 (OBDonUDS) moves the legislated OBD functions onto Unified Diagnostic Services. ISO 14229-1, Road vehicles - Unified diagnostic services (UDS) - Part 1: Application layer, defines those services independently of the data link, so that a diagnostic tester acting as the client can control diagnostic functions in an electronic control unit acting as the server. Its 2020 edition is withdrawn and ISO lists a 2026 edition as its replacement. J1979-2 carries the legislated OBD functions forward, but the request and response structure changes, and so does the shape of some content, such as trouble codes and readiness.

For a platform this is a detection problem first. A reader built only for classic J1979 cannot assume a J1979-2 vehicle will answer its service and PID requests, so the device has to establish the variant before it builds a polling schedule and report it with every batch. The backend therefore needs a second decoder table and a trouble-code model that holds both forms without forcing one into the other.

Two failure modes are worth designing against. The loud one is a device that sends classic requests, gets no answers and reports the vehicle as unsupported. The quiet one is a decoder that parses a UDS response with classic rules and produces plausible but wrong values for weeks. A protocol-variant field that is mandatory on every stored record, and a decoder lookup that refuses to run without it, closes the quiet path. In a mixed fleet both decoders stay in production, and coverage reports should break down by variant.

OEM Connected-Car APIs

An OEM API skips the connector entirely. The vehicle's own telematics unit sends data to the manufacturer's backend, and the platform reads from there. What an OEM API returns is bounded by what the manufacturer's backend collects, and both the data points and the interval are the manufacturer's choice. In the EU, the Data Act governs what a manufacturer must make available on request.

Consent, coverage and latency

Consent is typically per vehicle and held in the manufacturer's system. The user grants access through the manufacturer's flow, the platform receives a grant tied to that vehicle and the user can revoke it from the manufacturer side. The backend needs a per-vehicle consent state machine (requested, active, revoked, expired) checked on every read. A revocation webhook that lands while a scheduled pull is in flight is the classic race; the safe rule is to drop, not store, data whose source timestamp is after the revocation.

Coverage does not necessarily span every model, model year and market a manufacturer sells, and field availability can vary within one brand. Values often arrive as last-known snapshots carrying the manufacturer's timestamp, which can be hours old for a car parked out of coverage. Storing only the receive time turns a stale fuel level into a fresh one, so the source timestamp has to be first-class in the schema.

Ingestion shape

Each manufacturer gets its own adapter that maps its fields and units onto the platform's canonical signal model, and the adapter version is stored with every value it writes. Writes are idempotent upserts keyed on vehicle, signal and source timestamp, because webhooks retry and pulls overlap. Rate limits belong in the adapter, and a manufacturer API version change ships as a new adapter version, with the old one kept until every consented vehicle has moved.

Raw CAN Logging With DBC Decoding

Raw CAN logging records the broadcast traffic electronic control units exchange with each other, far more than the diagnostic services expose. The diagnostic transport standard draws that line itself: ISO 15765-4 sets requirements for communication between the in-vehicle network and the diagnostic link connector and leaves the architecture of the in-vehicle CAN network unspecified. A DBC file fills that gap: for one vehicle's network it describes which frame identifiers carry which messages and where each signal sits in the payload bytes.

The open-source cantools library shows what a DBC-driven decoder has to model. Per signal, cantools records position and size plus byte order, signedness, scale, offset, minimum, maximum and unit. Its documentation also shows it can "Decode CAN frames captured with the Linux program candump".

Where the DBC comes from is the hard part of this path. A platform should not assume a manufacturer will hand one over, so teams use DBCs they are licensed to use, build their own from vehicles they own or restrict this path to vehicles they design or equip. On many modern vehicles a gateway also sits between the connector and the internal buses, so a connector-mounted logger may see little broadcast traffic and a deeper tap becomes a hardware decision.

Ingestion shape

CAN logs are bulk data. Loggers upload files per session in batches, and the backend lands them in object storage partitioned by vehicle and day before any decoding. Decoding is a separate, re-runnable job that applies a specific DBC version and writes signals to the time-series store with that version attached. Keeping raw frames pays for itself: when a signal's scale or byte order turns out wrong, a corrected DBC re-decodes history.

Which Path to Choose

The choice follows mostly from who owns the vehicles and how much hardware the operation can support.

Criterion	Dongle, classic J1979	Dongle, J1979-2 vehicles	OEM connected-car API	Raw CAN with DBC
Vehicles you control or customer-owned	Best on owned or leased vehicles; a customer vehicle needs its owner to keep the device fitted	Same as the classic dongle	Fits customer-owned vehicles, since each user authorizes their own vehicle	Vehicles you own, design or equip
Hardware and installation	One device per vehicle, plugged into the diagnostic connector	The same device, with firmware that detects the variant	None in the vehicle	A logger per vehicle, and a deeper tap where a gateway hides the internal buses
Recurring cost type per vehicle	Device hardware and cellular connectivity	Same as the classic dongle	Fees or terms set by each manufacturer's access program; on a Data Act request, access is free of charge to the user and any third-party compensation must be reasonable (Article 9)	Logger hardware, upload bandwidth and storage for bulk logs
Data breadth	The legislated emissions set plus optional PIDs the vehicle supports	The legislated set over UDS, with different trouble-code and readiness structures	Whatever the manufacturer's backend retrieves and chooses to expose	Every frame on the tapped bus, decodable only with the right DBC
Latency	Near real time on a fast polling tier, capped by request-response polling	Same polling limits as the classic dongle	Often last-known snapshots at the manufacturer's interval	Full bus rate on the logger, batch uploads to the backend
Coverage across brands	Any vehicle whose connector answers the classic services	J1979-2 vehicles, once the firmware detects the variant	Only the brands and markets whose manufacturer offers access, through one adapter each or an aggregator	One DBC per vehicle configuration, so coverage grows vehicle by vehicle
Access basis in the EU, besides data protection law	The vehicle owner's agreement; no manufacturer request is involved	Same as the classic dongle	A user request under Article 4 or 5 of the Data Act, or a contract with the manufacturer	Same as the dongle, plus the right to use the DBC

The comparison covers light-duty vehicles. Heavy-duty trucks and many commercial vehicles typically use SAE J1939, the SAE standards family for heavy-duty vehicle networks, which this matrix does not cover.

Battery-electric vehicles need a separate check. The OBD obligation cited above is bound to emissions diagnosis, so a vehicle with no emission control system to monitor may expose little standardized data through the port. Verify per model which services and PIDs it answers before choosing a dongle for an electric fleet.

An OEM API can be reached directly, with one integration per manufacturer, or through a multi-brand connected-car data aggregator that puts several manufacturers behind one interface. Compare the two on brand and market coverage for your vehicles, which fields and update intervals survive the aggregator's normalization, how consent is collected and revoked and whose contract governs the data.

This guide states no J1979-2 phase-in date. Confirm the applicable model years against the regulator's rule for the target market, and confirm which of the fleet's vehicles speak J1979-2 before choosing hardware.

Backend Ingestion and Data Quality

The paths meet in one canonical signal model. Speed from a PID, from an OEM API or from a CAN frame is the same product signal with different sampling and latency, and features should read the signal, not the path. Even a single connector-mounted device can poll PIDs and log broadcast frames in the same session, so the model separates a signal from its source from the start. Every stored value carries provenance: the path, the device or manufacturer adapter, the decoder version (PID table, UDS table, DBC or adapter) and both source and receive timestamps. Keep the raw bytes or payload each value was decoded from, so a corrected PID table, DBC or adapter can re-decode history instead of carrying wrong values forward.

The data-quality failures we design against come from a short list:

• Units and scaling. A wrong PID formula, a wrong DBC offset or an API that switched from kilometers to miles produces plausible wrong numbers that pass a simple range check.
• Missing versus zero. An unsupported PID is not a zero reading.
• Clock drift. Device clocks drift and reset, and receive times include upload delay. Order events by source time and flag device time that moves backwards.
• Identity. Device ID, VIN and account are separate keys with separate lifecycles. A VIN read that failed at ignition-on or an OEM grant passed to a new owner with the car breaks a model that treats them as one, and the damage is silent: two vehicles' trips merge under one history, or one vehicle splits into two.
• Duplicates and gaps. Store-and-forward uploads and webhook retries duplicate data, and dead zones leave gaps. Deduplicate on sequence number or source timestamp, and record gaps so a trip with a hole is not drawn as a straight line.

Trouble codes need their own model rather than a string column: format (classic or UDS), status, reporting ECU, first-seen and last-seen times and whether a clear was issued. The ingestion layer itself, brokers, device identity and time-series storage, follows the same patterns as any connected-device platform, covered in our IoT development guide.

Dongle Security

A device plugged into the diagnostic connector is a network endpoint inside the vehicle, and US authorities warned about exactly that in 2016. In a joint public service announcement of March 17, 2016 (alert I-031716-PSA), the FBI and NHTSA pointed at third-party devices that plug into the diagnostics port, naming insurance dongles and telematics tools as examples, and stated the risk: "The security of these devices is important as it can provide an attacker with a means of accessing vehicle systems and driver data remotely."

The same announcement makes the architectural point a platform team should design around. Where attacking the vehicle through the port once typically required physical presence, "it may be possible for an attacker to indirectly connect to the vehicle by exploiting vulnerabilities in these aftermarket devices." The 2016 announcement names categories of devices, not specific products, and it is a dated warning rather than current guidance, but its logic has not aged.

The controls that follow are our recommended design, not anything the announcement prescribes. Device firmware should allow only the read services the product needs and refuse diagnostic write and control requests. Firmware updates should be signed and verified on the device, and each device should authenticate with its own credential, never a fleet-wide key. On the backend, never expose a generic send-a-diagnostic-frame command, since that one feature turns one compromised operator account into a remote diagnostic channel to every vehicle that account can reach.

The EU Data Act Rule for Vehicle Data

In the EU, Regulation (EU) 2023/2854, the Data Act, sets who may ask for data from connected products, connected vehicles included. A data holder, for vehicle data typically the manufacturer, owes the user access under Article 4(1): "Where data cannot be directly accessed by the user from the connected product or related service, data holders shall make readily available data" accessible to the user, and Article 5(1) extends this to a third party the user chooses: "Upon request by a user, or by a party acting on behalf of a user, the data holder shall make available readily available data" to that third party. One class of recipient is excluded: "Any undertaking designated as a gatekeeper, pursuant to Article 3 of Regulation (EU) 2022/1925, shall not be an eligible third party under this Article". The application rule sits in Article 50: "It shall apply from 12 September 2025."

Article 3(1) of the Regulation adds a design duty for manufacturers and providers of related services: connected products and related services must be designed so product data is, by default and where relevant and technically feasible, directly accessible to the user. That duty has its own start in Article 50: "The obligation resulting from Article 3(1) shall apply to connected products and the services related to them placed on the market after 12 September 2026."

How the Commission reads it for vehicles

The European Commission's guidance on vehicle data is a non-binding reading that by its own text "does not extend or modify the rights or obligations established under the Data Act." It singles out the manufacturer's backend: "In the automotive context, an important example of readily available data includes data generated by a connected vehicle, which are sent to a backend server of the OEM", and adds that this happens "notably under the ‘extended vehicle’ concept. Such data will be readily available to the OEM." It also names the limit that matters for an integrator: "OEMs may, for various reasons, choose to not retrieve or store certain data points on the backend although the vehicle architecture would technically allow for their transmission."

The same guidance sets out the Data Act's scope limits: "The Data Act only mandates making available data which are designed to be retrievable." Raw and pre-processed data are in scope, but inferred or derived information is not: "By contrast, ‘information inferred or derived from such data’ should be considered out of scope of the Data Act." It lists "e. raw controller area network (CAN) bus messages;" among raw data, so raw bus data is not outside the Act merely because it is raw, although the obligation still covers only data that is readily available to the data holder. The guidance also says the Act "does not contain rules regarding access rights to vehicle functions or resources", which means remote lock, remote start or any other command is not a Data Act right and, absent other legislation, is a matter of agreement with the manufacturer.

On the channel, the Commission guidance leaves the choice to the manufacturer: "Data holders are, in principle, free to decide on the means through which access is granted." It is firmer on quality: "The requirement to make available data ‘of the same quality as is available to the data holder’ also entails a rule not to discriminate against the user or third parties such as independent repair shops or other independent service providers." And if the connector is the channel, "Where data holders choose to make available data to the user via the dedicated OBD-II port inside the vehicle, the user cannot be required to purchase a specialised access tool at their own expense".

Acting as a user-chosen third party, a platform should therefore expect a channel the manufacturer picks and no Data Act right to commands or to inferred or derived information. It also takes on Article 6 duties: it may process the data only for the purposes and under the conditions agreed with the user and must erase it when it is no longer necessary for the agreed purpose, unless otherwise agreed with the user for non-personal data. A consent and provenance model that traces each value to the request that authorized it is the design we recommend for meeting that. The same Regulation also sets switching duties for cloud providers, covered in our guide to Data Act cloud switching requirements.

How Pharos Production Helps

We design and build the platform side of vehicle data as part of automotive platform work. For the wider picture of software in the vehicle and around it, our automotive software development guide covers the full stack. To scope a telematics or connected-vehicle platform, talk to our automotive software development team.

Sources: US EPA regulations as published in the eCFR, 40 CFR 86.1806-17, 40 CFR 86.1 and 40 CFR 85.2231; ISO, ISO 15765-4:2021 and ISO 14229-1:2020, cited by title; SAE J1979, SAE J1979-2 (OBDonUDS) and SAE J1939, cited by designation; FBI and NHTSA, public service announcement I-031716-PSA; Regulation (EU) 2023/2854, the Data Act; European Commission, Guidance on vehicle data, C(2025) 6119 final; cantools documentation. Engineering guidance, not legal advice.

FAQ

Last updated: September 28, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• What should be checked on a vehicle before choosing a data path?

  Featured question. Copy link Copies a direct link to this answer to your clipboard.

  Read the VIN and the supported-PID list with a scan tool, note whether the vehicle answers classic J1979 requests or only J1979-2, and try to read a true odometer rather than a distance counter. Then check whether the manufacturer offers API access in the market where the vehicle runs and whether a gateway limits what a connector-mounted logger can see.

  Run the check on one vehicle of each model and model year in the fleet, since the answers can differ within one brand.

• How can a J1979-2 decoder be tested before it reaches production?

  Copy link Copies a direct link to this answer to your clipboard.

  Build a replay set of captured request and response pairs from vehicles of both variants, with the expected decoded values recorded by hand, and run every decoder release against it. Include a vehicle that answers only J1979-2 to prove the variant detection, and feed classic responses to the UDS decoder on purpose: the test passes only when the decoder refuses them instead of returning plausible values.

• What should a platform log to answer a consent audit for OEM API data?

  Copy link Copies a direct link to this answer to your clipboard.

  Keep an append-only record of every consent event per vehicle with its source, time and scope: the grant received, each scope change, the revocation and the moment the platform stopped pulling. Link every stored value to the grant that was active at its source timestamp, so the platform can show which authorization covered any value it holds and which values it discarded after a revocation.

• How can a platform detect that a dongle was moved to another vehicle?

  Copy link Copies a direct link to this answer to your clipboard.

  Compare the VIN read at each ignition-on with the VIN bound to the device, and treat a mismatch or a failed read as an identity event rather than ordinary telemetry. When the VIN read fails, secondary signals help: a different supported-PID list, a jump in the distance counter or a first position far from where the last trip ended.

  Hold the incoming data apart until the binding is confirmed, so it never lands in the wrong vehicle's history.

• What does keeping raw vehicle data cost?

  Copy link Copies a direct link to this answer to your clipboard.

  Raw CAN logs are the largest item, because they hold every frame on the tapped bus rather than the few signals a product decodes, so storage grows with the number of vehicles, the hours they run and the traffic on each tapped network. Plan for compressed, tiered object storage, a retention period tied to how long decoded history must stay correctable and the compute cost of re-running decoding jobs.

  Raw dongle responses and API payloads are small by comparison.

• What should happen when a user revokes consent for an OEM API?

  Copy link Copies a direct link to this answer to your clipboard.

  The platform should stop pulling for that vehicle as soon as the revocation arrives and discard any value whose source timestamp falls after it, including data from a pull that was already in flight. Data received before the revocation then follows the platform's retention rules, which have to respect Article 6(1) of the Data Act where it applies, erasing data once it is no longer necessary for the purpose agreed with the user unless the user agreed otherwise for non-personal data, and data protection law where the data is personal.

  Decide those rules before the first vehicle is connected.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.