Reverse-Engineer Tesla Roadster

Map Tesla Roadster fan and thruster claims into a safe conceptual system.

Introduction

30 Second Summary

A spectacular vehicle claim can be easy to admire. Explaining how its moving parts coordinate safely takes much more than a list of features.

In this project, you will use Excalidraw to reverse-engineer how the Tesla Roadster concept could coordinate surface attachment with airborne control. Your finished engineering canvas will keep public evidence visibly separate from assumptions.

What You'll Build

Your finished canvas will let a reviewer trace the Roadster concept from inverted surface attachment through launch, airborne stabilization, landing, and safe abort.

By the end of this project, you'll have:

A system architecture that lets a reviewer trace sensor feedback into central control. Its labels show which elements come from public evidence, engineering assumptions, or open questions.
A state-transition diagram that lets you follow the conceptual vehicle through ordinary driving, inverted driving, launch, airborne control, landing, and safe abort. Visible guards and interlocks make each transition auditable.
A verification matrix that lets you select any requirement and trace it to a subsystem. You can also see its verification method and required pass evidence.
Secret Mission: Add a degraded-mode response that blocks a hazardous transition when two attitude sensors disagree.

Are there any prerequisites?

You need a Mac with browser access to Excalidraw. Basic diagram experience is helpful, with no coding, paid subscription, or vehicle-engineering experience required.

Before We Start

A clear design intent keeps this conceptual system grounded in public evidence while protecting uncertain details from being presented as Tesla facts. This is your moment to define how the diagram explains safe coordination between surface attachment and airborne control.

Set Up an Evidence-Labeled Canvas

Your design intent already separates Tesla's public evidence from your engineering assumptions. The canvas now needs to make that evidence boundary visible before any hypothetical controller or sensor appears.

You will use Excalidraw to establish the structure for the entire project. Every later mechanism or decision will have a clear place plus an evidence status.

In this step, get ready to:

Lay out the project title across a wide three-region canvas.
Create an evidence legend around a vehicle boundary.
Save an editable copy of the scene on your Mac.

Lay out the canvas regions

A wide layout gives each engineering view enough space to grow. The three regions will keep architecture separate from behavior plus verification.

Enter https://excalidraw.com in your browser's address bar.

You'll see a blank Excalidraw canvas with drawing tools across the top.

Select the text tool from the top toolbar.
Add Reverse-Engineer the Flying Tesla Roadster near the top of the canvas.

You should see the project title anchoring the canvas.

Add Functional architecture below the title on the left.
Add State transitions below the title in the center.

You should now see two labeled work zones beneath the project title.

Add Verification matrix below the title on the right.
Zoom out until all three region headings fit across one wide view.

That first structure is in place. Your later diagrams now have dedicated areas instead of competing for the same space.

Create the evidence legend

The legend acts as an evidence contract for the diagram. Its styles will show whether each future element comes from public information or conceptual reasoning.

Select the rectangle tool from the top toolbar.
Draw three small rectangles in a vertical stack beneath the project title.

You should see three empty legend markers ready for their evidence styles.

Give the top rectangle a solid green outline using the style controls.
Add the label [Publicly verified] beside the top rectangle.

The first legend entry now has a solid green marker for claims supported by public evidence.

Give the middle rectangle a dashed amber outline using the style controls.
Add the label [Engineering assumption] beside the middle rectangle.

The second legend entry now has a dashed amber marker for conceptual design choices.

Give the bottom rectangle a dotted gray outline using the style controls.
Add the label [Open question] beside the bottom rectangle.

You should now see three visually distinct evidence categories in one legend.

Why evidence labels matter

The [Publicly verified] label is reserved for behavior stated on the cited Tesla page.

The [Engineering assumption] label identifies components or rules you add to explore a possible design.

The [Open question] label marks implementation details that the public source does not resolve.

Finish the evidence canvas

A system boundary shows what belongs inside the conceptual vehicle design. The source note gives every future public claim a visible evidence trail.

