Public Product Notes
Architecture Overview
How the visible voice-first surface maps to cognitive orchestration, memory, simulation, policy, execution, and audit layers without exposing proprietary internals.
Public architecture model
Publicly, SimOracle should be described as one voice-first cognitive intelligence system. The user does not need to understand internal workers, orchestration details, or private infrastructure to evaluate the product.
The useful mental model is a layered system: surface, context, reasoning, simulation, authority, action, and audit.
Layered system
- Operating surface: voice-first and text-capable interaction
- Context layer: active case, customer, domain, and prior-session context
- Memory layer: persistent facts, decisions, and relevant prior work
- Simulation layer: consequence comparison before action
- Policy layer: authority, constraints, approvals, and escalation rules
- Execution layer: drafts, handoffs, routed work, and bounded actions
- Audit layer: evidence, rationale, approval, action, and outcome records
SimCore boundary
SimCore is the reusable reasoning model behind the product story. It reasons over state, constraints, authority, uncertainty, and downstream effects so each Oracle can apply the same pattern to a different pressure system.
When a use case requires agent-scale scenario modeling, SimOracle simulations can deploy up to one million agents. The public claim should focus on what that scale enables: consequence-aware recommendations, visible authority boundaries, and progressively safer autonomy. Specific implementation methods and internal orchestration patterns should stay out of public docs.
Design decisions
- One visible product surface is easier for buyers to trust than exposed internal machinery
- Authority boundaries are first-class because autonomy without review is not credible in high-stakes domains
- Domain pages explain where the pattern applies without requiring separate product taxonomies for every market
- Docs disclose the system model and buyer-facing behavior while protecting implementation details
What stays private
- Internal orchestration implementation
- Provider-specific runtime details
- Customer-specific prompts, policies, data paths, and integrations
- Unreleased roadmap mechanics
- Security implementation details that would reduce operational safety if exposed