Turn driver feel into the next system check

Generated from content/lms/race-car-mechanic-reference/06-service-each-system-by-evidence/05-connect-system-checks-to-driver-feedback.md; edit the source file, not this page.

Source path: content/lms/race-car-mechanic-reference/06-service-each-system-by-evidence/05-connect-system-checks-to-driver-feedback.md

Course: Service the race car that has to finish

Module: Service each system by evidence

Estimated duration: 55 minutes

Principle: a feeling is a symptom, not a work order

The purpose of this lesson is to make driver feedback useful without letting it turn into guesswork. After a session, the driver usually comes back with a sentence that sounds simple: the car would not turn, the brake pedal felt wrong, the rear was nervous, the car felt flat off the corner, or the front felt light when the brake came off. Those sentences matter, but they are not yet a system check. They are symptoms. Your job is to turn the symptom into a specific question that can be checked against the car, the driver inputs, and the next-session objective.

The central rule is this: do not translate driver feel directly into an adjustment. Translate it first into a time, a place, a phase of the corner, and a measurable contradiction to check. Ross Bentley describes two common problems with drivers who struggle to develop a car: they are not sensitive enough to what the car is doing, and they do not communicate what they feel very well. He also warns against the driver trying to do the engineer's job by naming the adjustment before explaining the sensation. For this lesson, that becomes the mechanic's debrief discipline. You are not trying to make the driver sound technical. You are trying to protect the evidence chain.

Data acquisition gives you the second half of that chain. The point of logging is not to admire traces after the fact. It is to record what the car and driver are doing, measure performance, learn from it, and use that information the next time the car goes on track. The same analysis ideas apply across levels of machinery because the dynamics of the vehicle and driver remain the same. A club HPDE car and a race car have different budgets, but the question after a complaint is still the same: what did the driver do, what did the car do, and do those two stories agree?

That is why driver feel and system checks belong together. Feel tells you where to look. Data and inspection tell you whether the feeling matches a driver-input problem, a car-response problem, a condition problem, or a sensor-story problem. If you skip the feel, you can waste time hunting graphs with no practical question. If you skip the evidence, you can bolt parts onto a misunderstanding.

What the driver must report

Good feedback is not fancy. It is located. You want the driver to describe when the feeling happened, what they were doing with their hands and feet, and whether it repeated. A useful debrief answer has four coordinates.

The first coordinate is location. The driver should identify the corner, straight, braking zone, transition, or section. If the corpus gives you a named track map, use that. If it does not, use the driver's own references: the brake marker, the turn-in area, the apex zone, the exit curb, or the fast bend where confidence dropped. Carl Lopez frames the fast lap as a plan made of specific points: brake there, shift there, turn in at that spot, take a specific apex, apply power in a deliberate way, and use the exit edge. That plan is your language for debriefing. A complaint that cannot be attached to one part of the plan is still too vague to drive a check.

The second coordinate is phase. Corner entry is not one thing. Lopez breaks entry into smaller blocks: the throttle-brake transition, straight-line deceleration, and brake-turn. Each block asks a different question of the car. In the throttle-brake transition, the issue may be the driver's timing, the speed of the pedal switch, or the car's reaction to the first load transfer. In straight-line deceleration, the tires are being asked mainly to brake, so you can look hard at whether the driver reached the intended deceleration and whether the brake trace was short, long, hard, light, or inconsistent. In brake-turn, the car is being asked to decelerate and change direction at the same time, so a balance complaint belongs with brake-release shape, steering demand, line, and speed.

The third coordinate is input. Ask what the driver was doing when the sensation appeared. Was the brake being applied, held, trailed, or released? Was throttle application hesitant, early, partial, or followed by a lift? Was steering angle building smoothly or being added in a second bite? Was the driver shifting, approaching the limiter, or using the wrong gear for the section? The Data for Drivers process points directly at these traces: brake pressure shape, throttle trace, steering, RPM, gear, GPS line, G-sum, total steer angle, segment time, fastest rolling time, theoretical fastest time, and throttle histogram. You do not need every channel on every car. You need enough channels to check the driver's story against the car's recorded behavior.

The fourth coordinate is repeatability. One strange moment may be traffic, a missed reference, tire state, or driver timing. A repeated sensation in the same phase of the same section is a stronger clue. Segers describes comparative analysis as the way to reveal the effect of setup changes or driver performance by comparing different laps or runs with earlier data. That means the debrief should always ask whether the feeling was consistent lap to lap. If it appeared once, label it as a single event. If it appears every lap, it becomes a system-check priority.