Draw a large rectangle inside the functional architecture region.
Add Vehicle system boundary along the top edge of the large rectangle.

You should see a clearly labeled area ready to contain the vehicle's future functional components.

Add https://www.tesla.com/roadster as a source note inside the vehicle system boundary.

The public evidence in later steps will now point back to a visible source.

Open Excalidraw's main menu in the top-left corner.
Choose the file-saving option that downloads the editable scene.

Your browser downloads an editable Excalidraw scene to its normal download location.

Check your browser's downloads list for a saved file ending in .excalidraw.

Before you scan the finished canvas, consider whether each future element can be classified without relying on memory.

Scan the top row for the project title plus all three region headings.
Trace the large vehicle system boundary in the functional architecture region.
Compare the three evidence styles in the legend.
Locate the Tesla Roadster source note inside the vehicle system boundary.

You should see a wide canvas titled Reverse-Engineer the Flying Tesla Roadster with regions for functional architecture, state transitions, plus a verification matrix. You should also see the system boundary, all three evidence labels, plus the Tesla Roadster source note.

Strong start. Your canvas can now expose the evidence status of every component you add.

Can't find the saved scene?

Check your browser's downloads list for a file ending in .excalidraw.
Return to Excalidraw's main menu if no file appears.
Choose the file-saving option again.

Help me find my saved Excalidraw scene.

Your evidence boundary is ready. Next, you'll test whether the public mechanisms explain a complete and coordinated handoff.

Expose the Coordination Gap

Your saved Excalidraw canvas already gives every element a visible evidence status. That boundary lets you add Tesla's public capability claims without presenting unknown control logic as fact.

A functional architecture can map what each mechanism does. This step tests whether two separate mechanism paths can explain the handoff from surface attachment to airborne control.

In this step, get ready to:

Map the two public mechanisms as separate evidence blocks.
Convert public capability claims into two traceable requirements.
Trace the mechanism paths to expose the unanswered handoff decision.

Map the two public mechanisms

A public-evidence block records behavior supported by the cited Tesla page. Keeping each mechanism separate makes its contribution easy to trace.

Return to the functional-architecture region of the saved scene.
Draw two rectangular blocks inside the vehicle system boundary.

You should see two empty blocks inside the boundary. Leave enough space between them for two distinct paths.

Position the first block toward the upper-left area of the functional-architecture region.
Position the second block toward the lower-right area of the functional-architecture region.

The offset positions create room for a visible handoff gap between the paths.

Apply the legend's solid green [Publicly verified] style to both blocks.

Both blocks should now match the public-evidence entry in your legend.

Enter Multi-mode fan + ground sealing as the heading in the first block.
Place pull air from beneath the vehicle to generate downforce directly below the first heading.

The first block now shows the mechanism responsible for the surface-attachment path.

Enter Cold-gas thrusters + all-electric actuators as the heading in the second block.
Place provide precise thrust adjustments for flight stabilization directly below the second heading.

The second block now shows the mechanism responsible for the airborne-control path.

Why are these blocks green?

Tesla's Roadster page describes a multi-mode fan with ground sealing as a downforce mechanism. It also describes cold-gas thrusters with all-electric actuators as a way to make precise thrust adjustments.

Green records only those public functions. Coordination logic remains outside the public-evidence blocks.

Save the updated scene using the same local-save workflow from earlier.
Compare both mechanism blocks with the solid green legend entry.

You should see two readable green blocks inside the vehicle boundary. Each block should contain one mechanism heading plus one function.

Do the public blocks look inconsistent?

Copy the existing green legend style if either mechanism block uses amber or gray.
Widen a block if its function text overlaps the border.

Help me fix my public-evidence blocks in Excalidraw.

Write traceable requirements

A traceable requirement gives each capability a stable ID. Using the word shall makes the intended behavior clear enough to verify later.

Create a green requirement note beside the fan block containing R-P1: The concept shall maintain surface attachment while stationary and inverted.
Add public-claim-derived beneath the requirement.

