|
2 | 2 |
|
3 | 3 | Extropy has three phases, each mapping to a package under `extropy/`. |
4 | 4 |
|
| 5 | +## CLI Pipeline |
| 6 | + |
| 7 | +``` |
| 8 | +extropy spec → extropy scenario → extropy persona → extropy sample → extropy network → extropy simulate → extropy results |
| 9 | +``` |
| 10 | + |
| 11 | +All commands operate within a **study folder** — a directory containing `study.db` and scenario subdirectories. Data is keyed by `scenario_id` rather than `population_id`. |
| 12 | + |
5 | 13 | --- |
6 | 14 |
|
7 | 15 | ## Phase 1: Population Creation (`extropy/population/`) |
@@ -242,22 +250,44 @@ All Pydantic v2: |
242 | 250 |
|
243 | 251 | ## Storage (`extropy/storage/`) |
244 | 252 |
|
245 | | -Canonical store: `study.db` (SQLite) |
| 253 | +Canonical store: `study.db` (SQLite) in the study folder root. |
| 254 | + |
| 255 | +### Study Folder Structure |
| 256 | + |
| 257 | +``` |
| 258 | +my-study/ |
| 259 | +├── study.db # Canonical data store |
| 260 | +├── population.v1.yaml # Base population spec |
| 261 | +├── scenario/ |
| 262 | +│ └── my-scenario/ |
| 263 | +│ ├── scenario.v1.yaml # Scenario spec (references base_population) |
| 264 | +│ ├── persona.v1.yaml # Persona rendering config |
| 265 | +│ └── network-config.yaml # Optional custom network config |
| 266 | +└── results/ |
| 267 | + └── my-scenario/ # Simulation outputs |
| 268 | +``` |
246 | 269 |
|
247 | 270 | ### Tables |
248 | 271 |
|
249 | | -| Table | Contents | |
250 | | -|-------|----------| |
251 | | -| `agents` | Sampled agent attributes (JSON) | |
252 | | -| `network_edges` | Social graph edges with weights and types | |
253 | | -| `agent_states` | Current simulation state per agent | |
254 | | -| `exposures` | Exposure records with source and channel | |
255 | | -| `memory_traces` | Agent memory entries | |
256 | | -| `timeline` | Simulation events (JSONL-style) | |
257 | | -| `timestep_summaries` | Per-timestep aggregates | |
258 | | -| `simulation_runs` | Run metadata and status | |
259 | | -| `simulation_metadata` | Checkpoint state | |
260 | | -| `chat_sessions` | Post-sim agent chat sessions | |
| 272 | +| Table | Contents | Key | |
| 273 | +|-------|----------|-----| |
| 274 | +| `agents` | Sampled agent attributes (JSON) | `scenario_id` | |
| 275 | +| `network_edges` | Social graph edges with weights and types | `scenario_id` | |
| 276 | +| `agent_states` | Current simulation state per agent | `run_id` | |
| 277 | +| `exposures` | Exposure records with source and channel | `run_id` | |
| 278 | +| `memory_traces` | Agent memory entries | `run_id` | |
| 279 | +| `timeline` | Simulation events (JSONL-style) | `run_id` | |
| 280 | +| `timestep_summaries` | Per-timestep aggregates | `run_id` | |
| 281 | +| `simulation_runs` | Run metadata and status | `run_id` | |
| 282 | +| `simulation_metadata` | Checkpoint state | `run_id` | |
| 283 | +| `chat_sessions` | Post-sim agent chat sessions | `session_id` | |
| 284 | + |
| 285 | +### Scenario-Centric Keying |
| 286 | + |
| 287 | +Agents and network edges are keyed by `scenario_id`, not `population_id`. This allows: |
| 288 | +- Multiple scenarios to share a base population spec |
| 289 | +- Each scenario to have its own extended attributes merged at sample time |
| 290 | +- Clear association between agents/network and their scenario context |
261 | 291 |
|
262 | 292 | --- |
263 | 293 |
|
|
0 commit comments