The mechanic's translation loop

Use a five-step loop. First, capture the driver's plain-language feeling without correcting it. Second, anchor it to location, phase, input, and repeatability. Third, choose the smallest set of channels or inspections that can test the story. Fourth, look for congruence or incongruence. Fifth, set one objective for the next session.

The first step matters because drivers often overreach when they want to help. Bentley's point is that the driver's job is to report what they feel, not to command the adjustment. The driver may have enough knowledge to suggest a possible direction, but the useful part comes first: understeer after brake release, front unloading quickly, instability when throttle is picked up, or hesitation before full throttle. If the report starts with a part change, bring it back to sensation and timing. The proposed change can be noted, but it should not replace the symptom.

The second step turns the report into a checkable problem. Suppose the driver says the car is lazy on entry. That can mean slow hands, too much entry speed, long brake release, front tire saturation, a line that pinches the apex, or a setup issue. Ask where the laziness starts. If it begins at first brake pressure, you are in the throttle-brake transition or straight-line deceleration. If it begins when the wheel is turned while the brake is still on, you are in brake-turn. If it appears only after brake release, the check shifts again. This step prevents the common paddock mistake of treating every balance word as if it points to the same system.

The third step chooses evidence. The Data for Drivers process is explicit about looking for incongruencies, digging for details, using other channels when available, asking why, comparing when possible, calibrating to the driving, imagining what ideal would look like, and setting objectives for the next session. That sequence is practical. If the driver says the car will not rotate on brake release, start with brake pressure shape, speed, steering, GPS line, and segment time before you decide whether a hardware check is justified. If the driver says the car feels flat on exit, start with throttle trace, RPM, gear, acceleration rate, and any lift after an early throttle application. If the driver says a fast corner is scary, start with steering, throttle, lifts, GPS line, G-sum, and lap-to-lap consistency.

The fourth step is the congruence check. Congruence means the driver report, the input trace, and the vehicle response all point in the same direction. Incongruence means something does not fit. A driver may report no grip at entry, while the brake trace shows a very long, light pedal application that gives away speed too early. A driver may report poor exit power, while the throttle trace shows coasting or a hesitant application. A driver may report instability in a fast corner, while the data shows a lift every lap at the same place. The point is not to blame the driver. The point is to separate a system problem from a plan, timing, or confidence problem before you service the wrong thing.

The fifth step is the next-session objective. Do not end the debrief with a cloud of possible causes. End it with one target. For example: repeat the same brake marker and release shape for three clean laps; pick up throttle once and avoid the corrective lift; hold the same gear and confirm the acceleration trace; or gather comparison laps before touching the car. This comes straight from the analysis process: compare if you can, calibrate to the driving, imagine the ideal, and set objectives for the next session. A system check is not complete until it tells the driver or crew what evidence to collect next.

How to map feelings to checks without overreaching

A braking complaint should first be mapped to the brake trace and corner phase. The brake pressure trace can show initial application, trail, a long tail, inconsistent pressure, or the difference between light-and-long and hard-and-short. Lopez's straight-line deceleration block explains why this matters: when the car is straight, the tires are not being asked to corner, so the car can decelerate at its maximum rate unless the driver deliberately brakes below threshold for a reason. If a driver says the brakes are weak but the trace shows early, light, long braking with speed given away before turn-in, the next check may be driver technique and consistency before a brake-system service. If the driver reports a changed pedal or inconsistent pressure and the trace agrees, the brake-system lesson in this module becomes the next reference.

A throttle or exit complaint should first be mapped to throttle trace, RPM, gear, and acceleration rate. Data for Drivers asks whether the driver is coasting, hesitating, applying throttle early and then lifting, or lifting in fast corners. Those are different problems. Coasting can make a car feel slow without any powertrain fault. Hesitant application can make the exit feel flat because the driver never gives the car a clear request. Early application followed by a lift can feel like a power or traction problem when the first issue is timing. RPM and gear help you separate the driver's gear choice from the engine's response. If those channels look clean and the car still does not accelerate as expected, then the powertrain-reliability lesson becomes the next check.