You should see R-P1 linked visually to the surface-attachment mechanism. Its status shows that the requirement comes from a public capability claim.

Create a green requirement note beside the thruster block containing R-P2: The concept shall provide precise thrust adjustments during flight.
Add public-claim-derived beneath the requirement.

You should see R-P2 linked visually to the airborne-stabilization mechanism. Its evidence status should match R-P1.

Create an amber requirement note between the two public requirements containing R-A1: The conceptual design shall prevent a mode transition unless its safety conditions are satisfied.
Add [Engineering assumption] beneath the requirement.

You should now see two green public-claim-derived requirements. The amber requirement identifies the safety rule introduced for this conceptual exercise.

Why is R-A1 an assumption?

The two public requirements describe capabilities supported by Tesla's page. The transition rule is an engineering choice introduced to reason about safe coordination.

The amber status keeps that design choice from being presented as Tesla's published implementation.

Save the updated scene using the local-save workflow from earlier.
Read each requirement from its ID through its evidence-status line.

You should see R-P1 plus R-P2 marked public-claim-derived. You should see R-A1 marked [Engineering assumption].

Trace the handoff and expose the gap

A functional path links a mechanism to the outcome it produces. Two separate paths let you test whether the current architecture explains the transition between those outcomes.

Add Surface attachment as an outcome label to the right of the fan block.
Connect the fan block to Surface attachment with an arrow connector.

You should see a visible path from the suction mechanism to its surface-attachment outcome.

Add Airborne stabilization as an outcome label to the right of the thruster block.
Connect the thruster block to Airborne stabilization with an arrow connector.

You should now see a second visible path from the thrust mechanism to its airborne-stabilization outcome.

Before you trace the two paths, do you expect them to explain who permits the vehicle to leave surface attachment for airborne control?

Trace the upper path with your pointer from Multi-mode fan + ground sealing to Surface attachment.
Trace the lower path with your pointer from Cold-gas thrusters + all-electric actuators to Airborne stabilization.

The surface path explains attachment. The airborne path explains stabilization after launch.

The canvas has no decision point that authorizes the transfer between those paths. This visible shortfall is the intended result of the two-mechanism model.

Place a dotted gray note between the two paths using the existing [Open question] style.
Enter Who authorizes and coordinates the handoff? in the note.

What did the trace prove?

Each mechanism can reach its own outcome. The model cannot explain the transfer of authority between them.

Leaving the gap visible prevents an assumed controller from being mistaken for public fact.

Save the completed scene using the local-save workflow from earlier.
Compare the three requirement statuses with the evidence legend.

The public requirements should match the solid green evidence style. The assumed transition requirement should match the dashed amber style.

Before the final trace, which label do you expect your pointer to reach when the explanation runs out?

Trace the surface scenario from ordinary driving through Multi-mode fan + ground sealing to Surface attachment.
Trace the airborne scenario from launch through Cold-gas thrusters + all-electric actuators to Airborne stabilization.
Point to [Open question] Who authorizes and coordinates the handoff? between the two paths.

You should be able to narrate both mechanism-to-outcome paths. Neither path crosses the dotted gray handoff question.

You have made the coordination gap visible. Your canvas now shows exactly where public evidence ends.

The missing decision is now explicit. Next, you will design an assumed feedback and control architecture that closes this gap without presenting it as Tesla's design.

Design the Coordinated Control Architecture

Your Excalidraw canvas now exposes a gap between surface attachment and airborne stabilization. The two public mechanisms show what may create force.

In this step, you will resolve that gap with an assumed control loop that observes system condition before coordinating both mechanisms. Every new component stays amber so the canvas never presents this conceptual architecture as Tesla's published implementation.

In this step, get ready to:

Add the assumed sensing, control, gas-distribution, and actuation components.
Connect every component with a labeled interface.
Assign four responsibilities to the central controller.

Add the assumed coordination components

