Plan an Autonomous Skid-Steer Program

Build an evidence-gated research workspace for an autonomous skid-steer.

Introduction

30 Second Summary

A confident plan for a moving machine can hide dangerous gaps when the exact controls, manuals, and site conditions remain unknown. Those gaps matter when people may be nearby.

In this project, you will build a reusable research control center inside a ChatGPT Project. It will govern the loader's automation, remote operation, software, connections, firmware, deployment, and validation without inventing unsupported machine details.

What You'll Build

Picture asking for an end-to-end loader plan while your workspace blocks unsupported machine details before they reach a physical test.

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

A visible evidence gap register that separates verified findings from assumptions, conflicts, and missing information. Its evidence gates prevent unsupported parts, pinouts, protocols, APIs, or commands from becoming accepted decisions.
An end-to-end system definition built around an Operational Design Domain. You can trace command authority into bounded machine motion. You can also trace sensor feedback into fault detection and safe response.
A reviewed research roadmap for Deep research that makes every stage independently testable. It progresses from documents and simulation through bench testing, supervised operation, remote control, autonomy, tilling, and field acceptance.
Secret Mission: Red-team the preferred linear-actuator approach. Force the workflow to classify it as Supported, Rejected, or Blocked by missing evidence using model-specific evidence.

Are there any prerequisites?

You need a Windows PC, an active ChatGPT Plus subscription, and the original loader requirement.

Machine-specific implementation remains blocked until the exact loader details, tiller information, manuals, jurisdiction, and site communication evidence are available.

Before We Start

Before any hands-on work, this step locks in why the autonomous-loader program needs evidence-based staged development. Your commitment keeps physical machine testing behind simulation, bench, stationary, and supervised validation gates.

Set Up the Research Workspace

Your staged development commitment sets a safe direction for the loader program. Without a controlled workspace, machine evidence can blur into unrelated software decisions.

A dedicated ChatGPT Project gives this program one controlled context. In this step, you will create that workspace before testing its end-to-end scope.

In this step, get ready to:

Create a dedicated research project.
Limit memory to the new project.
Verify the complete requirement inside a labeled project chat.

Create the research project

A dedicated project separates the loader program from unrelated conversations. Its name gives every future report a clear home.

In your browser, sign in to your ChatGPT Plus account.
In the ChatGPT sidebar, select New project.
Enter Autonomous Skid-Steer Program as the project name.
Confirm the name to create the project.

Your program now has a dedicated research home. You should see Autonomous Skid-Steer Program in the ChatGPT sidebar.

Can't see the new project?

Confirm that you are signed in to the account with your active ChatGPT Plus subscription.
Use New project in the ChatGPT sidebar.

Help me create the project from my ChatGPT Plus account.

Enable Project-only memory

Project-only memory supports the controlled boundary this program needs. The setting is easy to miss because it sits inside the project's more-options menu.

Open the project's more-options menu.
Select Project settings.
Under Memory, select Project-only memory.
Select Save.

You should see Project-only memory remain selected after saving. This confirms that the controlled project context is enabled.

Anchor the complete requirement

The first project chat becomes the written scope anchor. It needs the original loader requirement before the wider software lifecycle is added.

Return to the earlier conversation that contains your original loader requirement.
Copy the original loader requirement.
Switch back to the Autonomous Skid-Steer Program project.
Start a new chat inside the project.
Type Original Requirement as the first line.
Paste the copied loader requirement below the label.

The copied requirement captures the machine goal. Complete program coverage also defines the surrounding engineering work.

What complete program coverage includes

Machine automation.
Command authority.
Remote-control software.
Communications.
Firmware creation.
Firmware installation.
Deployment.
Testing.
Field validation.

Add a second paragraph requiring every program layer listed above.
Send the message.
Open the new chat's more-options menu.
Rename the chat Original Requirement.

You should see Original Requirement in the project's chat list. The chat now holds the loader goal plus the complete program scope.

