Handoff work without assumptions

Generated from content/lms/race-car-mechanic-reference/02-build-records-and-checklists/05-handoff-work-without-assumptions.md; edit the source file, not this page.

Source path: content/lms/race-car-mechanic-reference/02-build-records-and-checklists/05-handoff-work-without-assumptions.md

Course: Service the race car that has to finish

Module: Build records and checklists that catch failures

Estimated duration: 55 minutes

The skill in one sentence: a good handoff turns invisible status into verifiable car state.

That sounds clerical until you have lived through a race weekend. The car is on stands, the session clock is moving, one person finished a brake job, another person changed pressures, someone else downloaded data, and the driver is asking whether the car is ready. In that moment, assumptions become mechanical risk. The problem is not that people are careless. The problem is that race work is divided, interrupted, time pressured, and dependent on tiny details. When more than one person is involved, it is easy for each person to believe the other person completed the missing detail. The source material says this directly in the context of checklists: with multiple people involved, each may assume the other has done everything. That is the core failure this lesson trains out.

A handoff is not a polite update. It is not a hallway summary. It is not the sentence, the left front is done. A handoff is the transfer of responsibility for a defined piece of car state, including what was intended, what was changed, what was checked, what evidence supports that statement, what remains open, and what the next person must do before the car runs. If the next mechanic, engineer, or crew chief cannot make a safe decision from your handoff, the handoff is incomplete.

This lesson sits beside the lessons on assembly checklists, pre-session checks, service life, and packing from failure history. Do not treat it as a replacement for those. The assembly checklist tells you how to perform and verify a subsystem build. The pre-session checklist tells you what must be checked before the car goes out. The service-life record tells you when a part is aging toward failure. The handoff is the bridge between people and time. It keeps those documents from becoming isolated islands.

The principle: state, evidence, and next action.

Every useful handoff answers three questions.

First, what is the car's current state? This is the factual part. Which subsystem was worked on, which setup was installed, which adjustment changed, which checklist items were completed, which items are still open, and which conditions apply. A race-car record system exists because memory alone is not reliable enough. The mechanic and manager material emphasizes records, do-lists, checklists, schedules, and planning as dull but critical clerical work. The driver-record material makes the same point from the cockpit side: keep details from each race, practice, test, or qualifying session, and write down objectives, conditions, changes, required changes, and results. If drivers and engineers need records to avoid learning the same thing twice, mechanics need records to avoid doing or assuming the same thing twice.

Second, how do you know? This is the evidence part. A statement such as brakes checked is weaker than a statement that identifies the relevant assembly checklist, the pre-race checks, the fluid level, the fasteners, the adjustment, and any data channel or second look used to confirm the work. The data-analysis chunks give a useful mental habit: start with an overview, look for incongruencies, dig for details, use other channels when available, ask why, compare if you can, calibrate to the specific driving or car, imagine the ideal, and set objectives for the next session. For handoff work, those are not just data habits. They are verification habits.

Third, what happens next? This is the action part. A handoff that says what happened but not what remains forces the recipient to rebuild the plan from scratch. The source material on team management recommends revising do-lists at short intervals and breaking jobs into Must do, Important, and Also. That priority structure belongs inside handoffs. The next person should know whether they are inheriting a safety-critical item, a performance-development item, or a convenience item that can wait.

The mechanism: why assumptions survive in race shops.

Assumptions survive because most race work is partially visible. You can see that a wheel is installed. You may not see whether the fasteners were torqued at final ride height, whether the pressure target was changed after the last session, whether a pad inspection found uneven wear, whether a setup change was made without the compensating adjustment, or whether a data trace supported the driver's complaint. You can see activity, but activity is not evidence.

Assumptions also survive because experienced people get bored with repetition. The mechanic source warns that an experienced mechanic may tire of the checklist, graduate from it, and eventually ignore or forget some tiny detail that costs the race. That is not an insult to experience. It is the reason professional habits exist. The more familiar the job, the more important the external record becomes, because familiar jobs are exactly where the brain starts filling gaps.

Assumptions also survive because testing and setup work can look meaningful while being methodologically weak. The aerodynamic testing chunk describes a disciplined comparison of two wings: run each configuration for a defined number of laps, change only the wing configuration, average the lap times, discard abnormal times, and return to baseline periodically when conditions may change. That is a test discipline lesson, but it is also a handoff lesson. If a crew member says the new wing was better but cannot say what else changed, whether the baseline was revisited, how many laps were used, whether track or tire conditions shifted, and what the driver reported about balance, the next person has inherited a conclusion without the method that produced it.