A functional architecture needs observation, decision, and execution roles. The dashed amber style identifies each role as an engineering assumption.

What belongs in the loop?

The Central mode controller uses feedback to coordinate both mechanism paths.
The Attitude and motion sensing block represents information about vehicle orientation and movement.
The Underbody pressure and seal sensing block represents information about suction conditions.
The Compressed-gas pressure sensing block represents information about gas readiness.
The Surface-contact sensing block represents information about nearby surface contact.
The Compressed-gas storage and distribution block supplies the conceptual gas path.
The Command valves / actuator drivers block turns controller decisions into actuation.

Place a dashed amber box labeled Central mode controller between the existing green mechanism paths.
Create four dashed amber sensor boxes to the left of Central mode controller using the four sensing labels above.

You should see one amber decision block beside four separate amber sensing blocks.

Create a dashed amber Compressed-gas storage and distribution block near the green Cold-gas thrusters + all-electric actuators block.
Create a dashed amber Command valves / actuator drivers block between the controller and the thruster mechanism.

Good progress. Your canvas now contains seven amber coordination components while both public mechanisms remain green.

Label the system interfaces

Interfaces turn a collection of boxes into a working explanation. Each arrow needs a clear direction plus a label for what crosses it.

What should each interface carry?

Use sensor feedback for information flowing from the four sensor blocks into the controller.
Use fan and seal commands for instructions flowing toward the suction mechanism.
Use valve and thrust commands for instructions flowing through the actuator path toward the thruster mechanism.
Use compressed-gas flow for gas moving from storage and distribution toward the thrusters.
Use electrical-power flow for power moving toward the sensing, control, fan, and actuator equipment.
Use mechanical force for the effects of both green mechanisms on vehicle motion.

Draw one arrow from each of the four amber sensor blocks into Central mode controller.
Label each of the four arrows sensor feedback.

Each sensing path should now have the controller as its visible consumer.

Connect Central mode controller to Multi-mode fan + ground sealing with an arrow labeled fan and seal commands.
Trace that arrow from the controller toward the green suction mechanism.

The suction path should now show who issues its conceptual commands.

Connect Central mode controller to Command valves / actuator drivers with an arrow labeled valve and thrust commands.
Connect Command valves / actuator drivers to Cold-gas thrusters + all-electric actuators with another arrow labeled valve and thrust commands.

The thrust-command path should now pass through the amber driver block before reaching the green mechanism.

Connect Compressed-gas storage and distribution to the thruster mechanism with an arrow labeled compressed-gas flow.
Add an incoming line labeled electrical-power flow inside the system boundary with branches toward the sensing, control, fan, driver, and thruster equipment.

You should now be able to distinguish the gas path from the electrical-power path by reading their labels.

Add the plain output label Vehicle motion above the existing Surface attachment and Airborne stabilization outcomes.
Label both existing mechanism-to-outcome paths mechanical force.

Both green mechanisms should now produce a labeled physical effect under the shared vehicle-motion output.

Assign the controller responsibilities

The controller now has visible inputs plus outputs. Its responsibilities explain how feedback becomes guarded commands without claiming a specific Tesla algorithm.

What must the controller do?

Estimate current state.
Evaluate transition guards.
Issue coordinated commands.
Enter a safe or abort state when required evidence becomes invalid.

Add a dashed amber responsibility panel beside Central mode controller.
Copy the four controller responsibilities above into the panel in the same order.

The controller should now show a complete observe, decide, command, and respond role while remaining visibly hypothetical.

Before you audit the complete loop, do you expect any amber sensor or command path to end without a consumer?

Trace every sensor feedback arrow from its amber sensor into Central mode controller.
Trace fan and seal commands from the controller to the green suction mechanism.
Trace valve and thrust commands from the controller through the driver block to the green thruster mechanism.
Trace compressed-gas flow from storage and distribution to the thruster mechanism.
Trace electrical-power flow toward every powered equipment group.
Trace mechanical force from both green mechanisms toward vehicle motion.
Confirm every hypothetical component and controller responsibility uses the dashed amber assumption style.
Save the updated editable scene to your Mac using Excalidraw's local file export.