A steering or balance complaint should first be mapped to steering, total steer angle, GPS line, G-sum, and segment time. A driver who adds more and more steering for the same path is reporting something important, but you still need to know whether the extra steering came from excess entry speed, a line that asks too much of the front, brake release timing, or a vehicle-response change. Segment reports and comparison laps help you avoid being fooled by one corner that feels dramatic but costs less time than a quieter section. Theoretical fastest and fastest rolling views can also show whether a problem is isolated or part of a wider driving pattern.

A fast-corner confidence complaint deserves special care. Data for Drivers specifically calls out lifts in fast corners on both throttle and brake process slides. A lift in a fast corner can be a driver-confidence marker, a line problem, a balance problem, or a genuine system issue. The check is not to tell the driver to be braver. The check is to find where the lift happens, whether steering demand changes at the same time, whether the GPS line is repeatable, whether G-sum drops, and whether the same event appears lap after lap. Only then can you decide whether to coach the commitment, check the tire and suspension evidence, or inspect for a fault.

A shifting or engine-speed complaint should be mapped to RPM, gear, acceleration rate, and section time. The corpus does not give you a full powertrain diagnostic procedure here, so do not invent one in this lesson. The useful method is narrower: make sure the driver actually requested acceleration in the same gear, at comparable RPM, in comparable sections, before treating the complaint as a mechanical system problem. If the driver changes gear timing every lap, the system check is not yet clean. If the same gear, same throttle request, and same section repeatably show weak acceleration, then you have earned a deeper powertrain check.

Sub-skill 1: listen for sensation before solution

The first sub-skill is disciplined listening. A driver can be technically knowledgeable and still make the debrief worse by skipping straight to a fix. Bentley's example is useful because it separates three layers: the sensation, the driver's interpretation, and a possible adjustment direction. The sensation is the car understeering just after brake release. The interpretation is that the front unloads too quickly. The possible adjustment direction is controlling the rate of front-end unload. In a good debrief, you preserve that order.

For the mechanic, this means asking questions that move from feel to evidence. What did it feel like? When did it start? What were you doing with brake, throttle, and steering? Was it the same every lap? Did the car do it before the setup change? Did it appear with traffic or on clear laps? The goal is not to interrogate the driver. The goal is to help the driver produce a report that is precise enough to test.

Sub-skill 2: separate driver action from vehicle response

The second sub-skill is separating the request from the response. Brake pressure, throttle position, steering input, RPM, and gear describe what the driver asked for. GPS line, speed, G-sum, segment time, and acceleration rate describe what the car did with that request. A system check becomes much cleaner when you keep those categories separate.

For example, a driver may say the car would not take throttle. The request side asks whether the throttle was actually applied, whether it was delayed, and whether an early application caused a later lift. The response side asks whether acceleration followed the request, whether RPM and gear made sense, and whether the section time improved or fell away. If the request is inconsistent, fix the request or run a cleaner test. If the request is consistent and the response is wrong, the car has earned closer inspection.

Sub-skill 3: compare before concluding

The third sub-skill is comparative thinking. Segers emphasizes comparing laps or runs to reveal the effect of setup changes or driver performance. Going Faster's back-cover material describes data acquisition being used to show a speed difference between two drivers in the same track section, with the difference caused by one driver slowing too much in the first half of the corner. That is exactly the kind of comparison that protects you from a false mechanical diagnosis. If two traces show the same car in the same section and one driver gives away speed early, the car did not necessarily become slow. The driver plan changed.

Comparison does not require a professional engineer. Compare the driver's best clear lap to the complaint lap. Compare before and after a change. Compare the first half of the corner to the second half. Compare the driver input trace to the vehicle response trace. Compare the current session to a known-good session if the conditions are close enough. Keep the comparison simple and directly tied to the driver's report.

Sub-skill 4: calibrate the driver's feel

The fourth sub-skill is driver calibration. Bentley argues that sensitivity to the car can be developed by focusing on sensory input, and he names Sensory Input Sessions as the way he knows to do it. For this lesson, calibration means the driver gets better at connecting sensations to phase and evidence. Over time, the report should evolve from vague balance words to specific, repeatable descriptions. The driver should be able to say that the problem starts after the brake comes off, that the steering demand rises at the same path, that throttle application is clean but acceleration is not, or that the fast-corner lift happens before the car actually moves.