Prepare the scope check by copying this prompt:

State the current project scope in one sentence.

What does this prompt check?

It asks the project to summarize the scope captured in the chat.
Its answer reveals whether the full loader program remains in context.

Before you send it, form a prediction about whether the project will describe a full program or only a parts list.

Paste the prompt into the Original Requirement chat.
Send the prompt.

A successful reply describes end-to-end autonomous-loader planning. It covers the program beyond an unsupported parts list or unrelated topic.

Scope reply too narrow?

Confirm that Original Requirement contains the original loader requirement.
Add the missing remote-control software requirement.
Add the missing complete program coverage requirement.
Send the scope check again.

Help me diagnose why the project scope reply is incomplete.

That foundation is now locked in. Next, you will test what happens when one request demands every final engineering answer at once.

Expose the All-in-One Prompt Failure

Your dedicated research workspace now holds the full loader requirement. The next risk is accepting a polished plan before the supporting evidence exists.

An all-in-one request pressures ChatGPT to settle every program layer at once. You will test that pressure before judging each exact claim against the available evidence.

In this step, get ready to:

Generate a baseline answer that attempts to cover the entire program.
Audit every exact claim against its supporting source.
Save the completed audit as a reusable project source.

Pressure-test the available evidence

The baseline request asks for final hardware details alongside production software details. It gives you one response to test before stronger evidence rules exist.

Return to the Original Requirement chat inside your project.
Select the prompt window beneath the existing conversation.

Before you submit the request, which program area do you think the current evidence can support most confidently?

Enter the baseline request by pasting this prompt:

Using the Original Requirement, give me the final automation architecture, complete part-number BOM, exact wiring and connector pinouts, remote communication design, production operator application, all data contracts, and exact firmware build and installation instructions now.

What does this prompt test?

This prompt asks one response to settle hardware architecture, component selection, physical connections, communications, software, data contracts, and firmware procedures. Each exact detail would need authoritative evidence before an engineering team could accept it.

The response becomes a baseline for checking how far confident wording travels beyond the project evidence.

Press Enter to submit the request.
Read the baseline response from top to bottom.

You should see unsupported exact claims or a refusal that names missing inputs. Both outcomes show that the current evidence cannot support a verified final design.

You have now captured the intended shortfall. The all-in-one request cannot resolve machine-specific decisions through confident wording alone.

Audit every exact claim

An evidence audit separates what the response claims from what its sources can prove. The missing-evidence column turns each unsupported detail into a research requirement.

Select the prompt window beneath the baseline response.
Request the evidence audit by pasting this prompt:

Audit your previous response in a table with the columns Claim, Source, Machine-specific?, Software-specific?, Verified?, and Missing evidence.
Flag every exact value, part, protocol, API, port, or command that lacks an authoritative source.
Identify unresolved inputs for the machine, control geometry, interlocks, schematics, communication environment, selected components, remote-control software requirements, safety concept, and jurisdiction.
Include missing manuals, hydraulic and electrical schematics, data contracts, and firmware procedures in the unresolved evidence list.
Do not accept an exact part, connector pinout, voltage, actuator size, protocol, API, or command as verified without an authoritative source.

How does the audit work?

Each row connects a claim to its source. The classification columns show whether that claim depends on the exact machine or the eventual software design.

A claim stays unverified when its authoritative source is absent. The final column records the evidence needed to move it forward.

Press Enter to generate the audit.
Inspect each row for a named source.
Confirm that unsupported exact details remain unverified.

The table should flag unsupported hardware, wiring, connectors, communications, software, data contracts, and firmware claims. It should record the missing authoritative evidence for each claim.

That is the useful failure captured. The answer's confidence no longer hides the gaps that block safe implementation.

Audit missing columns or claims?

Check that you submitted the audit prompt beneath the baseline response.
Ask ChatGPT to preserve all six requested column names.
Compare the table against the exact hardware and software details requested in the baseline.

