Design Space Map
Design Space Map — Morphological Analysis
Section titled “Design Space Map — Morphological Analysis”This page presents the systematic exploration of 12 design dimensions using morphological analysis. Each dimension represents a fundamental design choice; the chosen combination defines the IOA-ORM’s position in the design space.
Design Configuration Summary
Section titled “Design Configuration Summary”The chosen configuration ({C, B, A, C, A, C, B, D, A, C, B, D}) is characterized by:
- Determinism over flexibility — Policies are structured data, transitions are runtime-approved, evidence is validated before recording
- Separation of concerns — IR ↔ Runtime ↔ Pipecat are cleanly separated; evidence collection ↔ evaluation are separated
- Defense in depth — Multiple layers of constraint (IR policies, runtime guardrails, output validation, context policy)
- LLM as sensor, Runtime as judge — The LLM observes and reports; the Runtime validates and enforces
- Auditability as first-class — Events, evidence signals, and policy decisions are all recorded with provenance
Cross-Dimension Dependencies
Section titled “Cross-Dimension Dependencies”| Dimension Pair | Dependency | Nature |
|---|---|---|
| 1 (IR) → 2 (Layers) | IR enables three-layer architecture | IR provides the semantic richness that justifies a separate Runtime Controller |
| 2 (Layers) → 7 (Autonomy) | Three layers enable three autonomy levels | The Runtime Controller layer is the enforcement mechanism for the advisory/controlled boundary |
| 3 (Communication) → 11 (Transition) | Single function bundles transition proposals | evidenceSufficient in report_observation is the LLM’s transition proposal |
| 4 (Evidence) → 9 (Evidence Output) | Rich taxonomy requires first-class ledger | The eight signal kinds and provenance fields require a dedicated storage mechanism |
| 5 (Policy) → 6 (State) | Structured policies drive state transitions | CompletionPolicy and TransitionPolicy are evaluated by the state machine |
| 7 (Autonomy) → 11 (Transition) | Advisory level enables LLM proposals | The LLM’s evidenceSufficient signal is an advisory action |
| 8 (Events) → 9 (Evidence) | Event protocol delivers evidence signals | evidence_signal events flow through the event protocol to the ledger |
| 10 (Recovery) → 12 (Context) | Recovery affects context management | After recovery, context may need to be reconstructed from events |
Rejected Combinations
Section titled “Rejected Combinations”| Combination | Why Rejected |
|---|---|
| {A, _, _, _, _, _, _, _, _, _, _, _} | No IR = no versioning, no multi-target, no compile-time validation |
| {_, _, _, _, C, _, _, _, _, _, _, _} | Prompt-based policies are not enforceable (Greshake et al., 2023) |
| {_, _, _, _, _, _, _, _, _, _, C, _} | LLM-controlled transitions threaten fairness and reliability (Joughin, 1998) |
| {_, _, _, C, _, _, _, _, _, _, _, _} | Free-text parsing is unreliable for high-stakes assessment |
| {_, _, _, _, _, _, D, _, _, _, _, _} | Full LLM autonomy without runtime guardrails violates safety requirements |
Interactive Visualization
Section titled “Interactive Visualization”For the full interactive design space visualization with QOC evaluation matrices, dependency graphs, and cross-cutting themes, see the Design Alternatives section.