Trust Model and Product Status
This page defines how to interpret Operus safely.
Why this page exists
In agentic finance, trust fails when products mix simulation and live outcomes without clear labels. Operus is explicit about these boundaries.
This page is written for real decision-makers, especially traders, allocators, and institutional users who need to assess exposure quality before allocating capital.
What is real onchain today
Operus already supports selected chain-integrated primitives, including:
- agent identity surfaces
- wallet-connected control interactions
- evidence-linked state transitions where available
These surfaces are observable and should be interpreted according to their documented trust stage.
What is simulation-backed today
Some performance and trade-history views are currently simulation-backed and should be interpreted as such. They are useful for evaluation and iteration, but they are not equivalent to finalized live execution performance.
Trust-staged execution model
Operus follows a staged path rather than a single “live” switch:
- Simulation — strategy behavior and system interactions are tested in controlled conditions.
- Paper-tracked — execution semantics are tested without assuming final live capital outcomes.
- Live-capped — controlled live execution with strict safety and operational limits.
- Live-verified — mature live state with stronger verification and reconciliation semantics.
Operator controls and approvals
Execution-sensitive actions are protected by control gates, including:
- authenticated operator pathways
- policy-enforced permissions
- proposal and decision workflows
- replay-safe request handling
These controls exist to reduce accidental, duplicate, or over-trusted actions.
Evidence and auditability
Operus persists durable evidence to support replay and review:
- proposal and decision events
- quote and build provenance
- lifecycle facts and status transitions
The purpose is to make operational history inspectable, not narrative-driven.
Practical interpretation guide
- Treat simulation metrics as simulation unless explicitly marked otherwise.
- Treat operator approvals as governance and control records, not autonomous execution proof.
- Treat trust progression as a product feature: safety and clarity come before speed.
Allocation-oriented interpretation
If you are making capital decisions:
- Determine whether the surface is simulation-backed, staged, or higher-trust context.
- Confirm that evidence and lifecycle visibility support the interpretation you are making.
- Size exposure according to trust stage and evidence quality, not headline metrics.
What users should not assume
- Not every displayed metric represents finalized live execution.
- Not every approval represents autonomous strategy behavior.
- Not every workflow is public, permissionless, or fully automated today.
- Not every chain-integrated surface should be read as end-state autonomy.
Operus is designed to make these distinctions explicit.
Status at a glance
| Surface | Current status | How to interpret it |
|---|---|---|
| Agent identity | Chain-integrated | Real product surface |
| Operator controls | Active | Safety and governance primitive |
| Evidence layer | Active where available | Review and audit surface |
| Autonomous execution | Staged | Expanding through trust progression |
| Performance views | Mixed by context | Must be read according to label |
Current principle
Operus is designed to go to market fast, but not at the cost of trust. The platform prioritizes secure foundations, explicit boundaries, and staged rollout of autonomous capital capabilities.