Ask for help with an incomplete audit.

Save and verify the gap audit

Saving the audit as a project source makes its unresolved evidence available to later project chats. The source becomes a durable checkpoint for future architecture decisions.

Open the message menu on the audit response.
Select Add to project sources.
Use Baseline Gap Audit as the source title.

You should see Baseline Gap Audit in the project sources. Your workspace now retains the audit beyond this conversation.

Before you run the final scope check, which missing evidence category do you expect the project to name first?

Check the saved audit's coverage by pasting this prompt into the project chat:

Which requested hardware and software outputs cannot be verified yet, and what exact evidence is missing?

What does this check prove?

This prompt tests whether the audit can distinguish requested outputs from verified outputs. A complete reply should connect each blocked output to the evidence it still needs.

Press Enter to run the scope check.

The reply should identify unresolved machine identity, control geometry, interlocks, manuals, schematics, communications, selected components, and jurisdiction. It should also identify unresolved safety concepts, software requirements, ports, protocols, APIs, data contracts, and firmware procedures.

No exact part, connector pinout, voltage, actuator size, protocol, API, or command should appear as verified without an authoritative source.

Your baseline now exposes where polished output outruns the evidence. Next, you will turn that lesson into permanent project rules.

Install Evidence Gates

Your Baseline Gap Audit has made the evidence gaps visible. A polished answer can still outrun the evidence available.

Now your ChatGPT project needs evidence gates that govern physical automation. The same rules must govern remote-control software.

In this step, get ready to:

Add permanent project instructions that classify every load-bearing claim.
Create a source hierarchy for resolving engineering claims.
Rerun the baseline request to produce a cited evidence-gap register.

Add permanent evidence gates

Project instructions govern every conversation inside this project. The rules need to block unsupported implementation details before those details influence hardware or software decisions.

Select the project's more-options menu.
Select Project settings.
Locate the Project instructions field.
Add the evidence-gate rules by pasting this text into the field:

Act as the research coordinator for a safety-critical autonomous earth-moving machine and its remote operator software. Separate every load-bearing finding into Verified, Assumed, Conflicting, or Missing. For exact specifications, ports, pins, voltages, commands, versions, prices, safety behavior, protocols, APIs, and compatibility, require a current manufacturer or recognized-authority source and cite its URL. Do not provide a final machine-specific BOM, actuator sizing, wiring pinout, network design, software stack, firmware command, or interlock modification until the exact machine, site, selected component, and official software documentation support it. Never recommend bypassing an original safety interlock. Keep independent safety functions separate from the ordinary remote-control and autonomy paths. Compare at least two viable approaches, record trade-offs, define tests, and end every report with a decision gate and unresolved evidence list.

How Do These Gates Work?

The label Verified identifies a finding backed by the required authority.
The label Assumed keeps an unproven working assumption visible.
The label Conflicting exposes disagreement between sources.
The label Missing blocks a decision until the required evidence exists.
Independent safety functions remain separate from ordinary remote-control paths.
Every report ends with tests.
Every report also ends with a decision gate.
Unresolved evidence stays visible at the end of every report.

Select Save.
Return to Project settings from the project's more-options menu.
Confirm the full evidence-gate instructions remain in the field.

The saved instructions now apply across this project. Unsupported precision has a permanent checkpoint before it can become a design decision.

Instructions Missing After Saving?

Paste the full instruction block into the Project instructions field again.
Select Save.
Confirm you are editing the Autonomous Skid-Steer Program project.

Ask for help with project instructions that do not remain saved.

Set the source hierarchy

Evidence classifications show confidence. A priority order decides which source can support an engineering claim when sources differ.

Return to the project chat.
Create the source hierarchy by sending this text:

exact machine manuals and manufacturer documentation first; applicable regulator and standards sources second; official software and component documentation third; peer-reviewed research fourth; community material only as a lead that must be reverified.

