Neutral runtime contract
Read this page to understand how OSuite describes runtime families, adapter modes, authority boundaries, and approval enforceability in one shared vocabulary.
What it is
The neutral runtime contract is the shared language OSuite uses to compare different runtime families without pretending they all expose the same control depth.
When to use this page
Read this page when you need to answer one of these questions:
- which runtime family am I integrating
- how close is OSuite to execution
- who owns execution versus final authority
- can approval really pause side effects, or is it only visible after the fact
Runtime families
| Family | What it usually means |
|---|---|
| OpenAI-compatible and SDK-driven runtimes | Common starting point for governed decision loops |
| Managed agent platforms | Strong enterprise fit, but often weaker tenant-visible governance by default |
| Tool-hook and framework runtimes | Better when governance needs to sit close to development-time execution |
| Observer and import lanes | Useful when evidence arrives after execution rather than inline |
Adapter modes
- inline governance checks
- lifecycle hooks
- session adapter
- runtime bridge
- observer import
- managed-runtime projection
Each mode changes interception depth. It does not change who closes final authority.
What you should check in practice
For any runtime, confirm these points:
- whether pre-action admissibility happens inline or post-hoc
- whether approvals can pause execution before side effects
- whether session and tool identity survive replay
- whether runtime-stage receipts are complete, partial, or absent
What you will see in OSuite
These contract details show up in replay, runtime summaries, proof exports, and buyer-facing runtime packets. They are useful only if the same vocabulary survives implementation, review, and export.