A handoff without method creates false confidence. A handoff with state, evidence, and next action lets the next person continue without guessing.

The handoff standard.

Use this standard whenever work changes hands, especially across sessions, across days, across crew members, or across subsystems.

1. Name the scope.

Start with the car, subsystem, side or corner if relevant, session context, and time. Do not make the recipient infer what you are talking about. A setup note that only says changed rear wing is weaker than a handoff that says the rear wing configuration was changed for the second test run after the baseline run. A brake note that says LF done is weaker than one that names the left-front brake assembly and connects it to the assembly checklist or pre-race checklist.

Scope also includes what you did not touch. If you rebuilt the front brakes but did not inspect the rear, say that. If you changed ride height but did not compensate camber because the next step belongs to the alignment person, say that. The race-data acquisition chunk gives an example of a ride-height change without camber compensation as a setup relationship the engineer must understand. In handoff terms, the lesson is simple: a change that normally drags another check behind it must be handed off with that relationship visible.

2. State the objective.

A task without an objective is hard to judge. The driver-record source recommends writing down the objectives for each session and the driving techniques or plans needed to achieve them before the session, then recording conditions, changes, and results after the session. Use the same structure for mechanical work. Before the job, write what the job is supposed to accomplish. After the job, hand off whether that objective was met and what evidence says so.

For example, the objective might be to return the car to pre-race readiness after qualifying, to isolate a brake-pressure inconsistency, to compare two aero configurations, or to prepare the car for a session where the driver will evaluate balance. The objective controls what evidence matters. If the objective is safety and durability, the Must do items dominate. If the objective is aero comparison, the baseline, variable control, lap count, sector speeds, and driver balance feedback dominate. If the objective is a data-driven brake concern, the brake-pressure trace, consistency of pressure, and relationship to driver comments matter.

3. Separate completed work from verified work.

This is one of the most important habits in the lesson. Completed means the action was performed. Verified means the action was checked against a standard or independent evidence. Those are not the same thing.

The checklist source lists detailed assembly checklists for areas such as engine installation, suspension assembly, and brake rebuilding, plus pre-race checklists for fluid levels, tire pressures, fasteners, and adjustments. That tells you the work world is naturally layered: assembly, pre-race readiness, logistics, and records. When you hand off, say which layer you completed and which layer still needs verification.

A useful sentence structure is: action completed, evidence checked, open item remaining. For example: left-front brake assembly completed from the brake rebuild checklist, fluid level still needs final pre-session check after pedal pressure is confirmed. Or: tire pressures set to the current target, but final hot-pressure review belongs after the next session. The exact values belong in your team record; the lesson here is that handoff language must distinguish work from proof.

4. Record changes and reasons.

Race cars move too fast for undocumented changes. The driver-record source asks for notes on what changes were made and need to be made to the car, and what the results of the session were. The simulation and data acquisition source says a good log of simulation runs and results should be kept for later reference so the engineer can make decisions and remove guesswork. The aero testing source shows why: if you change more than one variable, or if you fail to account for changing conditions, you weaken the result.

A handoff should never say simply setup changed. Say what changed, why it changed, what baseline it came from, what result is expected, and what the next observation should be. If only one configuration change was intended, say that only that configuration change was made. If weather, track condition, or tire deterioration may have affected the result, say that too. The recipient should not have to discover later that the apparent improvement might belong to tires, conditions, or an unrecorded second change.

5. Make open work impossible to miss.

Open work is where assumptions do the most damage. The source material's Must do, Important, and Also categories are a simple way to prevent that. A handoff should not bury an incomplete safety item among convenience tasks. If a car cannot run until an item is finished, that item belongs in Must do. If it affects performance or the quality of the next test but not immediate safety, that is Important. If it is useful but not session-blocking, it is Also.

Do not overfill the Must do category. If everything is Must do, the category stops communicating. But do not soften a safety or durability item because you want the handoff to sound tidy. The team-management material is blunt about priority: there are endless projects to make a race car faster or more reliable, so some priority must be established. Your handoff is one of the places where that priority becomes operational.

6. Include conditions that change the meaning of the work.