Why Does Source Order Matter?

The hierarchy gives exact machine documentation the highest priority. Applicable authorities provide the next layer for safety requirements.

Official software documentation supports software-specific claims. Community material can reveal useful leads that still need stronger verification.

Confirm the reply preserves all five levels in the same priority order.

You should see community material placed last as a lead requiring re-verification. This keeps an unsourced forum suggestion from becoming a machine command.

Source Levels Out of Order?

Compare the reply with the five levels in the source-hierarchy message.
Correct any level that ChatGPT reordered.
Confirm community material remains a lead requiring re-verification.

Ask for help with restoring the source hierarchy.

Pressure-test the evidence gates

The original all-in-one request now serves as a regression test. Its broad demand reveals whether the permanent rules can resist pressure to invent exact details.

Before you send the request, do you think the answer will repeat confident implementation details or stop at the evidence gaps?

Pressure-test the evidence gates by sending the baseline request again:

Using the Original Requirement, give me the final automation architecture, complete part-number BOM, exact wiring and connector pinouts, remote communication design, production operator application, all data contracts, and exact firmware build and installation instructions now.

What Should Change?

The request still asks for unsupported precision. The project instructions should now stop those details from being presented as verified facts.

The response should classify unresolved hardware and software inputs. It should cite authoritative URLs for any exact claim it retains.

The response should compare viable alternatives. It should finish with tests plus a decision gate plus an unresolved evidence list.

Open the rerun response's message menu.
Select Add to project sources.
Enter Evidence Gate Register as the source title.
Confirm the project sources area lists Evidence Gate Register.

You should now see a cited gap register instead of invented parts or commands. That is the key control working: unsupported precision has become visible research debt.

Still Seeing Unsupported Exact Details?

Return to Project settings.
Confirm the complete evidence-gate instructions remain saved.
Confirm the source hierarchy remains in the project chat.
Rerun the baseline request inside the Autonomous Skid-Steer Program project.

Ask for help with finding why the evidence gates are being ignored.

Your research workspace now refuses to turn missing evidence into machine instructions. Next up, you will define the automation chain plus the remote-control interfaces plus the firmware deliverables.

Define the System Deliverables

Your evidence gates now turn unsupported certainty into a cited gap register. That protects the program from invented implementation details.

The next problem is coverage. A safe system definition must trace authority, motion, feedback, software, connections, firmware, and fault response.

This step turns that coverage into required schemas. Each schema leaves unsupported numerical limits or machine-specific behavior marked as Missing.

In this step, get ready to:

Create an evidence-gated operating-domain and automation-chain specification.
Create a stack-neutral remote-operator and data-contract specification.
Create an interface-control and firmware-lifecycle specification.

Define the operating domain and automation chain

An Operational Design Domain defines the conditions where a machine is allowed to operate. Here, the domain covers private-property travel of up to 2 km between a home station and a tilling plot.

The domain also recognizes that people may be nearby. The automation chain then traces how each authorized input becomes bounded machine motion.

Return to the project chat from earlier.
Paste this specification prompt into the message box:

Build an Operational Design Domain for a skid-steer that travels on private property for up to 2 km between a home station and a tilling plot, with people potentially nearby. Then define the complete automation chain from local operator, remote operator, or autonomous mission input through command authority, task planning, route or coverage planning, bounded motion commands, machine-interface control, actuator movement, sensor feedback, fault monitoring, and safe reaction. Include manual, local teleoperation, remote teleoperation, assisted, autonomous, degraded, recovery, and maintenance modes. Define allowed transitions, who can request each transition, required preconditions, acknowledgements, timeouts, and logging. Mark every numerical limit and machine-specific behavior Missing until supported.

What does this prompt define?

The operating domain establishes the mission context without inventing machine capabilities.
The automation chain traces each input through authority checks before it can reach the machine interface.
The mode-transition fields expose who can request a change under each operating condition.
The Missing classification prevents unsupported limits from becoming accepted requirements.