Every feedback path should end at Central mode controller. Every command or physical flow should reach a named mechanism or powered consumer.

That closes the coordination gap. Your canvas now explains how an assumed controller could observe conditions before coordinating the two public mechanisms.

Having trouble tracing a path?

Check that each arrowhead points from its source toward its consumer. Move crossing connectors apart when a label could apply to more than one line.

Compare every new component with the dashed amber legend entry. Help me audit the interface directions in my Excalidraw architecture.

Your control architecture now observes conditions before it coordinates suction and thrust. Next, you will turn that architecture into a safety state machine with guarded transitions.

Build the Safety State Machine

Your Excalidraw architecture now shows how the assumed controller receives sensor feedback. It also shows where its commands go.

Architecture blocks cannot prove that mode changes happen in a safe order. A state machine makes the order of operations explicit.

In this step, get ready to:

Arrange the eight conceptual operating states in sequence.
Label each forward transition with its assumed guard conditions.
Route hazardous conditions to Safe / Abort.

Lay out the operating states

Tesla's public Roadster page does not specify this control sequence. The whole state machine therefore stays amber under [Engineering assumption].

Eight states plus several fault paths can crowd this region. A two-row layout keeps the labels readable.

Add an amber [Engineering assumption] label to the top of the state-transition region.
Create an amber row of three state boxes ordered Ordinary Driving, Suction Armed, then Inverted Driving.

You should see the surface-attachment sequence take shape beneath one clear evidence label.

Create a second amber row of four state boxes ordered Launch Ready, Launch, Airborne Attitude Control, then Landing.
Place an amber Safe / Abort box beside the operating states where incoming fault paths remain readable.

Good progress. Your state model now gives every later guard a visible start point plus destination.

Add the forward transition guards

A transition guard is evidence the controller must accept before entering the next state. These labels turn R-A1 into visible logic.

Draw an amber arrow from Ordinary Driving to Suction Armed labeled self-check and authorized operating environment.
Draw an amber arrow from Suction Armed to Inverted Driving labeled stable seal, acceptable underbody pressure, and fan health.

You should now be able to trace a guarded path from ordinary operation into inverted surface attachment.

Draw an amber arrow from Inverted Driving to Launch Ready labeled valid attitude data, available gas pressure, and armed thrust control.
Draw an amber arrow from Launch Ready to Launch labeled coordinated seal release and committed launch command.

The middle of the diagram should now show the handoff from surface attachment to committed launch.

Draw an amber arrow from Launch to Airborne Attitude Control labeled confirmed surface separation.
Draw an amber arrow from Airborne Attitude Control to Landing labeled acceptable attitude, descent path, and landing-zone status.

You should see one continuous sequence from ordinary driving to landing. Every forward move now depends on visible assumed evidence.

Add interlocks and fault paths

A safety interlock blocks a hazardous action when required evidence is invalid. A fault transition sends uncertain operation toward Safe / Abort.

Place an amber interlock note beside the launch transition reading block launch when attitude data or gas readiness is invalid.
Place an amber interlock note beside the seal-release guard reading block suction release before thrust control is ready.

The launch handoff should now show two explicit ways the controller prevents an unsafe transition.

Draw an amber fault arrow from each of the seven operating states toward Safe / Abort using a shared route where lines overlap.
Add a four-line amber note to the shared route using loss of seal, controller uncertainty, actuator fault, plus invalid landing conditions.

Every active state should now have a visible escape path when the controller loses trustworthy evidence.

Add a dotted gray note beside Safe / Abort reading [Open question] Exact recovery behavior depends on altitude, orientation, or remaining surface contact.
Save the updated editable scene to the same local file you used earlier.

The gray recovery note keeps uncertain physical behavior outside the assumed control logic. Your saved scene now preserves that evidence boundary.

