alainlebret Domain Context Scenario Builder
Goal
Replace the generic framing of a computing exercise (« écrire un programme qui trie une liste ») with a credible, engaging domain scenario that gives students a realistic professional context without adding technical complexity beyond what the pedagogical objectives require.
When to use
- When
mission.json → audienceis a reskilling or professional audience who expects industry relevance. - When a generic exam question needs to be dressed in a sector-specific narrative.
- When
domain-context-scenario-builderis listed in a workflow'soptional_skills.
Inputs
mission.json— level, domain (if specified incontext), constraintsstatement.mdor draft statement — the generic version to be contextualised
Output contract
| File | Description |
|---|---|
statement.md (updated) |
Revised statement with domain scenario embedded. Core technical requirements unchanged. |
scenario-rationale.md |
Explanation of domain choices: why this sector, which real-world constraints are reflected, what was simplified and why |
Supported domains
| Domain | Typical system | Example scenario |
|---|---|---|
| Aeronautics / drones | Embedded flight computer, telemetry | Log parser for UAV telemetry streams |
| Banking / fintech | Transaction processor, reconciliation | Multi-threaded ledger with atomic transfers |
| Cybersecurity | IDS, packet inspector | Log anomaly detector using sliding window |
| Embedded / IoT | Sensor hub, CAN bus | Real-time sensor aggregator with timeout handling |
| Telecom | SIP proxy, billing engine | CDR parser with rate limiting |
| Healthcare | Medical device firmware, EHR sync | Patient data anonymisation pipeline |
| Energy | SCADA, smart grid | Demand-response scheduler with constraints |
Rules
- The domain framing must not increase the cognitive load of the exercise. If the scenario introduces vocabulary students must learn first, simplify it.
- Technical requirements (input/output format, language, tools) remain exactly as defined in
mission.json. - State explicitly what is realistic and what is simplified. Do not mislead students into thinking the scenario is production-grade.
- Use fictional but plausible entity names (companies, systems, datasets) — never real company names or real systems.
- The scenario must be consistent with the academic level: an L2 student should not need industry knowledge to understand the context.
Anti-patterns
- Scenarios that require understanding domain-specific regulations (GDPR, DO-178C) when those are not in the learning objectives.
- Scenarios that imply a specific implementation architecture that conflicts with the reference solution.
- Names or situations that could be culturally insensitive or politically charged.