Submit the message.

You should see an evidence-gated draft from ChatGPT covering the operating domain, automation chain, modes, transitions, and unresolved machine limits.

Open the response message menu.
Select Add to project sources.
Name the saved source Operational Design Domain and Automation Specification.
Confirm the source title to finish saving it.

Good work. Your program now has an operating envelope plus a control chain that exposes every unsupported limit.

Seeing unsupported exact limits?

Confirm that you submitted the prompt inside the evidence-gated project chat.
Check whether every unsupported numerical limit is classified as Missing.
Regenerate the response if it presents machine-specific behavior without an authoritative source.

Help me correct an automation specification that contains unsupported machine-specific details.

Specify remote operation and data contracts

A remote operator system needs explicit control ownership. It also needs observable behavior when commands, telemetry, or communications fail.

A data contract gives each command or telemetry stream a testable definition. The design must also keep network stop requests separate from an independent emergency-stop function.

Paste this remote-system prompt into the same project chat:

Specify a custom remote operator system without choosing a final stack prematurely. Compare a browser application, a native desktop application, and any manufacturer-supported interface. Define frontend views, map and mission controls, drive and implement controls, live status, video, alarms, control ownership, user roles, authentication, authorization, command acknowledgement, heartbeat, telemetry, event logs, replay, software updates, and recovery. Define the backend or gateway and robot-side agent responsibilities. Require data contracts for every command and telemetry stream with schema, units, ranges, sequence or timestamp, source, destination, transport, delivery behavior, rate, latency budget, timeout, validation, authorization, acknowledgement, logging, fault response, and official source. A network stop request must not be presented as a substitute for an independent emergency-stop function.

What does this prompt define?

The interface comparison keeps browser, native desktop, and manufacturer-supported options open.
The responsibility split separates the operator console from the gateway and robot-side agent.
The contract fields make every command or telemetry stream testable.
The safety constraint prevents an ordinary network message from being treated as an independent emergency-stop function.

Submit the message.

You should see a stack-neutral comparison followed by responsibilities for the frontend, gateway, and robot-side agent. The response should also define complete fields for commands and telemetry.

The draft should explicitly separate network stop requests from the independent emergency-stop function.

Open the new response message menu.
Select Add to project sources.
Name the saved source Remote Operator System and Data-Contract Specification.
Confirm the source title to finish saving it.

That closes a major gap. Remote commands now have defined owners, contracts, acknowledgements, and failure behavior.

Missing a remote-system layer?

Check that the response compares all three interface approaches from the prompt.
Confirm that it separates frontend, gateway, and robot-side-agent responsibilities.
Regenerate the response if any command or telemetry stream lacks an official-source field.

Help me find missing responsibilities or contract fields in my remote operator specification.

Map connections and firmware lifecycles

An Interface Control Document records every boundary between components. This prevents power, ordinary data, safety signals, network links, and programming paths from collapsing into one vague diagram.

A firmware lifecycle defines how each future image is created. It also defines installation, verification, recovery, rollback, and maintenance.

Paste this connection and firmware prompt into the same project chat:

For every future component, require a block diagram separating power, ordinary control data, independent safety signals, remote communications, and programming links. Require one connection row per link with source, destination, function, connector, exact port and pins, supply, grounding or shielding, electrical interface, protocol, message or signal, direction, rate, latency, timeout, fault detection, safe reaction, isolation, test, and official source. For every programmable component, require hardware revision, software responsibility, repository, pinned toolchain, dependencies, configuration, build procedure, artifact and checksum, programming transport, exact programming connector and pins, bootloader or recovery mode, installation, verification, rollback, logs, release record, and acceptance tests. Separate operator application, backend or gateway, robot agent, ROS 2 application software, machine-interface firmware, independent safety-controller configuration, and communications-device firmware.

What does this prompt define?