Before you trace the finished diagram, do you expect any hazardous forward transition to remain possible after its required evidence becomes invalid?

Trace the forward path from Ordinary Driving through Suction Armed, Inverted Driving, Launch Ready, Launch, Airborne Attitude Control, then Landing.
Point to the assumed guard on every forward arrow.
Follow the visible fault path from every active state to Safe / Abort.
Confirm that every hypothetical state uses amber evidence styling.
Confirm that uncertain recovery behavior uses dotted gray evidence styling.

You should see a guard on every forward transition. Invalid launch evidence or premature suction release should be visibly blocked.

Every active state should reach Safe / Abort. The unresolved recovery behavior should remain marked [Open question].

Strong work. Your architecture now explains the legal operating sequence plus the path away from unsafe conditions.

Next, you will audit the design by tracing its requirements to evidence plus verification methods.

Verify, Review, and Export the Design

Your state machine now makes each legal transition visible. The final gap is proof that every claim can be audited.

In this step, you will build a verification matrix in Excalidraw. You will review the completed design before creating its local portfolio export.

In this step, get ready to:

Build a verification matrix that traces each requirement to evidence.
Audit traceability across the complete canvas.
Produce the final local scene plus a readable portfolio export.

Build the verification matrix

A verification matrix links every shall requirement to its owner plus its planned proof. The method defines what evidence would count as a pass.

How do the four methods differ?

Analysis uses models or reasoning to determine whether the design satisfies a requirement.
Inspection checks whether required information is visibly present in the artifact.
Demonstration shows the required behavior through an observed scenario.
Test measures performance under controlled conditions.

Draw a compact table inside the existing verification matrix region.
Label its columns ID, Requirement, Evidence status, Allocated subsystem, Verification method, Pass evidence, and Unknowns.
Populate the R-P1 row with The concept shall maintain surface attachment while stationary and inverted, [Publicly verified], Multi-mode fan + ground sealing, Demonstration, A future prototype maintains surface attachment while stationary and inverted, and Required pressure and seal limits.
Populate the R-P2 row with The concept shall provide precise thrust adjustments during flight, [Publicly verified], Cold-gas thrusters + all-electric actuators, Test, Measured thrust adjustments stabilize a future prototype in flight, and Thrust magnitude and timing.
Populate the R-A1 row with The conceptual design shall prevent a mode transition unless its safety conditions are satisfied, [Engineering assumption], Central mode controller, Analysis, No mode transition occurs without all safety conditions, and Guard thresholds.
Populate the R-A2 row with The conceptual design shall inhibit launch when attitude data or gas readiness is invalid, [Engineering assumption], Central mode controller, Analysis, Invalid attitude data or gas readiness blocks Launch, and Validity thresholds.
Populate the R-A3 row with The conceptual design shall permit landing entry only when attitude, descent path, and landing-zone status are acceptable, [Engineering assumption], Central mode controller, Analysis, Landing entry occurs only when attitude, descent path, and landing-zone status are acceptable, and Acceptance thresholds.

You should now see five requirement rows with a subsystem allocation. Each row should also show a planned verification method plus explicit pass evidence.

Audit every trace

Treat this portfolio review as Inspection. You are checking whether the visible artifact contains a complete trace.

Trace the Central mode controller fan-and-seal command to Multi-mode fan + ground sealing.
Trace the controller's valve-and-thrust command to Command valves / actuator drivers.
Trace every sensor-feedback arrow to Central mode controller.
Trace every controller command through its actuator path.
Confirm every green public claim points to the Tesla Roadster source note.
Confirm every invented component or guard carries [Engineering assumption].
Confirm unresolved recovery behavior carries [Open question].
Trace each requirement row through its allocated subsystem to the matching diagram element.

You should complete all eight checks without finding an orphaned sensor or command. Every requirement should also reach a labeled diagram element.

Produce the portfolio files

