Build a why loop around every trace
Generated from
content/lms/data-interpretation-ii-advanced/01-beyond-the-basics/03-the-why-loop.md; edit the source file, not this page.
Source path: content/lms/data-interpretation-ii-advanced/01-beyond-the-basics/03-the-why-loop.md
Course: Read the data your hands can't feel
Module: Move past speed traces and guesswork
Estimated duration: 55 minutes
A trace is not an answer. A trace is the start of a conversation.
That is the skill in this lesson. You are learning to turn a line on a data screen into a useful driving change without fooling yourself. The method is simple to say and harder to practice: identify what changed, ask why it changed, confirm the reason with another channel when you can, compare it against another lap or driver, then turn the conclusion into one specific change for the next session. That chain is the why loop.
The reason this matters is that data can show you a symptom long before it proves a cause. A speed trace can show a smaller minimum speed, a lazy acceleration ramp, or a change in deceleration slope. A throttle trace can show coasting, hesitation, early application followed by a lift, or lifts in fast corners. A brake trace can show a strong first hit and a smooth release, or it can show indecision. Lateral and longitudinal g can show whether you are using the car consistently, whether the peaks are repeatable, and whether the car is being loaded in a smooth enough way to be useful. None of those observations, by itself, tells the whole story. The data gives you a question. Your job is to keep asking why until the question becomes a driving plan.
This lesson sits after the basic comparison skills in this module. You should already understand that laps should be overlaid by distance, that you should compare the same piece of track, and that channels must be audited before you trust them. We will not re-teach those mechanics here. This lesson starts once the trace is aligned well enough to inspect and the channel is credible enough to believe. Your job now is interpretation: not just what happened, but why it happened, whether that why is supported, and what you will do differently.
The mistake intermediate drivers make is stopping one step too early. They see time lost at the end of a straight and decide they need earlier throttle. They see lower minimum speed and decide they braked too much. They see a throttle lift in a fast corner and decide they lacked commitment. Sometimes those are right. Sometimes they are exactly wrong. Earlier throttle may have caused a later lift. A lower minimum speed may have been the price paid to get better exit speed. A fast-corner lift may have been traffic, vision, a mental image problem, or a car-position problem that began two references earlier. A why loop protects you from treating the visible symptom as the root cause.
A useful why loop has five moves.
First, name the observable. Do not start with judgment. Say what the trace actually shows. The red lap loses speed at 1600 yards. The throttle is not at full between two turns. The brake trace has a hard initial application and then a late second squeeze. The longitudinal g peak is lower than the other lap in the braking zone. The lateral g trace spikes instead of building and holding. This first move matters because vague language creates vague fixes. If you say you were messy, you have no next-session task. If you say you coasted for half a second before brake application, you have a place to work.
Second, ask the first why. Why did the observable happen? This is where you generate hypotheses, not verdicts. If speed dropped, was it brake pressure, throttle lift, steering angle, line, traffic, or a mental hesitation? If throttle opened late, was it because the car was not pointed, because you over-slowed entry and waited, because you were still finishing brake release, or because you did not trust the exit? If the brake release looked uneven, was the corner entry speed too high, did the reference point move, did traffic distract you, or did you turn in before completing the pressure release you intended?
Third, confirm or weaken the hypothesis with another channel. If you think a speed dip came from braking, look at brake pressure or longitudinal g. If you think it came from throttle, look at throttle position and acceleration rate. If you think it came from line or steering, use steering angle if you have it, lateral g, video, and the track map position. If you think the problem is coasting, confirm that the throttle is closed while brake pressure is also absent, and then look at the speed trace to see what the car was doing during that dead time. The point is not to collect channels for decoration. The point is to keep each channel honest by asking another channel to support the story.
Fourth, compare. Compare the same segment to another lap, another driver, another session, or another car when the comparison is legitimate. You are looking for consistency and priority. A single odd trace may be a one-off caused by traffic or a missed reference. A repeated shape across laps is much more likely to be your technique or mental program. A big delta-time loss tells you where to spend attention first. A faster lap that is slower at one point may teach you that the lost speed was an intentional trade for a better exit. This is why the goal is not to admire the fastest lap. Sometimes the fastest lap hides the most useful lesson because the best pieces are spread across multiple laps.
Fifth, turn the why into a next-session instruction. A data conclusion is unfinished until it becomes a behavior you can drive. The instruction should be small enough to execute under speed. Do not leave the paddock with improve braking. Leave with turn into West Bend from the same brake point, but release five percent sooner and check whether the minimum speed rises without delaying full throttle. Do not leave with be braver downhill. Leave with hold maintenance throttle past the reference cone, then decide after video whether the lift was caused by traffic or by entry placement. The why loop ends with an experiment.
The loop has to stay disciplined because racing data is seductive. A graph looks precise, so it is easy to treat your first interpretation as precise. But driver data is a record of a human operating a car on a specific piece of pavement with weather, traffic, confidence, vision, track knowledge, and mental programming all mixed together. Ross Bentley’s data instruction repeatedly uses the same pattern: look at a channel, ask why, confirm with other channels if available, compare with other laps, and only then interpret. That sequence is the backbone of this lesson.
Start with the speed trace, but do not end there.
Speed is the most tempting channel because it seems closest to lap time. It is also the easiest channel to misread. On a speed graph, you can see acceleration and deceleration rate, coasting before the brake, failure to reach full throttle between turns, throttle lifts where they should not happen, trail braking in slow to mid-speed corners, and shifting issues. That is already a lot. But every one of those observations still needs a why.
If the speed trace flattens before the braking zone, you may be coasting. The correction might be to stay on throttle longer before a decisive brake application. But do not assume. If the throttle is still open and the speed has stopped climbing, maybe you were at the car’s acceleration limit or climbing a hill. If the throttle closed early and the brake did not begin, then the coast is real. If the video shows traffic ahead, the coast may have been a situational decision rather than a technique habit. If three clean laps show the same coast in the same place, now you probably have a driver habit to fix.
If the speed trace shows a change in deceleration slope, you may be seeing trail braking. A single speed trace can suggest it because the car does not decelerate at one constant rate all the way to turn-in; the slope changes as the brake is released while the car is being asked to turn. But the speed trace alone cannot tell you whether that trail braking was good. You need brake pressure to confirm the pressure release, and then you need the corner result. Did the car rotate and carry speed? Did the brake release delay throttle? Did the minimum speed improve but exit suffer? The why loop asks not only whether trail braking happened, but whether it helped the lap.
If the speed trace shows that one lap had the highest front-straight speed but still became the worst lap, the why loop stops you from worshiping the peak number. A high speed at one point may have been bought at too high a price somewhere else. The faster lap may have come from a better exit onto the front straight, not from a more heroic moment at the end of it. The data-for-drivers example at Lime Rock shows exactly this kind of trap: a yellow lap can start with the highest front-straight speed and still be the worst lap, while a different lap can begin that segment slower and produce the faster overall result. Your job is to find the trade, not crown the biggest number.
The throttle trace tells you what you believed.
Throttle position is not just an input channel. It is a confidence channel. When you see coasting, hesitant application, early application followed by a lift, or lifts in fast corners, you are seeing the driver’s belief about the car and the track. The trace shows the foot, but the why may live in vision, mental image, car placement, traffic, or the timing of brake release.
A hesitant throttle application usually means you did not know that the car would accept the throttle. That can be mechanical, but for a driver-learning lesson, first ask whether the hesitation follows from the previous phase. Were you late releasing the brake? Did you pinch the car toward the apex and leave no exit room? Did you turn in without a clear exit reference? Did you ask too much steering angle while trying to accelerate? A throttle trace can show the hesitation, but the reason may be written earlier in the corner.
Early throttle followed by a lift is especially important. Many drivers think earlier throttle is always better because exit acceleration matters so much. But a throttle trace can expose false early throttle: the foot goes down before the car is ready, the car runs out of room or grip, and the driver has to lift. In the why loop, that is not a success because the first throttle event occurred early. It is a failure if the early application delayed full throttle, caused a correction, or cost speed down the straight. The useful question is when the car accepted throttle continuously.
A lift in a fast corner needs careful handling. The trace may reveal a confidence problem, but the first repair should not be a blind order to hold it flat. Ask why the lift happened. Did the car arrive with too much steering angle? Was the driver late seeing the exit? Was there traffic? Was the line wrong? Was the lift a response to a real grip limit? Was the driver protecting the car because the track was wet or dirty? The data-for-drivers material explicitly points from throttle lifts to the why question, and even in examples of hesitant laps it asks whether traffic was involved and says to check video. That is the standard: before you prescribe bravery, find the cause.
The brake trace tells you whether your commitment was organized.
A useful brake trace is not merely high pressure. The data-for-drivers examples call out the shape: hard initial application and a nice release. That shape matters because braking is not just a speed-reduction task. It sets the car’s entry speed, its load transfer, and its readiness to turn. In a clean why loop, you inspect not only how much pressure was used, but when it started, how quickly it built, how smoothly it released, and whether the release matched the steering and throttle that followed.
If brake pressure is inconsistent from lap to lap, ask whether the brake point moved, whether the driver’s vision moved, whether traffic or a pass changed the approach, or whether the driver lacked a clear mental program for that corner. If the first brake hit is soft and then pressure rises late, the driver may have delayed commitment and then tried to recover. If the release is lazy, the car may stay loaded too long and delay throttle. If brake and throttle overlap in the wrong part of the corner, the data may show a blend that delays getting to full throttle. The trace points to the place; the why loop decides whether the behavior was a technique problem, a response to circumstances, or a deliberate compromise.
Brake pressure also helps you avoid mislabeling speed-trace features. A change in deceleration slope might suggest trail braking, but brake pressure confirms whether pressure was actually still present. A lower minimum speed might look like too much brake, but if brake pressure was lighter and throttle was delayed, the issue might be corner placement or hesitation. A quick pressure spike might look decisive, but if longitudinal g does not build correspondingly, you may be looking at grip, surface, or sensor questions. The why loop keeps the brake trace connected to the rest of the car.
The g traces tell you whether the car was loaded and whether the loading was repeatable.
Lateral g and longitudinal g are useful because they describe the car’s response rather than only the driver’s commands. Lateral g asks whether you are consistently using peak cornering load, whether there are spikes in either direction, and whether the pattern repeats lap to lap. Longitudinal g asks whether braking and acceleration peaks are being used consistently, whether deceleration rate points to a braking issue, whether acceleration rate points to an exit issue, and whether the shape repeats.
The important word is consistently. A single high g spike can be a mistake, a curb strike, a correction, or a momentary surface feature. A smooth, repeatable build and hold of lateral load tells a different story. A strong, repeatable longitudinal decel peak may show that the driver is approaching the brake zone with a clear plan. A weak or wandering longitudinal trace may match a hesitant brake trace. The why loop uses g traces to test whether the car did what the driver input suggested it should do.
Be careful with g traces because they can seduce you into chasing peaks. Driving at the limit is not a collection of isolated peak numbers. Bentley’s driving-at-the-limit explanation is about building the tire’s braking, cornering, or acceleration forces and keeping them there. As you turn in, the brake comes off as steering comes on; as you unwind steering, acceleration increases. That means the useful trace is often a coordinated exchange, not a single heroic spike. If you use too much steering angle for the amount of braking or acceleration, or ask the reverse combination, you can exceed the traction limit and misdiagnose the result as a car problem. A why loop asks whether the driver asked the tire for the right blend at the right time.
The track gives the why loop its context.
Data interpretation without track knowledge is weak. Every racetrack has its own personality. Even tracks that appear similar can feel different because of surface, radius, camber, elevation, hillcrests, curbing, and straight length. The same speed loss may mean one thing on a flat constant-radius corner and another on a downhill corner where the driver is unloading the car or managing confidence. The same throttle lift may be a bad habit in one place and a reasonable response to traffic, camber, surface, or placement in another.
That is why the why loop should be tied to a track map and notes. After a session, write down where you brake, where you release, where you get back to full throttle, what references you used, where the surface changes, where the curbs begin and end, and which pieces of track were difficult. Draw the track as you see it, not only as the printed map presents it. Your personal map carries the mental model you actually drive. When the trace shows a problem at a particular distance, your notes help you remember what that distance meant in the car.
This is also where the why loop connects to mental programming. Bentley describes driving at the limit as developing a clear mental program, triggering it, and trusting it. Data helps you revise that program. If your trace shows a lazy throttle release and a hesitant application at the same corner every lap, you do not simply tell yourself to try harder. You update the mental program: reference point, brake shape, release timing, vision target, throttle acceptance point, and exit room. Then you rehearse it before the next session. The data is the evidence; the mental program is the thing you actually execute at speed.
The loop should always end in one priority.
Intermediate drivers often create too many assignments from one data review. They find coasting in Turn 1, late throttle in Turn 3, a brake release problem in Turn 5, and a lift in a fast corner, then go out with four repairs in mind. That is too much. Use delta or compare time to find the largest useful difference, then choose the change that is both valuable and executable. If the biggest time loss comes from a speed reduction at one segment, start there. If a smaller trace issue explains a larger downstream loss, start upstream. If a data issue is interesting but not costly, put it in your notes and save it.
A good next-session objective has a trace prediction. Before you drive, state what should change if your why is correct. If you think the problem is coasting before braking, the next trace should show throttle maintained longer, brake pressure beginning more decisively, and no dead band between the two. If you think the problem is a lazy brake release, the next trace should show a cleaner release and earlier continuous throttle without a lift. If you think a fast-corner lift is traffic, the lift should disappear on a clean lap but remain when traffic appears. If the trace does not change as predicted, your why was incomplete.
This prediction step is what turns data into learning instead of post-session entertainment. You are not just explaining the previous lap. You are creating an experiment. That is why Bentley’s note-taking advice matters: write objectives before the session, then write conditions, changes, and results after. The same discipline that makes a car engineer useful also makes a driver useful to himself. You want to avoid learning the same thing twice.
Here is the full loop in plain language.
Name what the trace shows. Ask why it happened. Check another channel. Compare the same section to another lap or driver. Check video or notes when human context may matter. Decide whether the issue is driver technique, circumstance, car behavior, or an intentional compromise. Choose one next-session experiment. Predict what the traces should look like if the experiment works. Drive it. Review again.
That is the why loop. It is slow at first, but it is how you build a data habit that improves your driving instead of decorating your paddock routine. Over time, the questions become faster. You will look at a throttle lift and automatically ask whether it came from entry placement. You will see a speed dip and immediately check brake, throttle, and video. You will stop arguing with isolated numbers and start building supported explanations. That is when data begins to shorten the learning curve.
Worked example: Lime Rock speed loss at 1600 yards
Imagine you overlay two laps at Lime Rock Park and the compare-time trace points to a loss near 1600 yards. The red lap loses speed there and the time-lost graph shows the cost. The novice version of the analysis would stop at the speed trace and say the red lap was slower. The why-loop version starts by naming the observable more precisely: at the same distance on the same piece of track, the red lap has a reduction in GPS speed and gives up time.
Now ask why. The data-for-drivers prompt gives the right list of suspects: throttle lift, braking, steering angle, or line. You do not choose one because it feels familiar. You check. If brake pressure appears where the other lap has none, braking is part of the cause. If throttle position closes where the other lap stays open, the lift is part of the cause. If steering angle is available and shows a larger or later steering demand, the car may have been placed or aimed differently. If the video shows traffic, the driver may have made a situational choice.
The important move is the next why. Suppose brake pressure explains the speed drop. You are still not done. Why was there brake pressure there? Was the driver reacting to traffic? Did the driver enter with too much speed because the previous brake point moved? Was the driver looking too near and lacking a clear exit picture? Was the mental image of the corner wrong? The bonded material explicitly warns that data does not give all the answers and points to vision, mental image, bravery, and traffic as possible causes. Those are not soft excuses; they are real driving causes that may not live cleanly inside the data channel.
The next-session experiment depends on the answer. If video shows traffic, the action is not to force the throttle open in traffic. The action is to tag the lap as compromised and compare clean laps. If the brake trace appears on several clean laps at the same distance, the action may be to revise the reference and carry a different entry or maintenance-throttle plan. If throttle closes before the brake and video shows no traffic, the experiment may be to remove the coast, not to move the brake point. If steering angle is large before the lift, the experiment may be a line and vision change rather than a pedal change.
A clean review note for this example might read this way: Red lap loses time at 1600 yards from a speed reduction. Brake pressure confirms an actual brake input, not just throttle lift. Video shows no traffic. Steering channel unavailable. Next session: same approach speed, eyes to exit earlier, avoid the extra brush of brake, and verify whether speed stays up without delaying full throttle on exit. That note is useful because it contains evidence, a likely why, a scoped experiment, and a trace prediction.
Worked example: Lime Rock fastest piece versus fastest lap
The Lime Rock multi-lap example is a good warning against interpreting one peak number as success. In the data-for-drivers material, one lap has the highest front-straight speed starting the lap and still becomes the worst lap time. Another lap has the lowest front-straight speed leading to the fastest lap. That sounds backward only if you treat speed as a trophy instead of a consequence.
Run the why loop. First, name the observable. Yellow begins the lap with the highest front-straight speed but ends with the worst lap time. Red begins that segment with the lowest front-straight speed and leads to the fastest lap. The observable is not simply that yellow was fast or red was slow. The observable is a trade across the lap.
Ask why. Did yellow arrive at the front straight quickly because of an earlier corner exit, but then compromise the next braking zone? Did the driver spend too much time in a previous corner to gain a speed number that did not pay back? Did yellow carry speed into a section that forced a later lift, a softer brake shape, or a poorer line? Did red give up a little at the start to place the car better for a later section? The trace invites those questions because lap time is built from connected pieces, not isolated glory moments.
Confirm with other channels. If yellow has a higher speed but then shows a throttle lift, lazy throttle release, or hesitant application later, the peak speed was not the whole story. If brake pressure on yellow shows a larger or later correction in the next braking zone, the driver may have bought the front-straight number at the cost of entry. If lateral g shows a spike or inconsistent load, the car may have been placed poorly or asked for too much. If red is calmer and more repeatable through the next section, its lower starting speed may have been the better compromise.
The driving lesson is not to avoid speed. The lesson is to ask where the speed came from and what it cost. Bentley’s cornering framework says you want to spend as little time in the corner as possible and get maximum speed out by accelerating early, but often you must compromise one goal for the other depending on the track layout and the car. The why loop is how you decide whether a particular compromise worked. If the higher local speed did not improve the lap, do not chase it blindly. Find the combination of entry, midcorner, and exit that improves the segment and the next segment together.
Worked example: West Bend and Downhill hesitation
The West Bend and Downhill example gives you a more complete why loop because it includes speed, throttle, brake pressure, and the human question. The notes identify several observations: a good brake-pressure trace shape with a hard initial application and a nice release, a possibility that the brake for West Bend could be lighter, a need to minimize throttle lift for Downhill, and a possible blend of throttle and brake that may delay full throttle. The same page describes the lap as hesitant, with brake trace inconsistencies, lazy throttle release, and hesitant throttle application. Then it asks why and points to traffic and video.
Start with the observations separately. For West Bend, the brake shape may be fundamentally good, but the amount may be too much. That is an important distinction. Do not throw away a good brake shape just because the corner might accept less brake. The experiment could be lighter pressure or earlier release while preserving the hard initial application and smooth release. For Downhill, the issue may be a throttle lift. Again, do not prescribe courage first. Ask why the lift occurred.
Now connect the channels. A lazy throttle release before a brake zone can create a dead zone where the car is neither being driven forward nor slowed decisively. A hesitant throttle application after brake release can delay the exit. If brake and throttle overlap in a way that delays full throttle, the trace may reveal that the driver is not making one clean transition. That is a driver-input rhythm problem, but the why could still be track-specific experience. The note says the lighter brake for West Bend takes experience at that track, which means the data is showing both a technique opportunity and a learning-stage reality.
The next-session plan should be conservative and specific. Do not attempt to fix West Bend brake amount, Downhill lift, and every hesitation everywhere in one session. Pick the section with the biggest time cost or the clearest safety margin. For West Bend, a good plan might be to keep the same brake point, keep the first pressure application decisive, reduce peak or release slightly earlier, and check whether minimum speed improves without delaying full throttle. For Downhill, a good plan might be to use video first: if the lift happens only in traffic, mark it as context; if it repeats on clean laps, revise the vision and placement plan before asking the foot to stay down.
This example also shows why the why loop is not anti-instinct. If the lap looks hesitant, that impression is useful. But it becomes actionable only when tied to specific channels: brake inconsistencies, lazy throttle release, hesitant throttle application, and video context. The loop turns a paddock impression into a driving experiment.
Drill: the three-pass why-loop review
Use this drill at your next event after every session where you have usable data and at least one clean lap. It should take 12 to 18 minutes, and the success criterion is a written next-session experiment with a trace prediction.
Pass one is the symptom pass. Pick one section of track, preferably the section with the largest compare-time loss or the clearest repeated inconsistency. Spend no more than three minutes naming only what the traces show. Write short observable statements: throttle closed before brake, brake release has second squeeze, speed flattens between turns, lateral g spike at turn-in, full throttle delayed until track-out. Do not write causes yet.
Pass two is the why pass. For each observable, write at least two possible causes. If speed drops, list brake, throttle, steering, line, traffic, or shifting as appropriate. If throttle is hesitant, list car not pointed, late brake release, lack of exit vision, traffic, or early throttle followed by correction. If brake pressure is inconsistent, list moved reference, uncertainty, traffic, entry speed, or mental program. The goal is to prevent the first explanation from becoming the only explanation.
Pass three is the confirmation pass. Check one other channel for the leading hypothesis. Use brake pressure or longitudinal g for braking questions. Use throttle position and acceleration rate for exit questions. Use lateral g, steering if available, video, and track notes for line and confidence questions. If the confirmation is weak, change the hypothesis or mark it unresolved. If the issue could be traffic, check video before turning it into a technique assignment.
End with one experiment. Write it in driver language and include a prediction. For example: remove the coast before Turn 3 by staying at throttle to the brake marker, then making one decisive brake application; prediction is no flat speed plateau before brake and no later loss at corner exit. Or: reduce the West Bend brake slightly while keeping the same initial shape; prediction is a higher minimum speed with no delay to full throttle. If you cannot write the prediction, you have not finished the loop.
Run this drill for three sessions in a row. In session one, practice clean observation. In session two, improve confirmation with another channel. In session three, compare the prediction against the new trace. The drill is successful when your review note contains an observable, a supported why, one next-session action, and whether the new data confirmed or rejected the idea.
Common mistakes
Mistake one is treating the fastest lap as the only useful lap. The fastest lap matters, but it may not contain your best braking, best throttle application, best minimum speed, and best exit all in one place. The data-for-drivers material warns that if you only look at the fastest lap, you can miss important information. Good looks like comparing useful pieces and asking what would happen if the best pieces were put together.
Mistake two is calling every speed loss a bravery problem. A lift or speed reduction can come from traffic, vision, mental image, brake timing, steering angle, line, surface, or a real grip limit. Good looks like checking throttle, brake, steering or lateral g, and video before deciding what the driver should do differently.
Mistake three is fixing the pedal trace while ignoring the corner that created it. Late throttle may not be a throttle problem. It may be a brake-release problem or a car-placement problem. Extra brake may not be a braking problem. It may be a vision or confidence problem. Good looks like reading backward from the symptom to the preceding phase.
Mistake four is chasing peak numbers. Highest straight speed, highest lateral g, or hardest brake pressure can all look impressive and still fail to improve the lap. Good looks like asking whether the number helped the connected section: entry, middle, exit, and the following straight.
Mistake five is using data without track notes. The same trace shape means different things on different surfaces, radii, cambers, and elevations. Good looks like connecting the graph to your own track map, reference points, surface notes, curbs, weather, and traffic memory.
Mistake six is leaving the review with a vague command. Try harder, brake later, or be smoother is not a useful next-session plan. Good looks like one specific experiment with a prediction the next trace can confirm or reject.
Cross-references: where this lesson connects
This lesson depends on the earlier module skills but does not replace them. Use overlay-by-distance before you interpret a corner-to-corner difference, because the why loop assumes you are looking at the same piece of pavement. Use same-segment comparison before you decide where the lap was won or lost, because a time-based comparison can point you at the wrong part of the lap. Use channel trust and channel audit before you believe a suspicious trace, because a why loop built on bad data only produces a more elaborate wrong answer.
It also connects forward into mental programming and session notes. Once the data review gives you a supported why, you still have to drive the change. That means writing the objective before the next session, rehearsing the relevant part of the track, and returning afterward to record whether the experiment worked. Bentley’s broader coaching message is that reading and understanding are only useful if they become practice. The why loop is the bridge between the screen and the steering wheel.
Author Review
No quiz questions are attached to this lesson.
Sources
| # | Document | Chunk | Pages | Score | Collection |
|---|---|---|---|---|---|
| 1 | Data-for-Drivers-PRINT | ec2b5633-0f92-b587-99f2-6f5044efc092 | 1 | 1 | uio_books_raw_v1 |
| 2 | Data-for-Drivers-PRINT | c440bd03-cdb9-90b2-ddf1-f8335740fa28 | 1 | 1 | uio_books_raw_v1 |
| 3 | Data-for-Drivers-PRINT | ba11efce-fa7b-39cf-f1bf-2bbfddb3acaa | 1 | 1 | uio_books_raw_v1 |
| 4 | Data-for-Drivers-PRINT | 27a86c4f-e78b-a3ac-5011-0bb82408d23d | 1 | 1 | uio_books_raw_v1 |
| 5 | Data-for-Drivers-PRINT | c76265b3-e38e-d9dd-45b1-10446beb0a9b | 11 | 1 | uio_books_raw_v1 |
| 6 | Data-for-Drivers-PRINT | c10154dc-b033-8e12-98ae-b40ab858909d | 11 | 1 | uio_books_raw_v1 |
| 7 | Data-for-Drivers-PRINT | e400d8d0-9169-48ff-7827-758ad23a1b6c | 5 | 1 | uio_books_raw_v1 |
| 8 | Data-for-Drivers-PRINT | c3ad98bc-4cf4-8d17-0522-135212a121f4 | 5 | 1 | uio_books_raw_v1 |
| 9 | Data-for-Drivers-PRINT | eaae7953-9633-80b8-0643-2f672eb66708 | 7 | 1 | uio_books_raw_v1 |
| 10 | Data-for-Drivers-PRINT | 45ae5ff1-23c9-fc57-4bfa-5ae8023b6962 | 9 | 1 | uio_books_raw_v1 |
| 11 | Data-for-Drivers-PRINT | c279a711-b54f-10d6-886c-8fc067176272 | 9 | 1 | uio_books_raw_v1 |
| 12 | Ultimate Speed Secrets - Ross Bentley | 1dbf972c-aef7-3111-aa9c-9fec3776319f | 567 | 1 | uio_books_raw_v1 |
| 13 | Ultimate Speed Secrets - Ross Bentley | 8a59dd5c-bd92-7571-3b97-879bd28ffbf5 | 109 | 1 | uio_books_raw_v1 |
| 14 | Ultimate Speed Secrets - Ross Bentley | d64f3ac3-8ef8-0bfd-1ea5-ca5dc9d308c0 | 197 | 1 | uio_books_raw_v1 |
| 15 | Ultimate Speed Secrets - Ross Bentley | d9e68831-bd2e-fb43-8e6b-a89a77ab090c | 152 | 1 | uio_books_raw_v1 |
| 16 | Ultimate Speed Secrets - Ross Bentley | a9a648d9-5c51-dce8-aed0-7835e25db48e | 211 | 1 | uio_books_raw_v1 |
| 17 | Ultimate Speed Secrets - Ross Bentley | 6054ef2e-10b7-b9ee-1f7a-ab71e3b5d037 | 513 | 1 | uio_books_raw_v1 |
| 18 | Ultimate Speed Secrets - Ross Bentley | da4318b3-e49b-f6b8-133a-236b8f480ea6 | 318 | 1 | uio_books_raw_v1 |
| 19 | Ultimate Speed Secrets - Ross Bentley | 4e5da4b9-9759-43f4-6f55-67017525d3a9 | 120 | 1 | uio_books_raw_v1 |
| 20 | Ultimate Speed Secrets - Ross Bentley | 4400491c-451f-86fc-590c-1fa83983aef9 | 12 | 1 | uio_books_raw_v1 |