The block diagram separates ordinary control paths from independent safety paths.
The connection rows force each physical or logical link to carry evidence and a test.
The lifecycle fields trace each artifact from source code through release and recovery.
The software split prevents one firmware procedure from being applied to unrelated programmable layers.

Submit the message.

You should see a connection schema with one evidence-backed row per link. You should also see separate lifecycle records for each programmable layer.

Open the response message menu.
Select Add to project sources.
Name the saved source Connection and Firmware Lifecycle Specification.
Confirm the source title to finish saving it.

You now have the three specification families needed to control future research. The final check tests whether the project can present them as one coherent system.

Before you run the final check, which schema groups do you expect the project to surface?

Ask the project to assemble its deliverable schemas by entering this check:

Show the required end-to-end deliverable schemas.

What does this check prove?

This check tests whether the project can retrieve the deliverables as one end-to-end system. A complete answer keeps sources and unresolved fields visible across every schema.

Submit the message.

You should see automation, control-authority, remote-software, connection, data-contract, deployment, and firmware tables. Each table should include source and unresolved fields.

The response should keep numerical limits and machine-specific behavior marked as Missing until authoritative evidence resolves them.

Are any schemas missing?

Confirm that all three specification responses were created inside the same project chat.
Check that the saved project sources use the specified titles.
Ask the project to identify the absent schema family if the final response omits one.

Help me diagnose why my project is omitting required end-to-end deliverable schemas.

Your system deliverables now cover the complete program without hiding the evidence gaps. Next, you will turn these schemas into a phased Deep research plan.

Build the Research Roadmap

Your workspace now defines the automation, remote-operation, connection, data-contract, and firmware deliverables. The remaining challenge is turning that wide scope into a sequence that can be tested without granting machine access too early.

You will use ChatGPT Deep research to prepare a source-grounded program roadmap. Each layer must prove itself before it can influence machine motion.

In this step, get ready to:

Create a master brief covering every hardware and software research workstream.
Convert the full program into independently testable phases with evidence gates.
Review the proposed Deep research plan before research begins.

Frame the program as research workstreams

A master research brief separates the program into questions that can be investigated independently. This prevents one weak assumption from spreading through the machine design or operator software.

Return to the project chat from earlier.
Create the master research brief by pasting this prompt into the ChatGPT prompt window:

Create a master research brief for the complete autonomous skid-steer program.
Use the Original Requirement, Evidence Gate Register, Source Hierarchy, Operational Design Domain and Automation Specification, Remote Operator System and Data-Contract Specification, and Connection and Firmware Lifecycle Specification.

Create separate workstreams for:
1. Machine identity and controls, applicable safety framework, and automation alternatives.
2. Machine-interface hardware, localization, mapping, 2 km route navigation, field-coverage planning, and obstacle and personnel detection.
3. Remote communications, cybersecurity, operator-console software, backend or gateway, robot-side agent, and data contracts.
4. Power design, component connections, firmware lifecycle, BOM and cost, verification, deployment, maintenance, and incident recovery.

End every workstream with these headings:
Decision
Evidence
Alternatives
Constraints
Interfaces
Tests
Open questions

Follow the project Source Hierarchy. Mark unsupported exact values and machine-specific behavior as Missing. Do not treat this brief as authorization for physical construction, machine modification, firmware installation, or machine testing.

How the brief controls scope

Separate workstreams keep machine evidence distinct from software design decisions.
The seven required headings expose the evidence behind each proposed decision.
The final restriction preserves the existing gate against unsupported physical work.

Press Enter to submit the prompt.
Review the response for a separate section covering each requested workstream.

You should see coverage from machine identity through incident recovery. Exact machine details should remain classified as Missing when the project lacks authoritative evidence.

Is the brief collapsing topics together?

Check that you submitted the prompt inside the evidence-gated project chat. A chat outside the project cannot use the specifications saved in this workspace.