That improvement helps the mechanic. A sensitive driver who communicates clearly reduces wasted checks. A vague driver forces the crew to inspect broadly or chase the driver's suggested fix. The goal is not to make the driver an engineer. The goal is to make the driver a reliable sensor.

Sub-skill 5: set the next system check at the right depth

The fifth sub-skill is choosing how deep to go. Not every complaint deserves a wrench immediately. Some complaints deserve a driver objective. Some deserve a data comparison. Some deserve a physical inspection. Some deserve a full service check. The evidence decides.

If the trace contradicts the complaint, do not ignore the driver, but do not service the wrong system either. Run a cleaner comparison or refine the driver's plan. If the trace confirms the complaint and the sensation is repeatable, inspect the most relevant system. If the driver report is precise but the available channels are thin, choose the simplest next observation: pressure trend, pedal feel, steering angle, RPM and gear, line overlay, or section time. The Data for Drivers reminder to keep it simple and focus on the basics is especially important here. A basic check done cleanly beats a complex theory built on a vague report.

Calibration cues: how you know this skill is improving

You are improving when debriefs get shorter and more precise. The driver stops saying only that the car is bad and starts naming location, phase, input, and repeatability. The mechanic stops asking broad questions and starts choosing the next check from the reported phase. The data review stops wandering through every graph and starts with the channels that can confirm or contradict the driver's report.

You are improving when the same pattern appears in more than one form of evidence. The driver reports an entry problem, the brake pressure trace shows the relevant release shape, the steering trace shows rising demand, and the GPS line shows the same path change. Or the driver reports poor exit, the throttle trace shows hesitation, RPM and gear explain part of it, and the segment time confirms where the loss occurs. Congruence does not automatically prove the fix, but it proves that the team is asking a coherent question.

You are improving when next-session objectives become specific enough to pass or fail. A vague objective is to make the car better. A useful objective is to repeat the brake release at the same point and see whether the understeer appears, to make one clean throttle application and see whether the exit trace improves, or to compare two clear laps before changing the car. If the next session produces evidence that answers the question, the system-check process is working.

You are improving when fewer parts are touched for uncertain reasons. This module has separate lessons on tires, brakes, suspension, and powertrain reliability because those systems matter. This lesson sits before them. It tells you which door to open. When the driver report and the data both point to brake pressure inconsistency, go to the brake evidence lesson. When tire state is the likely interface problem, go to the tire evidence lesson. When the report is really about brake-release balance, do not redesign the suspension before you have checked the simpler evidence.

Failure modes to watch for

The first failure mode is fix shopping. The driver comes in with a part-change request, and the crew treats it as the diagnosis. This is exactly the shortcut Bentley warns against. The recovery is to translate the requested change back into sensation, timing, and response. Ask what the driver felt that made the requested change seem attractive.

The second failure mode is global language. Words like loose, tight, slow, dead, nervous, and inconsistent are useful only after they are located. A car can understeer at brake release and oversteer at throttle pickup in the same corner. A brake complaint can be about initial bite, release, consistency, or driver pressure shape. The recovery is to put the word inside a corner phase.

The third failure mode is one-channel certainty. A throttle trace can show a lift, but it cannot by itself tell you why the driver lifted. A brake trace can show a long tail, but it still needs speed, steering, and line context. Segers notes that confidence can be allocated to certain sensor readings for dynamic behavior analysis, which is a reminder that channels have trust levels and context. The recovery is to use other channels when available and look for incongruencies.

The fourth failure mode is single-lap drama. A lap with traffic, a mistake, or a missed marker can create a vivid driver memory. Comparative analysis protects you by asking whether the pattern repeats against other laps or runs. The recovery is to label single events honestly and gather another clean sample before changing the car.

The fifth failure mode is data without a driving plan. Lopez's driver has a plan for every point on the track. Without that plan, the data is harder to interpret because you do not know what the driver intended. The recovery is to reconstruct the intended plan: brake point, shift point, turn-in, apex, throttle pickup, exit target. Then compare the trace to the plan.

Where this lesson stops

This lesson does not teach the full service procedure for tires, brakes, suspension, or powertrain. The sibling lessons cover those systems. Your job here is the handoff. Driver feel becomes a precise symptom. The symptom becomes a checkable question. The question is tested against driver inputs, vehicle response, comparison laps, and repeatability. Only then do you choose the next system lesson or the next driver objective.