A setup or test result is not only a car state; it is a car state under conditions. The driver-record source asks for date, car, lap times, fastest car's lap time, weather, track conditions, reference points, gears, surface changes, elevation changes, and challenging track sections. The aero testing source adds that weather, track conditions, and tire deterioration can change the baseline during a session. For mechanical handoff, you do not need to write a driver's track notebook, but you do need to include condition changes when they affect the job.

If a tire set is aging across test runs, say so. If the track is changing and a baseline run has not been repeated, say so. If the driver feedback on balance came from a higher-speed corner where aero effects are more visible, say so. If a data trace shows inconsistent brake pressure, say whether it was consistent lap-to-lap or changed with conditions. Conditions are not decoration. They tell the next person how much confidence to place in the conclusion.

7. End with the next action.

The next action should be concrete enough that the recipient can begin. Set objectives for the next session. That phrase appears in the data process chunk, and it is the right closing move for a handoff. Do not end with should be fine. End with what to check, what to watch, what to compare, and what decision the next observation should support.

For example: next session objective is to confirm whether brake pressure is consistent after the rebuild; compare driver comment to brake-pressure trace shape and pressure consistency. Or: next run returns to baseline wing configuration to account for track and tire change; compare average lap and sector times, then record driver balance feedback. Or: morning crew must complete pre-race fluid, pressure, fastener, and adjustment checks before warmup.

The handoff loop.

Use this loop whenever you are about to hand work to another person.

Start with overview. What is the whole situation? The data process chunk begins with overview because details only make sense inside a frame. In mechanic handoff, the overview is the car state, the session context, and the reason the work was done.

Look for incongruencies. If the driver's complaint does not match the data, if the setup sheet says one thing and the car appears to show another, if a checklist item appears complete but the evidence is missing, stop and resolve it or flag it. Incongruity is not an annoyance. It is a clue that the handoff could transfer a wrong assumption.

Dig for details. A handoff improves when the important detail is visible: which adjustment, which checklist, which result, which remaining check. The source material says to dig for details in data review. The same habit belongs in mechanical work.

Use other channels if available. In data work, this means checking another channel. In mechanic work, it may mean comparing the setup sheet to the car, comparing driver feedback to data, comparing the checklist to the physical state, or comparing the do-list to the work board. Do not rely on one channel when another is available and relevant.

Ask why. This is not a philosophical exercise. Why was the change made? Why is the job still open? Why did the result change? Why is the priority Must do rather than Important? The data chunks repeat the why habit because it prevents shallow interpretation. Handoffs need the same defense.

Compare if you can. Compare to the baseline, to the previous session, to the prior setup, to the driver's known notes at the track, or to the expected ideal. The aero testing material shows that returning to baseline can be crucial when conditions drift. The driver-record material shows that prior track notes become valuable when returning to the same track. A handoff that includes the comparison point gives the next person orientation.

Calibrate to the car and session. The data chunk says to calibrate to your driving; in mechanic handoff, calibrate to this car, this driver, this session, this tire set, and this objective. A note that is adequate for an end-of-day development list may be inadequate for a pre-race safety check.

Imagine the ideal. This does not mean invent a perfect answer. It means state what the clean result would look like. If the ideal is a controlled aero comparison, only one configuration changes, each configuration gets a defined run, abnormal laps are handled, and the baseline is revisited if conditions move. If the ideal is pre-race readiness, the relevant fluid levels, tire pressures, fasteners, and adjustments are checked. If the ideal is a data-supported brake investigation, the brake-pressure trace has a clear shape and consistent pressure rather than a confusing long tail or inconsistent application.

Set the next objective. A handoff that ends with the next objective prevents the recipient from guessing what the previous person intended.

Worked example: aero test handoff.

You are working a test where two rear wing configurations are being compared. The goal is not to produce a dramatic opinion; the goal is to generate meaningful information. The aero source describes the useful structure: each configuration is run over a defined number of laps, only the wing configuration changes, average lap times are recorded, abnormal times are discarded, and the team periodically returns to baseline because weather, track conditions, and tire deterioration can change the reference.

A weak handoff says the second wing was faster. That may be true, but it is not enough to inherit. The next person cannot tell whether the wing was the only change, whether tire deterioration affected the later run, whether the result came from one unusual lap, whether sector times show where the gain appeared, or whether the driver felt a balance change in the relevant speed range.

