Public Product Notes
Integration Boundaries
A public-facing explanation of how SimOracle thinks about integrations, APIs, and external systems without publishing sensitive endpoint details.
Integration model
SimOracle treats integrations as authority-bearing pathways, not simple connectors. If an external system can change customer state, schedule work, move money, send messages, update records, or trigger operational consequences, it belongs inside the authority model.
Route families, not public endpoint promises
- Health and status
- Voice-first product interaction
- Decisions, approvals, and autonomy state
- Memory, learning, and policy
- Knowledge and context
- Operational views
- Audit exports
Implementation principle
The visible product experience remains one cognitive surface. Supporting routes and integrations exist to make governed workflows work, not to imply a broad unmanaged public API. Production integration details should be scoped per customer, permission model, and workflow.
What to ask in implementation
- Which systems are read-only?
- Which systems can change external state?
- Which actions require approval?
- Which action types can become autonomous?
- What audit record is required for each action?
- What fallback exists if an integration fails?