Simulation Model Documentation Assistant

1. Go to claude.ai and sign in, or create an account.
2. Look for Projects in the left sidebar.

What you should see: A Projects section, empty until you create your first one, alongside your regular chat history.

1. Click Create project (or the equivalent new-project button in the sidebar).
2. Name it something specific to the engagement, like "Retail Network Optimization, Client X." The name is a label for you, the model doesn't use it as instructions.
3. In the description or custom instructions field, describe what the project is for and what kind of documentation help you want.

What you should see: A new, empty project workspace with a Files or Knowledge panel, usually on the right side of the screen.

1. Find the custom instructions field for the project (often under project settings).
2. Write a short instruction describing the documentation format you want: assumptions, methodology, limitations, whatever structure your firm expects.

Example custom instructions:

This project tracks documentation for a client optimization model. When I share code or describe a design decision, help me draft or update documentation with three sections: Assumptions (what we're taking as given and why), Methodology (how the model works, in plain language a non-technical stakeholder could follow), and Limitations (what the model doesn't account for). Keep the tone factual, not promotional. Flag anything I describe that sounds like an assumption I haven't stated explicitly.

1. In the project's Files or Knowledge panel, click the + or Add content button.
2. Upload your model's code file, plus any existing notes, even rough ones (each file up to 30MB).
3. Every chat you start inside this project will have access to these files automatically, so you won't need to re-paste them each time.

What you should see: Your uploaded files listed in the Knowledge panel, available to reference in any conversation within the project.

1. Open a new chat from inside the project (not from the main chat list, which won't have your files).
2. Ask for a first draft of one documentation section based on the uploaded code.

What you should see: A structured draft matching the format from your custom instructions, referencing specifics from your actual model rather than generic boilerplate.

This is the habit that makes the whole workflow pay off. Every time you make a real design decision, log it in a quick message to the project.

1. After a decision (a constraint choice, a parameter value, a simplifying assumption), open the project chat and describe it in a sentence or two.
2. Ask Claude to fold it into the running documentation draft.

Example:

I just decided to model warehouse capacity as a hard constraint rather than a soft penalty, because the client confirmed there's genuinely no overflow option this quarter. Add this to the Assumptions section with that reasoning.

Documentation drifts out of sync with code fast. When you make a significant change to the model itself, re-upload the updated file to the Knowledge panel so future drafts reflect the current version, not an earlier one.

1. Near the end of the engagement, ask for a complete, consolidated documentation draft pulling together everything logged throughout the project.
2. Read it against the actual final model. Documentation built incrementally can still drift if a late change didn't get logged.