The editable scene preserves the design logic for future changes. The image export gives reviewers a fixed view of the completed artifact.

Deselect every element on the canvas.
Open Excalidraw's top-left menu.
Select Save to update the editable scene.
Choose a local folder in the macOS save dialog if Excalidraw asks for a location.

Your completed .excalidraw scene is now stored locally with the verification matrix.

Reopen Excalidraw's top-left menu.
Select Save as image.
Choose either PNG or SVG as the export format.
Save the export to a local folder on your Mac.

Before you open the export, do you expect every label to remain readable at a normal viewing size?

Open the exported image from the location you selected.

You should see the title plus all three regions at a normal viewing size. The five-row verification matrix should remain legible.

Every requirement row should trace to a subsystem plus a diagram element. No evidence status or interface should be orphaned.

That is your portfolio package complete. Reviewers can now audit the evidence boundary, control architecture, safety logic, and verification plan.

Is the export hard to read?

Return to Excalidraw if the exported text is too small.
Tighten the spacing between regions before exporting again.
Choose SVG if the PNG looks blurry.

Help me diagnose an unreadable Excalidraw export.

Secret mission

Secret Mission: Handle Conflicting Attitude Sensors

Two attitude sensors can disagree at the worst moment. Extend your design so that disagreement blocks launch or landing. Route the conflict into a labeled safe response without claiming Tesla uses this design.

Clean Up Your Resources

Your Excalidraw work stays on this Mac with no ongoing cost. Choose whether to keep it available, pause with saved copies, or remove it.

Resources you used:

Your Excalidraw scene stored in this browser.
Your saved editable Excalidraw scene file.
Your local PNG or SVG exports.

Keep everything running

No action is needed. Choose this if you want to keep refining the architecture or retain every version of the design.

Your Excalidraw browser scene stays in local browser storage on this Mac at no ongoing cost.
Your saved editable scene file preserves the version you can revise later.
Your image exports remain available as readable copies of the completed diagram.

Pause - I'll come back to this later

Save the latest version before closing the browser. Your editable file gives you a reliable way to resume later.

Return to the Excalidraw scene from earlier.
Save the latest editable scene to your existing file.
Re-export the diagram as PNG or SVG if the current image does not include the conflicting-sensor design.
Close the browser after the local files are saved.
Resume later by loading the saved editable scene in Excalidraw.

Delete - I don't want to use this again

Deletion removes the browser copy plus the local project files. Make sure you no longer need the design before continuing.

Before You Delete

Clearing browser storage can affect other Excalidraw work stored in the same browser. Emptying the Trash can also remove unrelated files.

Confirm this browser does not hold any other Excalidraw drawings you need.
Move the saved editable scene file to the Trash in Finder.
Move every local PNG or SVG export from this project to the Trash in Finder.
Review the Trash for unrelated files that you need to keep.
Empty the Trash after your review.
Clear the stored site data for https://excalidraw.com in your browser settings.
Return to https://excalidraw.com after clearing the site data.
Check Finder for the removed project files.

You should see a blank canvas without your former scene. The saved scene file plus its exports should no longer appear in Finder.

Nice Work!

You made it! Your Excalidraw canvas now turns the Roadster concept into a traceable systems-engineering artifact.

A reviewer can follow the path from surface attachment to airborne control. They can also see where public evidence ends and engineering judgment begins.

You've learned how to:

Build an evidence-labeled system boundary that keeps public Roadster claims, engineering assumptions, and open questions visibly separate.
Convert public capability descriptions into traceable requirements. You also built a coordinated control architecture with labeled feedback, command, power, gas-flow, and mechanical-force interfaces.
Create a safety state machine with transition guards, interlocks, and abort paths. You also audited the design through a verification matrix with defined pass evidence.
Secret Mission: Extended the design with redundant attitude-sensor channels. Their disagreement now inhibits hazardous transitions and triggers a degraded or Safe / Abort path without presenting the design as Tesla's implementation.

Ready to quiz yourself?