If a workstream is missing, ask ChatGPT to regenerate the brief with one distinct section for every numbered group.

Help me identify missing workstreams in my autonomous-loader master research brief.

Convert workstreams into gated phases

The brief defines what must be researched. A phased roadmap defines when each result becomes safe enough to support the next experiment.

Turn the brief into an independently testable program by pasting this follow-up prompt:

Using the master research brief you just created, produce one combined artifact titled Master Research Brief and Phased Roadmap.

Build the implementation sequence in this order:
1. Machine evidence and risk analysis.
2. Simulation and data-contract prototype.
3. Machine-interface bench rig.
4. Local operator application.
5. Local teleoperation.
6. Remote communications and control.
7. Supervised autonomy.
8. Route teaching and replay.
9. Autonomous field travel.
10. Tilling coverage.
11. Degraded-mode testing.
12. Field acceptance.
13. Operations and maintenance.

Make stationary-machine checks and low-speed supervised operation explicit gates before higher-risk motion.
For every workstream and phase, include Decision, Evidence, Alternatives, Constraints, Interfaces, Tests, Open questions, Inputs, Deliverables, Hazards, Rollback, Stop conditions, and Continuation evidence.
Keep exact limits and machine-specific behavior marked Missing until supported by authoritative evidence.
State that this roadmap does not authorize physical construction or machine testing based on the report alone.

Why the phases need gates

Simulation tests command behavior before any hardware can move.
The bench rig isolates the machine-interface layer from the loader.
Stationary checks establish bounded behavior before supervised low-speed operation.
Stop conditions prevent an incomplete phase from quietly feeding the next one.

Press Enter to generate the combined brief and roadmap.
Scan the response from machine evidence through operations and maintenance.

You should see thirteen ordered phases with explicit gates for stationary checks and low-speed supervised work. Every phase should name the evidence required before the program continues.

Open the response message menu.
Select Add to project sources.

ChatGPT should open the source-saving controls for that response.

Enter Master Research Brief and Phased Roadmap as the source title.
Confirm the addition to the project sources.

Good progress. The project now has one controlled roadmap that connects every research workstream to a testable program phase.

Is a phase missing its gate?

Look for phases that name a deliverable without naming hazards or continuation evidence. Regenerate that phase using every required field before saving the artifact again.

Help me repair incomplete gates in my phased autonomous-loader roadmap.

Review the Deep research plan

Deep research creates a proposed plan that you can modify before research begins. This review point lets you catch missing workstreams before the tool spends time collecting sources.

In the ChatGPT prompt window, select Deep research from the tools menu.

You should see Deep research selected as the active research tool.

Select Sites.
Select Manage sites.

You should see the controls for managing which sites receive priority during research.

Add the official sites represented in the existing project sources.
Prioritize manufacturer documentation, official software documentation, regulator sites, standards bodies, and official component documentation while allowing full-web research.

The source controls should now reflect the project hierarchy. Manufacturer-specific conclusions must remain conditional until the exact loader identity is verified.

Load the saved roadmap into Deep research by pasting this request:

Use the project source titled Master Research Brief and Phased Roadmap to propose a Deep research plan for the autonomous skid-steer program.

Preserve every research workstream and every gated phase.
Prioritize exact machine manuals and manufacturer documentation first.
Use applicable regulator and standards sources second.
Use official software and component documentation third.
Use peer-reviewed research fourth.
Treat community material only as a lead that requires re-verification.

End every workstream with Decision, Evidence, Alternatives, Constraints, Interfaces, Tests, and Open questions.
Require hazards, rollback, stop conditions, and continuation evidence for every phase.
Keep all unsupported numerical limits and machine-specific behavior marked Missing.
Do not authorize physical construction, machine modification, firmware installation, or machine testing from the report alone.
Return the proposed research plan for review before beginning research.

What this review protects

The proposed plan connects each research question to the source hierarchy. It also keeps the report separate from permission to build or test the physical machine.