If the bonded evidence for a complaint is thin, say so. The corpus here supports the translation process, the communication discipline, and the main driver-input channels. It does not supply numeric acceptance limits, torque values, damper-click recommendations, or detailed physical inspection thresholds. Do not invent those. A disciplined mechanic can still do valuable work: locate the feeling, check the channels, compare the runs, ask why, and send the car back out with a cleaner objective.

Worked example: brake-release understeer becomes a brake-turn check

The driver comes in after a session and says the car will not turn after the brake comes off. The weak version of this debrief is to ask whether the driver wants more front grip and then reach for a setup change. The stronger version follows the translation loop.

First, locate it. Ask whether the push starts at initial brake pressure, during straight-line deceleration, while the driver is combining brake and steering, or just after release. Bentley's handling-development example is directly useful here because the sensation is understeer just after brake release, with the front feeling as though it unloads too quickly. That is not yet a command to change a shock. It is a phase-specific symptom.

Second, choose the check. Start with brake pressure shape, especially the trail and release tail. Add speed, steering, GPS line, G-sum, and segment time if those channels are available. If the brake trace shows an abrupt release every lap, the front may be losing the load the driver was relying on for rotation. If steering angle jumps after release, the driver may be asking the front tires to do more after the useful load has gone away. If speed is higher than the comparison lap at the same point, the driver may be carrying a different problem into the release.

Third, compare. Use a better lap from the same driver or a known-good lap from the same car if available. Look for whether the understeer report appears with the same brake-release shape and same steering demand. If the comparison lap has a smoother release and less steering for the same line, the next session objective may be a driver-input repeatability test before a hardware change. If the driver repeats the same clean input and the car still unloads too quickly, the system check has earned a deeper look in the brake or suspension evidence lessons.

The success criterion is not that you guessed the correct adjustment in the paddock. The success criterion is that the driver's feeling now points to a precise question: during brake-turn and release, does the recorded input and car response support the claim that the front unloads too quickly?

Worked example: same-section speed loss before blaming the car

The driver reports that the car feels slow through a section. The car is not obviously broken, and the complaint is not tied to a single system. This is where comparison is more useful than speculation.

Going Faster describes a data-acquisition example showing the speed difference between two drivers in the same section of a race track, with the difference caused by one driver slowing too much in the first half of the corner. That situation is the classic trap. From the seat, the slower driver may experience the car as unwilling, dull, or lacking exit speed. The trace may tell a simpler story: the driver gave away speed too early, then spent the second half of the corner living with that choice.

Turn the complaint into a section check. Compare speed through the first half and second half of the corner. Add brake pressure to see whether one lap is light-and-long while another is harder-and-shorter. Add throttle trace to see whether the driver coasts before pickup or applies early and lifts. Add steering and GPS line to see whether the car is being placed differently. Add segment time to keep the discussion honest.

If the loss begins before the driver asks the car to accelerate, do not start with a powertrain check. If the loss begins during braking, do not start with a spring change. If the loss appears only on laps where the driver hesitates on throttle, do not call it an engine issue. The next system check is chosen by the first place the evidence diverges.

Worked example: fast-corner lift as a confidence and evidence problem

The driver says a fast corner feels unstable. The risky response is to either dismiss the driver as nervous or immediately inspect every chassis part. The evidence response is narrower.

Data for Drivers calls out lifts in fast corners as something to look for in throttle and brake process work. Start there. Find the fast corner in the data, then check whether the throttle trace shows a lift at the same point each lap. If it does, add steering, GPS line, G-sum, and segment time. A repeated lift with a stable line and no matching steering event may be a confidence or reference-point issue. A repeated lift with a steering correction or G-sum change may deserve a deeper balance or tire/suspension check. A lift that appears only in traffic or on one lap should not drive a permanent setup decision.

The important move is to preserve both truths. The driver felt something real enough to lift. The system check determines whether the car created the event, the driver anticipated the event, or the line and speed choice created the feeling. The next objective might be a repeatable reference and throttle commitment test, or it might be a physical inspection if the evidence repeats with clean driver input.

Drill: three-session feel-to-check loop

Use this drill at the next event to train the driver and mechanic together. It uses three sessions. The count is three debrief cycles, one after each session. The duration is five minutes of debrief, ten minutes of focused data or note review, and one written next-session objective per cycle. The success criterion is that each cycle ends with one checkable question, not a list of guesses.

