Write the part requirement before the build plan
Generated from
content/lms/fabrication-and-composites/01-choose-safe-fabrication-targets/05-write-a-buildable-part-requirement.md; edit the source file, not this page.
Source path: content/lms/fabrication-and-composites/01-choose-safe-fabrication-targets/05-write-a-buildable-part-requirement.md
Course: Fabricate composite race-car parts with workshop discipline
Module: Choose fabrication jobs that fit your tools and risk
Estimated duration: 60 minutes
The skill in this lesson is simple to state and harder to practice: before you decide how to make a part, write what the part must do. Not what cloth you want to use. Not how many layers sound impressive. Not whether the finished surface will look like a pro car. The requirement comes first because the requirement is the only thing that can tell you whether the build plan is good.
For an intermediate driver-fabricator, this is the line between building a useful track part and building an attractive problem. A build plan starts with actions: cut this, lay this up, trim here, bolt there, paint it, run it. A part requirement starts with duties: carry this load, clear this control, survive this use, weigh roughly this much, keep the driver able to operate the car, stay inside this safety boundary, and be inspectable after a session. The build plan is a proposed answer. The requirement is the question the part has to answer.
That order matters because race-car design is not a sequence of isolated clever tricks. Costin and Phipps treat chassis design as a matter of forces first and physical members later. They describe design as beginning with forces that are later turned into tubes, brackets, and structure. For your smaller fabrication target, the lesson is the same. A panel, duct, bracket support, seat insert, gauge panel, cover, or mount is not just a shape. It is a place where force, package space, driver use, access, weight, and the rest of the car meet. If you begin with the method, you make the part before you have named the meeting it is supposed to survive.
The requirement is not a long engineering report. It is a buildable statement of purpose, boundaries, interfaces, and checks. It should be short enough to use in the workshop and specific enough to stop you from drifting. If you cannot say what success looks like before you cut material, you are not ready to cut material. If you cannot say what would make you reject the part, you are not ready to call it finished.
Why the requirement comes before material
The common mistake is to treat material choice as the beginning of design. In composites, that is especially tempting because the material itself feels like the achievement. Glass fibre, carbon fibre, and aramid have strong identities in the paddock, and McBeath points out that these materials are now common on competition cars and can be approached with home-workshop methods. That does not mean the choice of material is the requirement. It means the material is one possible way to satisfy a requirement.
Costin and Phipps are blunt about sequence at the chassis level: finish the design before choosing material or beginning work. You should scale that rule down to the part on your bench. A composite part requirement tells you what job the part is being asked to do before you choose glass, carbon, aramid, metal inserts, fasteners, or any production method. This lesson does not replace the sibling lessons on matching material to the part's job or defining the composite before you spec carbon. It feeds them. You cannot match material to the job until you have written the job.
The practical reason is that every part carries hidden compromises. Costin and Phipps describe suspension brackets that ideally feed loads into the chassis in the most advantageous way, then immediately acknowledge that another factor can be more important, such as aerodynamic disturbance or suspension geometry. That is the real world. Sometimes a better load path worsens packaging. Sometimes a cleaner shape makes inspection harder. Sometimes a lighter part becomes fragile at the attachment. Sometimes the beautiful part blocks a switch, gauge, belt, jack point, or fastener. The requirement is where those tradeoffs become explicit before the build plan locks them into the part.
Newey describes the chassis designer's job as finding an elegant package for the engine, turbocharger, radiators, driver, fuel tank, suspension, gearbox, and external aerodynamic shape while keeping the solution structurally sound and lightweight. Your HPDE part is smaller, but the same thinking applies. A part requirement is a package statement. It says what the part must coexist with. It says what it may not block. It says what it may touch, where it may fasten, and what it must leave alone. If you skip that step, you can build a technically neat part that is wrong for the car.
The requirement also keeps safety decisions out of the heat of fabrication. Newey reflects on the poor position designers were once put in when they had to balance performance and safety themselves, and he notes the value of taking some of those decisions away from the designer. In your workshop, the requirement does that on a small scale. You decide up front whether the part is safety-critical, near a safety-critical system, or safely outside that boundary. Once written, that boundary is not renegotiated because the part looks close to done.
What belongs in a buildable part requirement
A useful requirement has eight parts. You can write it on one page. More important, another competent person should be able to read it and understand what kind of part would pass.
First, name the part and its job in one sentence. The sentence should include a verb. A weak requirement says carbon interior panel. A useful requirement says the panel covers the unused opening behind the dash without interfering with switch reach, gauge visibility, or service access. The verb exposes the job. Covers, supports, locates, shields, routes, retains, closes, clears, and protects are better starting words than carbon, lightweight, cool, or race-inspired.
Second, state the part's boundary. Say what the part is not allowed to do. It may not carry suspension load. It may not retain the driver. It may not alter a manufacturer-recommended chassis setting. It may not hide damage-prone structure. It may not make an essential control harder to reach. This boundary is not negative thinking. It is how you keep a small fabrication project from quietly growing into an untested safety system.
Third, write the force or use case. You do not need to produce a finite-element model for a simple HPDE part, and the bonded corpus does not support teaching laminate calculations here. You do need to say whether the part is mainly a cover, a locator, a mount, a duct, a support, or a protective surface. Costin and Phipps' design-first rule is force-first thinking. If a part sees a load, name where it enters and where it leaves. If it should not see a load, write that too and design mounts so the real load goes elsewhere.
Fourth, write the interfaces. An interface is every place the part touches the car, the driver, a fastener, a bracket, a gauge, a hose, a panel edge, a body opening, or a service path. Newey's packaging lesson is that parts do not succeed alone. The requirement should list the part's fixed neighbors before the build plan starts. For a cockpit part, the interfaces may be the steering wheel, gear lever, switch bank, harness path, seat travel, and gauges. For an exterior cover, they may be brackets, tubes, suspension travel, bodywork, and access to fasteners.
Fifth, state weight and stiffness as a range or priority, not as wishful language. Costin and Phipps emphasize that early weight range affects structure, wheels, and tyres at the vehicle level. For a small part, you usually do not need a vehicle weight study, but you do need to decide whether the part is weight-sensitive, stiffness-sensitive, access-sensitive, durability-sensitive, or mainly cosmetic. If everything is priority one, the requirement is not finished. The requirement should force a ranking.
Sixth, state the allowed construction level. McBeath notes that a lot of composite design work remains empirical and based on experience, and he also notes that basic wet lay-up techniques are not beneath serious constructors. That is good news for the home workshop, but it does not remove the need for honesty. A buildable requirement says what tools, space, inspection, and repeatability the builder actually has. If the requirement can only be satisfied by facilities you do not have, the correct outcome is to choose a different part, not to pretend the build plan will overcome the gap.
Seventh, define inspection and verification. Van Valkenburgh warns against building a whole vehicle around a single unproven theoretical premise and points toward research and test verification. Scale that down. Before you build, write how you will check the part. Dry fit. Control reach. Fastener access. Interference sweep. Post-session inspection. Comparison against a standard setting. A requirement without a check is just a preference.
Eighth, define the stop rule. A stop rule says what makes you abandon or redesign the part. Major late interference. A control that is harder to use. A bracket that now carries load in a direction it was not meant to carry. Damage after light use. A need to alter a manufacturer baseline setting. A part that cannot be inspected. Stop rules protect you from the most expensive sentence in the workshop: it is almost done.
The difference between a requirement and a build plan
Here is the clean distinction. The requirement describes the job and the acceptance test. The build plan describes the method. Requirement language says the panel must let the driver read essential gauges at a glance. Build-plan language says trim the panel opening and bond in the gauge surround. Requirement language says the cover must not feed suspension load through the bodywork. Build-plan language says use two mounting tabs and a removable fastener. Requirement language says the duct must clear the radiator package and leave oil-line access. Build-plan language says make the pattern in this sequence.
If you mix those too early, the method starts defending itself. You wanted to try a process, so every requirement becomes a reason to keep that process. You already cut a shape, so every interface becomes an excuse to trim around the mistake. You bought the material, so every concern becomes a material problem instead of a requirement problem. The fix is not to become less creative. The fix is to delay method commitment until the part's duties are clear.
This is why the first version of the requirement should be method-neutral. It can say the part must be removable. It should not say the part will use a particular fastener unless that fastener is part of an existing interface. It can say the part must be stiff enough not to flutter in its installed use. It should not say carbon is required unless a previous lesson or engineering decision has already justified that material. It can say the part must survive normal event inspection and repeated installation. It should not hide behind vague words like strong, light, proper, or race-ready.
Write the requirement in three passes
The first pass is the mission pass. You write the job, boundary, and use case. Do this away from the material. If the part is a cover, say what it covers and why. If it is a support, say what it supports and what it must not support. If it is a duct, say what it routes and what it must clear. If it is a panel, say what the driver must still be able to see, reach, and service. The mission pass prevents the part from becoming a shape without a reason.
The second pass is the interface pass. Stand at the car. Touch every nearby system. Steering, shifter, pedals, belts, seat travel, brackets, tubes, body edges, hoses, wires, gauge lines, fasteners, jack access, and inspection access are all possible interfaces. Do not decide how to solve them yet. List them. Costin and Phipps' warning about completing a design study before beginning work applies directly here. You are trying to discover major changes while they are still pencil changes, not after the part is bonded, trimmed, drilled, or painted.
The third pass is the verification pass. Ask how the part will prove itself. Prost and Rousselot's setup discussion is useful here because it separates standard settings from event-specific dynamic settings and stresses preliminary work before the car turns a wheel, plus regular checks after use and especially after an accident. For your part, the standard setting is the baseline car condition the part must not disturb. The dynamic check is what you observe after sessions, heat, vibration, driver use, and service work. The requirement should say both.
You are done with the requirement when the first build step becomes obvious but not predetermined. If the requirement points to several possible build plans, that is fine. If it points to no buildable plan, it has done its job by stopping a bad project early. If it points to only one method because you secretly wrote the method first, go back and separate the job from the process.
Calibrating a good requirement
A good requirement changes your behavior before it changes the car. You will notice that you ask better questions at the bench. Instead of asking whether you can make the part out of carbon, you ask whether the part is actually carrying load. Instead of asking how to make the surface perfect, you ask whether the driver can still read the gauge at speed. Instead of asking how to hide a bracket, you ask whether the bracket still feeds load into the structure the way it should. These are calibration cues.
The first cue is fewer late surprises. Costin and Phipps warn that impatience to get a car on the road has ruined many good designs because major changes become necessary near the end. At the part level, a good requirement reduces the same pattern. You still discover details during fitting, but you do not discover that the part blocks a critical fastener, traps a cable, forces a bracket load into a weak direction, or makes the driver operate the car worse.
The second cue is cleaner tradeoff language. Newey's holistic view warns against cars that look like different departments fought each other. A small part can have the same disease. The pretty surface fights the bracket. The mount fights service access. The lightness goal fights durability. A good requirement lets you say which tradeoff wins and why. You are not guessing in the moment. You are following the priority you wrote when the part was still cheap to change.
The third cue is inspection confidence. Van Valkenburgh points toward checklists, failure information, manufacturer data, and test verification rather than blind extension of simplified theory. Your part requirement should make inspection boring. You know where to look. You know what changed. You know what would cause a redesign. If you cannot inspect the thing you built, you did not finish the requirement.
The fourth cue is that someone else can challenge the plan. A requirement is useful only if it can be read. If another driver, mechanic, instructor, or fabricator cannot tell what your part is supposed to do, the document is still a private thought. The point is not bureaucracy. The point is making the decision visible enough that a competent person can catch a bad assumption before the car is on track.
Failure modes: what wrong feels like
The first failure mode is the material-led part. It starts with a material identity and backs into a use. In the workshop it feels exciting because progress is immediate. On the car it often feels awkward because the part has to be trimmed, patched, spaced, or defended. The cost is not just the material. The cost is that the build plan becomes emotionally expensive before the requirement exists. The recovery is to stop, write the requirement from scratch, and allow the answer to be a simpler material or a simpler part.
The second failure mode is the pretty interference. The part looks finished, but a control, gauge, switch, seat movement, fastener, or inspection path is worse. Costin and Phipps' cockpit guidance is clear that controls should be easily reached, switches instantly recognizable, and essential instruments readable at a glance. A cockpit composite part that makes those things worse is not a finished part. It is a decoration that has taken function away from the driver. The recovery is to rewrite the requirement around the driver task, then change or remove the part.
The third failure mode is the hidden load path. The part was intended as a cover, trim piece, or locator, but once installed it starts taking load because of how it is mounted. This is especially dangerous near suspension brackets, chassis tubes, seat mounts, belt mounts, or anything already designed to feed load into the car. Costin and Phipps' bracket discussion matters because bracket position is not cosmetic; it affects how loads enter the chassis and how other mechanisms are preserved. The recovery is to identify where the load should go and redesign the fabricated part so it does not become an accidental structure.
The fourth failure mode is the untestable assumption. You assume the part is strong enough, stiff enough, clear enough, or durable enough, but you wrote no check. Van Valkenburgh's warning about simplified theory applies here. Even a simple part can fail because the builder extended a general idea into a new situation without verification. The recovery is to add a test before further fabrication: fit check, motion sweep, reach check, inspection after a session, or comparison against the car's baseline settings.
The fifth failure mode is the frozen mistake. You discover a problem but continue because the part is almost done. Costin and Phipps put the risk plainly at the vehicle level: incomplete design and impatience cause major changes late in construction. At the part level, the same habit makes small errors permanent. The recovery is a stop rule written before cutting. If the part fails the stop rule, you do not negotiate with it. You redesign.
How this connects to the rest of the module
This lesson sits before the material lessons. It does not teach you whether to choose glass, carbon, aramid, or something else. It teaches you how to write the job those materials would have to satisfy. When you move to the lesson on defining the composite before you spec carbon, bring the requirement with you. When you move to the lesson on starting with GFRP before chasing carbon, use the requirement to decide whether the lower-risk learning path still satisfies the job. When you move to the lesson on marking the safety-critical boundary, tighten the boundary statement in the requirement.
The goal is not to slow you down. The goal is to spend your impatience in the right place. You want momentum, but you want momentum after the part has a job, boundary, interfaces, and checks. A requirement-first habit makes the workshop faster because it prevents the slowest kind of work: repairing decisions that should have been made before the first cut.
A compact template you can use
Part name and one-sentence job: write the verb and the useful outcome.
Boundary: state what the part must not carry, block, alter, hide, or make harder.
Use case: state whether the part covers, supports, locates, shields, routes, retains, closes, clears, or protects.
Interfaces: list the systems, surfaces, controls, fasteners, and service paths the part touches or affects.
Priorities: rank weight, stiffness, access, durability, appearance, repeatability, and ease of inspection.
Allowed construction level: state the workshop method and tools that are genuinely available.
Verification: write the dry-fit checks, driver-use checks, baseline checks, and post-session checks.
Stop rule: write the condition that forces redesign instead of continued trimming.
Use this template before you write a build plan. If the template feels annoying, that is usually a sign it is doing useful work. It is exposing assumptions while they are still cheap.
Worked example: suspension bracket area before any composite cover or support
Imagine you want to fabricate a composite cover, local support, or tidy close-out panel around a suspension bracket area on a space-frame car. The material temptation is strong because the part is small and visible. But the requirement must start with the bracket's job, not the cover's look. Costin and Phipps emphasize that suspension brackets should feed their loads into the chassis in advantageous ways, while also acknowledging that packaging, aerodynamics, and suspension geometry can force compromise. That gives you the structure of the requirement.
The part name might be suspension bracket close-out panel. The job is not to strengthen the suspension. The job is to close or protect the area while preserving the existing bracket load path, suspension geometry, and inspection access. The boundary is strict: the part must not become the load path, must not hide cracks or movement at the bracket, must not require relocating the bracket, and must not make suspension adjustment or inspection harder. The interface list includes bracket tabs, chassis tubes, fasteners, bodywork, suspension movement, wheel clearance, and the inspection line of sight.
The build plan is not allowed to begin with a cloth choice. It begins only after the requirement says whether the part is a cover, guard, locator, or genuine structure. If it is a cover, the mounting should avoid feeding suspension load into the composite. If the desired shape would require a worse bracket load path or would disturb suspension geometry, the requirement tells you to stop or redesign the cover. This is the practical meaning of compromise. You do not pretend every objective can win. You name the priority before the part exists.
The verification is also requirement-led. Before the car turns a wheel, you dry-fit the part and check full visible access to the bracket and fasteners. You sweep the nearby moving parts through the relevant range available in the workshop. After use, you inspect the bracket area and the cover mounts. Success is not a glossy surface. Success is that the fabricated part did its limited job without changing the bracket's real job.
Worked example: cockpit switch and instrument panel
A cockpit panel is a good intermediate fabrication target because it can be useful without pretending to be a chassis member. It is also a good test of requirement discipline because the driver interface is easy to ruin. Costin and Phipps say controls deserve careful thought: switches should be easily reached and instantly recognizable, and only essential instruments belong in a racing car where they can be read at a glance. That is your requirement source.
The weak build-first plan says to make a carbon dashboard panel and mount the gauges. The requirement-first version says the panel must locate only the necessary switches and instruments so the driver can operate them from the belted driving position and read essential information at a glance without adding distraction. The boundary says the panel must not interfere with steering, gear selection, belts, seating, emergency exit, or service access. It also says the panel must not add unnecessary instruments just because there is space.
The interface pass happens in the car, not at the bench. Sit in the seat with belts as close to driving position as practical. Reach for the controls. Check whether the wheel blocks the instruments. Check whether the switch labels or shapes can be distinguished quickly. Check whether the panel can be removed without dismantling unrelated systems. None of those checks require a laminate schedule. They require a requirement that treats the driver as part of the system.
The verification pass is direct. A passable cockpit panel lets the driver reach the intended switches, recognize them, read the essential instruments, and service the panel without making the cockpit worse. A failed panel is not saved by carbon, paint, or neat edges. If the driver task is worse, the part failed the requirement.
Worked example: packaged bodywork around radiators or oil coolers
Newey's description of designing the March 85C from scratch is useful because it shows how many systems compete for the same space: engine, turbocharger, radiators for water, engine oil and gearbox oil, driver, fuel tank, suspension, gearbox, external aerodynamic shape, structure, and weight. Your club car project may be much smaller, such as a duct panel, cover, or local bodywork around a radiator or oil cooler, but the requirement problem is the same. A bodywork part is never just the outside surface.
A build-first plan might begin with a pattern shape that looks clean. A requirement-first plan begins by listing the packed systems the part must respect. The job might be to close the body opening around the cooler while preserving airflow path, hose clearance, fastener access, and nearby structure. The boundary says the part must not chafe lines, block service, require moving a cooler without a separate design decision, or create a shape that forces a weaker structural support. The interface list includes cooler mounts, hoses, adjacent bodywork, brackets, service tools, and any nearby moving parts.
The important lesson is holistic thinking at part scale. Newey warns against designs where aero and mechanical requirements appear to have fought each other, or where the car lacks cohesion. A small fabricated panel can create the same conflict. If the body shape forces poor access or poor mounting, the clean surface is not enough. If the mount is sturdy but creates a clumsy external shape, the requirement should expose that tradeoff. The right answer may be a less glamorous shape that fits the whole car better.
Verification is not a race-weekend guess. Dry-fit the part with the neighboring systems installed. Confirm the service path before finishing. Inspect after use. If the part solves one visible problem by creating two hidden ones, the requirement was incomplete or ignored.
Common mistakes
Mistake one is writing a material wish instead of a part requirement. The bad version starts with carbon or another material label. The good version starts with the part's verb and acceptance test. Material choice comes later, after the job and boundaries are clear.
Mistake two is confusing appearance with function. A part can look like it belongs on a serious car while making the car harder to drive, inspect, or service. The good version treats appearance as a lower-level priority unless the requirement has already protected controls, instruments, load paths, access, and verification.
Mistake three is letting a non-structural part become accidental structure. This often happens through mounting choices. A cover, panel, or close-out piece touches a bracket or tube, then quietly starts taking load. The good version writes the load boundary before the mount design and checks that real loads still go into the intended structure.
Mistake four is deleting the baseline. Prost and Rousselot stress the value of manufacturer or engineer baseline settings and regular checks. The bad version modifies around the part until the car fits the fabrication. The good version defines the baseline car condition first and rejects a part that forces an unjustified change.
Mistake five is treating empirical work as guesswork. McBeath notes that much composite design remains empirical and experience-based, even in serious racing contexts. That does not mean anything goes. The good version records what previous experience the requirement relies on and then defines a check that can confirm or reject the result.
Mistake six is continuing after the stop rule has been triggered. The bad version keeps trimming, spacing, drilling, and rationalizing. The good version accepts that a part can fail early and cheaply. If the requirement says a control must be easy to reach and the part makes it harder, the part failed. If the requirement says inspection must remain visible and the part hides the area, the part failed. The cure is redesign, not pride.
Drill: the three-pass requirement before your next event
Choose one fabrication target that is useful but not safety-critical. Good candidates are a removable cockpit panel, inspection cover, duct close-out, gauge mount, or protective trim piece. Do not choose anything that retains the driver, carries suspension load, changes braking, or substitutes for a manufacturer setting. The drill is to write the requirement before you write a build plan.
Pass one is the mission pass. Spend 20 minutes away from the material and write the part name, the one-sentence job, the boundary, and the use case. You are not allowed to name a material in this pass unless the material is already an existing interface. Success means the job sentence contains a verb and the boundary clearly says what the part must not do.
Pass two is the interface pass. Spend 30 minutes at the car. List every system, control, fastener, surface, motion path, service path, and inspection path the part could affect. Sit in the car if the part is in the cockpit. Move or inspect the nearby hardware if the part is near brackets or bodywork. Success means the interface list is specific enough that a second person can point to the affected items on the car.
Pass three is the verification pass. Spend 20 minutes writing the checks. Include at least one dry-fit check, one driver-use or service-use check, one baseline check, and one post-session inspection. Then write one stop rule. Success means you can state exactly what would make you redesign the part before finishing it.
Only after those three passes do you write the build plan. The build plan should answer the requirement line by line. If you cannot connect a build step to a requirement, the step is suspect. If the requirement reveals that the part is not buildable with your tools or experience, the drill still succeeded. It stopped you before the expensive part.
When the principle gets compressed
Sometimes you are at an event and need a quick repair, cover, or temporary solution. The requirement-first rule does not disappear. It compresses. You still name the job, boundary, interface, and check, but you do it in minutes and with a narrower ambition. The temporary requirement might say the part only protects an edge for transport back to the paddock, or only holds a non-critical cover until the end of the day, or only restores access after removing a damaged piece. It should also say what it is not allowed to do and when it must come off.
This matters because urgent fabrication encourages false confidence. Van Valkenburgh's warning about unverified theory is even more relevant under pressure. Prost and Rousselot's distinction between workshop baseline and event adjustment also helps: do not let an event fix silently become a new standard setting. If the part was built as a temporary answer, the requirement should make that status visible. After the event, inspect it, compare it to the baseline, and either redesign it properly or remove it.
Author Review
No quiz questions are attached to this lesson.
Sources
| # | Document | Chunk | Pages | Score | Collection |
|---|---|---|---|---|---|
| 1 | Racing and Sports Car Chassis Design Costin Micael Phipps David | b76a342e-5c16-6bd3-cb79-1b1626ca1ceb | 32 | 1 | uio_books_raw_v1 |
| 2 | Racing and Sports Car Chassis Design Costin Micael Phipps David | 8c4cec2b-f19c-73e2-3d06-47e084bbfa27 | 110 | 1 | uio_books_raw_v1 |
| 3 | Racing and Sports Car Chassis Design Costin Micael Phipps David | 8ec9348a-eb86-133e-1217-1585e7b5c8ae | 128 | 1 | uio_books_raw_v1 |
| 4 | How to Build a Car Adrian Newey | 68178e50-ba04-c27e-94b5-22dac677cb75 | 86 | 1 | uio_books_raw_v1 |
| 5 | How to Build a Car Adrian Newey | c77f68d0-4b2a-d669-fece-37f9e2cffa4f | 86 | 1 | uio_books_raw_v1 |
| 6 | How to Build a Car Adrian Newey | 1e01cfd9-51a6-b9b3-eb25-584b091d4366 | 104 | 1 | uio_books_raw_v1 |
| 7 | Race Car Engineering Mechanics Paul Van Valkenburgh | ea519039-ee4f-d64c-b79a-88981a8aa7c7 | 7 | 1 | uio_books_raw_v1 |
| 8 | Competition driving Prost Alain 1955- Rousselot etc. | 61c885d6-af89-6817-2f94-44a44a07ce10 | 92 | 1 | uio_books_raw_v1 |
| 9 | Competition Car Composites Simon McBeath | 629cf934-5b41-0aa0-eb70-cec1d94b0bbb | 171 | 1 | uio_books_raw_v1 |
| 10 | Competition Car Composites Simon McBeath | 2fd26ac3-6beb-d458-378d-1ca12307931e | 1 | 1 | uio_books_raw_v1 |
| 11 | Racing and Sports Car Chassis Design Costin Micael Phipps David | 1d4ff083-706a-e9f3-607f-60c68e359f89 | 4 | 1 | uio_books_raw_v1 |