A strong handoff says the objective was to compare rear wing configuration A against configuration B. It names the baseline configuration. It says configuration B was the only intended change. It records the number of laps used for each run, notes any abnormal laps that were excluded from the average, includes lap and sector results if available, and adds driver feedback on aerodynamic handling balance. If conditions changed, it states whether baseline was repeated. If baseline was not repeated, it flags the conclusion as provisional.

The next action might be to return to the baseline configuration during the next window before committing to the setup, or to run the second configuration again if the first comparison was contaminated by weather, track change, or tire deterioration. That handoff lets the next engineer continue the test rather than accept a loose conclusion.

Worked example: brake-corner handoff before a session.

You inherit a car after a brake-related job. The checklist source explicitly names brake rebuilding as a place for a detailed assembly checklist, and it also names pre-race checks for fluid levels, tire pressures, fasteners, and adjustments. The data source adds brake-pressure trace questions: initial application shape, trail, long tail, inconsistent pressure, light and long versus hard and short, and lifts in fast corners. Those are not all mechanic checklist items, but they are useful evidence if a brake concern is being investigated.

A weak handoff says brakes done. That statement hides too much. Which corner? Was this assembly work or only a pre-session inspection? Were the fluid level and fasteners checked? Was any adjustment changed? Was the concern mechanical, driver feel, or data trace? What still needs to be checked before the car runs?

A strong handoff names the subsystem and corner, identifies whether the brake rebuild checklist is complete, names the pre-session checks still required, and records any reason the work was performed. If the job began because the driver or data suggested inconsistent braking, the handoff tells the next person what to compare after the next run: driver comment, brake-pressure trace shape, pressure consistency, and whether the concern repeats. If the job is not verified, the open item is marked Must do and cannot be hidden among lower-priority work.

The next action might be a final pre-session check of fluid level, fasteners, and adjustments, followed by a post-session comparison between the driver's report and brake-pressure data. The handoff is useful because it connects wrench work to evidence.

Worked example: setup handoff from simulation or engineering work.

A setup idea can come from outside the physical adjustment range or from simulation work. The data acquisition source says simulation runs and results should be logged for later reference so the engineer can make setup decisions and remove guesswork. It also warns by example that a ride-height change without camber compensation is a meaningful relationship. That is exactly the kind of relationship a handoff must preserve.

A weak handoff says try lower ride height. The mechanic may perform the visible action and miss the related setup consequence. A strong handoff says what run or decision produced the change, what physical adjustment is requested, whether a related compensation is required, and what result will be evaluated afterward. If the related compensation cannot be completed in the current work window, it becomes an open item rather than an invisible assumption.

This is especially important when the next person is not the person who produced the simulation or setup decision. The person doing the work needs enough context to avoid making the car state inconsistent with the engineering intent.

Common mistakes.

Mistake 1: treating the handoff as a conversation instead of a record. Conversations are useful, but they disappear under pressure. The correction is to leave a written state that survives interruption. The record does not need to be elegant. It needs to answer state, evidence, and next action.

Mistake 2: saying done when you mean touched. A task can be physically touched, assembled, inspected, verified, or ready to run. Those are different states. The correction is to use precise verbs: assembled, checked, verified, open, needs final check, or ready for pre-session inspection.

Mistake 3: hiding open work. Open work is not embarrassing. Hidden open work is dangerous. The correction is to place remaining items into Must do, Important, or Also and make the Must do items impossible to miss.

Mistake 4: changing more than one variable and handing off a conclusion. The aero-test source shows why disciplined comparison matters. If several things changed, do not hand off a clean cause-and-effect conclusion. Hand off the changes, the limits of the comparison, and the next baseline or repeat needed.

Mistake 5: failing to record conditions. A setup or test result can be distorted by weather, track change, and tire deterioration. The correction is to include the condition that changes interpretation, especially when the team will make a decision from lap times, sector times, speed, or driver balance feedback.

Mistake 6: trusting experience over checklist discipline. Experience is valuable, but the source warns that experienced mechanics can tire of checklists and miss tiny details. The correction is to let the checklist carry the repetition so experience can focus on judgment.

Mistake 7: collecting data without asking why. Data channels, lap times, sector times, driver comments, and physical checks only help if you use them to answer a question. The correction is to state the objective before the work and set the next objective at handoff.

