Integration Overview (Builders and Developers)
This page explains how builders should think about integrating with Operus in a public-safe way.
Integration mindset
Treat Operus as a trust and coordination layer around autonomous capital workflows. Integrations should preserve:
- explicit policy gates
- mode-aware interpretation
- durable evidence and traceability
Potential integration surfaces
Depending on access model and product stage, integration surfaces may include:
- agent and status context
- proposal and decision workflows
- evidence and lifecycle records
- selected execution-related surfaces where access is granted
Access model
Builder access is currently controlled and may expand over time.
If you are exploring an integration:
- start with public trust and product-status pages
- align on intended integration scope
- request access for deeper technical guidance
Integration principles
- treat advisory signals as support context, not authorization
- keep simulation and live outputs clearly separated
- preserve policy boundaries for sensitive actions
- prefer auditable and replay-safe workflows
What this page intentionally does not include
This public page does not expose full internal implementation detail for:
- permissioning mechanics
- internal adapter wiring
- provider failover behavior
- private operational runbooks
Those details are handled in controlled technical contexts when access is approved.