Session one is the sensory-input session. Before the run, tell the driver to pick one recurring sensation to report, not the whole car. The driver should come back with location, phase, input, and repeatability. The mechanic's job is to keep the driver out of fix language. If the driver proposes an adjustment, ask what sensation led to that proposal.

Session two is the congruence session. Use the channels you have. For a brake or entry complaint, start with brake pressure shape, speed, steering, and line. For an exit complaint, start with throttle trace, RPM, gear, and acceleration. For a fast-corner complaint, start with lifts, steering, line, G-sum, and consistency. The goal is to decide whether the driver's story and the evidence agree, disagree, or are too thin to judge.

Session three is the objective session. Send the driver out with one task derived from the evidence. Repeat the brake release. Remove the throttle hesitation. Hold the same gear. Reproduce the line. Gather two clean comparison laps before changing the car. After the session, decide whether the evidence improved. If the driver executed the task and the symptom remains, the relevant system check moves up in priority. If the symptom disappears with cleaner input, record that finding instead of changing the car.

Common mistakes and what good looks like

Mistake one is taking adjustment requests literally. The driver says to stiffen, soften, add, remove, raise, or lower something. Good looks like asking for the sensation first, then the phase, then the repeatability. The proposed adjustment can be recorded as the driver's interpretation, not the starting point.

Mistake two is accepting vague balance language. The driver says the car is tight or loose without saying where. Good looks like locating the word in the driving plan: throttle-brake transition, straight-line deceleration, brake-turn, brake release, throttle pickup, or fast-corner commitment.

Mistake three is comparing dirty laps. A lap with traffic, a missed marker, or a different gear can make the wrong system look guilty. Good looks like comparing clear laps, checking consistency lap to lap, and labeling abnormal laps before drawing conclusions.

Mistake four is staring at one trace. A brake trace, throttle trace, or steering trace can start the investigation, but the Data for Drivers process tells you to use other channels when available. Good looks like checking the driver's request against the car's response.

Mistake five is chasing complexity before basics. Data for Drivers ends with the reminder to keep it simple and focus on the basics. Good looks like answering the smallest useful question first: did the driver request the same thing, did the car respond the same way, and did the issue repeat?

Cross-references inside the module

Use this lesson as the gatekeeper for the system-specific lessons around it. If the translated symptom points to tire state, pressure behavior, or the tire as the contact interface, go to the tire evidence lessons. If the symptom and brake pressure trace point to brake consistency, release behavior, pedal behavior, or deceleration repeatability, go to the brake-system lesson. If the symptom survives clean driver input and points to balance or platform response, go to the suspension check lesson before redesigning anything. If throttle, RPM, gear, and acceleration evidence point beyond driver request, go to the powertrain reliability lesson.

The handoff matters because each system lesson can go deeper once this lesson has narrowed the question. Without this handoff, every complaint becomes a whole-car problem. With it, the team knows what evidence made a system worth checking.

Author Review

No quiz questions are attached to this lesson.

Sources

#	Document	Chunk	Pages	Score	Collection
1	Ultimate Speed Secrets - Ross Bentley	32569ef6-9e67-12c5-e001-2ae0feacb49d	531	1	uio_books_raw_v1
2	Data for Drivers	cabda699642b26311b0a7ef998da2c71	15	1	uio_books_raw_v1
3	Going Faster Mastering the Art of Race Driving - Carl Lopez	3b70eb1f-e4e3-c70c-1221-c2c8a8e43d83	51	1	uio_books_raw_v1
4	Analysis Techniques for Racecar Data Acquisition	d0db9128-dc9a-aec3-14a8-5f101654753f	3	1	uio_books_raw_v1
5	Analysis Techniques for Racecar Data Acquisition	ad559d04-3651-61c2-d02b-5455aba0d7cc	7	1	uio_books_raw_v1
6	Analysis Techniques for Racecar Data Acquisition	b7da1ef7-f9f8-c734-bdb6-c1aa09e017fe	5	1	uio_books_raw_v1
7	Going Faster Mastering the Art of Race Driving - Carl Lopez	4285b990-c3e7-880e-5596-99af145b469c	300	1	uio_books_raw_v1
8	Data-for-Drivers-PRINT	b80dc634-a0a7-d6de-d470-353aed47e2a6	17	1	uio_books_raw_v1