Calibration cues: how you know your handoffs are improving.

A good handoff changes the behavior of the next person. They ask fewer basic status questions. They can name what is complete and what remains. They can tell which items block the next session. They can compare the current car state to the previous baseline. They do not repeat the same inspection only because the previous note was unclear.

A good handoff also improves the team's records. When the car returns to the same track, the team can look back and understand what was tried, what conditions applied, what changed, and what result followed. The driver-record source says this information becomes invaluable when returning to the same track. The same is true for the crew. A handoff that becomes part of the record prevents the team from relearning the same lesson.

In data-supported work, your handoff should make later review easier. The next person can compare lap times, sector times, speeds, GPS line, g-sum, steering, throttle, brake pressure, RPM, gear, or other available channels against the stated objective. You do not need every channel for every job. The cue is that the channels you do use answer the question you wrote down.

In test work, your handoff should protect the baseline. If conditions change, the team knows whether baseline was repeated. If abnormal laps were discarded, the team knows that the average was not built from a misleading sample. If only one variable was intended to change, the handoff confirms whether that discipline held.

In safety-critical work, the cue is simpler: there is no ambiguity about whether the car can run. If a Must do item remains, no one has to discover it by asking around.

The drill: three-handoff progression at your next event.

Use one subsystem for the whole drill. Choose brakes, suspension, tires, aero, or another subsystem your team actually touches. Do not choose the whole car. The point is to practice clarity, not produce a giant document.

Handoff 1 happens before the first session. Write the objective, the baseline state, and the checks that must be completed before the car runs. Keep it short but complete. Success criterion: another team member can read it and tell you what must be true before release.

Handoff 2 happens immediately after the session or work period. Record what changed, what was checked, what evidence you have, what conditions matter, and what remains open. Success criterion: the recipient can identify completed work, verified work, and open work without asking you to translate.

Handoff 3 happens before the next session. Use the previous handoff to set the next objective. If the last session raised a question, say what the next session should confirm. If the car is ready, say which checklist or checks support that. If it is not ready, mark the blocking item Must do. Success criterion: the team does not re-argue the status from memory.

Run the drill for three sessions or three work periods. At the end, review the handoffs against five questions: Was the scope clear? Was the objective clear? Was evidence included? Were open items prioritized? Was the next action clear? If one of those questions fails, rewrite the handoff in a tighter form.

Recovery when an assumption is discovered.

When you discover an assumption, do not patch it with another assumption. Stop and rebuild the state from evidence.

First, identify the exact unknown. Is the unknown whether the work was completed, whether it was verified, whether a setup change was recorded, whether a baseline is still valid, or whether an open item blocks the next session?

Second, compare records and car state. Use the checklist, do-list, setup sheet, data, and physical inspection as available. The data process says to look for incongruencies and use other channels when available. That is the recovery method.

Third, ask why the assumption appeared. Was the checklist skipped? Was the open item not prioritized? Was the handoff verbal only? Did two people each believe the other owned the item? The mechanic source warns exactly about shared assumptions when multiple people are involved. The fix should address the ownership gap, not only the immediate car state.

Fourth, write the corrected handoff before work resumes. If the handoff is not corrected, the same ambiguity will reappear for the next person.

A practical handoff template.

Use this template when you need structure. It is intentionally small enough to use at the track.

Scope: car, subsystem, side or corner, session or work period.

Objective: what this work or session was meant to accomplish.

Baseline: previous setup, previous condition, or prior reference point.

Work completed: actions performed.

Evidence checked: checklist, measurement, inspection, data channel, comparison, or second verification.

Changes made: adjustment, part, configuration, or process change, with reason.

Conditions: weather, track state, tire state, session context, or other variables that affect interpretation.

Open items: Must do, Important, Also.

Next action: what the recipient should check, run, compare, or decide next.

That template is not sacred. The standard is sacred: no invisible state, no unowned open work, no conclusion without method, no next session without an objective.

Final standard.

You have handed off well when the next person can continue without borrowing your memory. They know the state of the car, the reason it is in that state, the evidence behind the statement, the conditions that affect the conclusion, the open work, and the next action. If they cannot answer those points, the handoff is not finished.

This is not paperwork for its own sake. The source material repeatedly connects records to learning, decisions, reliability, and avoiding guesswork. In race work, the value of a handoff is that it keeps small details from becoming large failures. Treat every handoff as part of the car.

