This workspace supports two separate reviews. First, make the simulated transaction behave like a real matter of that type. Second, make Gustav's SITREP logic interpret that matter correctly. Only after those two are clear should you hand back exact source changes.
1. Model the transaction
Review the simulated emails, tasks, documents, deadlines, and contradictions. If those signals do not resemble a real matter, fix them before touching SITREP logic.
2. Model Gustav's judgment
Once the transaction is realistic, review whether specialists and the orchestrator are weighting blockers, milestones, resolutions, and recommendations correctly.
3. Hand off implementation intent
Write down the legal and commercial judgment behind the change so engineering can update prompts, typed sections, simulation scripts, and evaluation logic coherently.
1. Transaction realismEdit scenario sources so Gustav sees the right chronology, actors, blockers, and resolutions.
2. SITREP judgmentEdit specialist and orchestrator logic so Gustav reaches the right conclusions from those facts.
3. Engineering handoffDocument what should change in source, why it matters, and what rule or section shape must be preserved.
How to use this workspace
Pick a matter type and load the current source pack.
Start with Model the transaction and decide whether the scenario looks like a real matter.
Move to Model Gustav's judgment only when the scenario is producing the right signals.
Use Handoff to record the legal rule, the source file to change, and how later evidence should change status.
Export markdown when the draft is ready to hand back to engineering.
Good comment: “Once the CSSF acknowledgment arrives, this should move from blocked to waiting for filing completion.” Bad comment: “Make this better.”
What SITREP is
SITREP is Gustav's matter-intelligence output: the summary, priorities, section state, and recommended actions after the system interprets current matter signals.
What simulation is
Simulation is the synthetic transaction activity Gustav is exposed to: emails, tasks, documents, deadlines, delays, confirmations, and contradictions.
What you are editing
You are editing the actual current source files that shape the simulated transaction, the SITREP reasoning logic, and the matter-type behavior Gustav should learn.
Draft not saved yet.
Step 1. Model the transaction
Start by making the synthetic matter look like a real transaction before touching SITREP reasoning.
Transaction realism
Goal
Questions
Expected output
System model
Simulation
Creates the matter signals Gustav will see.
Specialists
Turn those signals into section-level state.
Orchestrator
Turns section state into summary, priorities, and actions.
Matter Brief
Capture the intended legal behavior, typed section design, and implementation handoff separately from the raw source code.
Editable matter-type brief
SITREP Logic
Edit the prompt files and matter-type specialist logic once the transaction model is realistic.
Simulation Source
Start here. Edit the scenario sources that shape which facts Gustav will encounter and in what order.
Handoff notes
Write the reasoning behind the source edits. The goal is to explain the legal and commercial rule Gustav should follow, not only to leave wording comments.
Decision / intended behavior
State the legal judgment Gustav should encode. Example: “Once first-close is effectively secured, unresolved setup tasks should no longer dominate.”
Evidence and status rules
Describe what evidence upgrades, downgrades, or resolves an issue for this matter type.
Simulation change notes
If the scenario itself is unrealistic or missing key signals, note that here.
Prompt / source change notes
Point at the exact prompt or source behavior that is wrong today.