Before you submit this request, which workstream do you expect will need the most editing in the proposed plan?

Press Enter to request the proposed research plan.

You should see a proposed plan that can be reviewed before research begins. Keep the plan at this review stage while you check its scope and gates.

Compare the proposed workstreams with the saved master brief.
Confirm the opening gates cover machine documents and risk analysis.
Confirm simulation appears before the bench rig.
Confirm stationary checks appear before low-speed supervised operation.
Confirm remote operation appears before autonomous travel and tilling.
Confirm the closing gates cover degraded modes and field acceptance.
Confirm every workstream ends with the seven required research headings.
Edit the proposed plan to restore any missing field or phase.

The reviewed plan should now span evidence gathering, simulation, bench testing, supervised machine work, remote operation, autonomous travel, tilling, acceptance, and ongoing maintenance. It should preserve explicit hazards, rollback paths, stop conditions, and continuation evidence.

Does the proposed plan skip a phase?

Compare the proposal with the thirteen phases in the saved roadmap. Add any omitted phase before allowing Deep research to proceed.

Check that physical construction remains unauthorized. A polished research plan cannot replace missing machine evidence or supervised validation gates.

Help me audit my proposed Deep research plan for missing workstreams or safety gates.

That completes the research control system. You now have a reviewed roadmap that can drive source-grounded projects without turning unresolved assumptions into machine commands.

Secret mission

Red-Team a Tempting Recommendation

External linear actuators can look like the simplest route to loader automation. This mission makes your research workflow challenge that assumption against electrohydraulic actuation and manufacturer-supported interfaces. The preferred option stays blocked until model-specific evidence supports it.

Clean Up Your Resources

Your evidence-locked planning workspace is complete. This project added no ongoing cost beyond your existing ChatGPT Plus subscription because it created planning content only.

Resources you used:

No teardownable resources were created during this project.

Keep everything running

No action is needed. Choose this option if you want the research workspace ready for future machine-specific evidence.

Keep the Autonomous Skid-Steer Program project as your research control center.
Retain the Evidence Gate Register as the record of unresolved inputs.
Apply the evidence gates whenever new manuals or site information arrive.

Pause - I'll come back to this later

A paused state preserves your evidence record while no research run or machine work proceeds.

Leave the reviewed master research brief unexecuted in ChatGPT Deep research.
Keep physical construction unauthorized.
Return to the Autonomous Skid-Steer Program project after collecting exact machine evidence.

Delete - I don't want to use this again

Nothing is running or provisioned, so there is no teardown command to execute. Keep the ChatGPT project as the audit trail showing why physical work stayed blocked.

Confirm that no Deep research run is active.
Confirm that no physical machine work has started.
Close the ChatGPT browser tab to end the session.

Nice Work!

You did it! You built an evidence-locked ChatGPT Project that turns a safety-critical loader idea into a staged research program. That workspace now blocks unsupported machine details until authoritative evidence supports each decision.

What you learned:

Built permanent evidence gates that classify every load-bearing finding. Established a source hierarchy that prioritizes exact machine manuals. Captured unresolved hardware and software claims in cited gap registers.
Defined an evidence-gated Operational Design Domain for private-property travel up to 2 km where people may be nearby. Mapped command authority across every operating mode. Specified a stack-neutral remote operator system with explicit data contracts. Created separate schemas for component connections and the firmware lifecycle.
Prepared a reviewed Deep research brief for the complete autonomous-loader program. Organized the roadmap into independently testable phases from machine evidence through field acceptance. Each phase now has tests, rollback criteria, stop conditions, and continuation evidence.
Secret Mission: Red-teamed the linear-actuator assumption against engineered electrohydraulic actuation. Evaluated manufacturer-supported interfaces as a third option. Recorded the decision as Blocked by missing evidence until model-specific evidence supports a different state.

Ready to quiz yourself?