External Workspace

Transaction and SITREP Review Workspace

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 realism Edit scenario sources so Gustav sees the right chronology, actors, blockers, and resolutions.
2. SITREP judgment Edit specialist and orchestrator logic so Gustav reaches the right conclusions from those facts.
3. Engineering handoff Document what should change in source, why it matters, and what rule or section shape must be preserved.

How to use this workspace

  1. Pick a matter type and load the current source pack.
  2. Start with Model the transaction and decide whether the scenario looks like a real matter.
  3. Move to Model Gustav's judgment only when the scenario is producing the right signals.
  4. Use Handoff to record the legal rule, the source file to change, and how later evidence should change status.
  5. 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.

    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.

    Implementation Notes

    Engineering-facing handoff: migration notes, typed sections, renderer implications, eval implications.