Worked example: aero test handoff

You are comparing two rear wing configurations. A weak handoff says the second wing was faster. A strong handoff preserves the method: baseline configuration, objective, the fact that only the wing configuration changed, number of laps per configuration, how abnormal laps were handled, lap and sector results if available, driver balance feedback, and whether the baseline was repeated after conditions changed. If weather, track condition, or tire deterioration may have shifted the baseline, the conclusion is provisional until the team returns to baseline or repeats the comparison. The next person should inherit both the result and the limits of the result.

Worked example: brake-corner handoff before a session

A brake job is a high-risk place for assumptions because it can involve assembly work, pre-race checks, fluid level, fasteners, adjustments, driver feel, and data review. A weak handoff says brakes done. A strong handoff names the corner or subsystem, identifies whether the assembly checklist is complete, separates completed work from verified work, names the remaining pre-session checks, and explains why the work was performed. If the concern came from brake-pressure data, the next action should include comparing driver comment to pressure trace shape and consistency after the next run.

Worked example: setup handoff from engineering work

When a setup instruction comes from simulation or engineering analysis, do not hand off only the visible adjustment. The source material emphasizes keeping logs of simulation runs and results so setup decisions remove guesswork. If the requested change has a related compensation, make that visible. A ride-height change that normally requires camber compensation should not arrive as a bare instruction. The handoff should say what run or decision produced the change, what physical adjustment is requested, what related check is required, and what result the next session should evaluate.

Common mistakes

The most common failure is using the word done when the real state is only touched, assembled, or inspected. Another is hiding open work in a casual sentence instead of prioritizing it as Must do, Important, or Also. A third is handing off a conclusion from a weak test, especially when more than one variable changed or when baseline conditions moved. A fourth is treating experience as a substitute for checklist discipline; the corpus warns that even experienced mechanics can tire of checklists and miss a tiny detail. A fifth is failing to record conditions, which makes later lap times, sector times, driver feedback, or setup results harder to interpret.

Drill: three-handoff progression

At your next event, choose one subsystem and run three handoffs. Before the first session, write the subsystem objective, baseline state, and pre-session checks that must be complete. Immediately after the session or work period, write what changed, what was checked, what evidence supports the state, what conditions matter, and what remains open. Before the next session, use the prior handoff to set the next objective and mark any blocking item Must do. The drill succeeds if another team member can read the handoff and state the car state, evidence, open items, and next action without asking you to explain.

Recovery when an assumption is discovered

When an assumption appears, stop and rebuild state from evidence. Identify the exact unknown, compare the record to the car, use other available channels such as checklist, setup sheet, data, and physical inspection, then ask why the assumption appeared. The common causes are verbal-only handoff, skipped checklist, missing owner, or open work that was never prioritized. Correct the handoff before work resumes so the same ambiguity does not transfer to the next person.

Author Review

No quiz questions are attached to this lesson.

Sources

#	Document	Chunk	Pages	Score	Collection
1	Race Car Engineering Mechanics Paul Van Valkenburgh	ec955143-becd-1670-805e-600e7e0cf6da	135	1	uio_books_raw_v1
2	Ultimate Speed Secrets - Ross Bentley	1dbf972c-aef7-3111-aa9c-9fec3776319f	567	1	uio_books_raw_v1
3	Data for Drivers	cabda699642b26311b0a7ef998da2c71	15	1	uio_books_raw_v1
4	Competition Car Aerodynamics 3rd Edition McBeath Simon	4adf8cb4-89c7-1b45-bd4d-9bb03634ecf3	345	1	uio_books_raw_v1
5	Competition Car Aerodynamics 3rd Edition McBeath Simon	c0cd0f54-6d9c-7f08-e9af-37c31b3421d3	345	1	uio_books_raw_v1
6	Analysis Techniques for Racecar Data Acquisition	2c2b79d6-8481-a249-415e-c9cfb1be1d8c	19	1	uio_books_raw_v1
7	Data-for-Drivers-PRINT	b80dc634-a0a7-d6de-d470-353aed47e2a6	17	1	uio_books_raw_v1
8	Going Faster Mastering the Art of Race Driving - Carl Lopez	3b70eb1f-e4e3-c70c-1221-c2c8a8e43d83	51	1	uio_books_raw_v1