OSSA SVE · Frequently asked questions

It is a sovereign voice system for telephone operations that enables call automation without handing audio, workflow or organisational rules to an external platform.

Speech recognition and synthesis are designed to run on the client's equipment. This removes the audio round trip to a remote service from the path and allows recordings, transcripts and sensitive data to remain under the organization's policy. In an isolated edition, the design supports operation without external services. Recording, transcription, access and retention are agreed before use. Keeping everything indefinitely is not necessary for good service. The team needs enough context to review transactions and incidents, while handling and access decisions belong to the organisation and must be reflected in the actual configuration.

A language model may interpret intent and draft a response inside explicit boundaries. Workflow state, permitted actions, confirmations and state transitions remain in a deterministic state machine. The model is replaceable. The operation does not depend on its internal behavior. Trials should include ambiguous replies, incomplete information and tools rejecting requests. Those cases reveal whether control holds. When progress is impossible, state is preserved and the planned handoff is used. The aim is not conversation at any cost but service without invented results or permissions.

OSSA is not intended to replace the client's PBX or force a carrier change. It integrates with IP telephony and business systems through declared interfaces. Provider neutrality is an architectural condition: trunk-specific behavior belongs in configuration profiles rather than business logic. Answering and speaking are not enough: transfer and the operator's context must be checked too. Initial scope can focus on one defined process while leaving the remaining switchboard unchanged. Expansion follows a complete journey working over real telephony, not merely a local demonstration.

The conceptual chain separates telephony boundary, conversational orchestration, speech recognition, workflow control, authorized tools, speech synthesis and records. This separation makes each segment measurable and replaceable and helps locate degradation without turning the entire system into a black box. Separation allows alternative recognition, reasoning or synthesis components to be evaluated without redefining process authorisations. Each replacement still needs whole-system testing. The architecture facilitates maintenance; it does not promise effortless interchangeability or identical quality under every configuration.

When a condition is outside scope, a failure occurs or the caller requests it, the system must be able to transfer to a person with available context. The expected degradation path is toward a human or a safe procedure, not silence or an unexplained hang-up. The human path must be checked against the switchboard and actual service hours. An agreed procedure is needed when the destination is unavailable. A model saying it is transferring is not enough: the operation must reflect what occurred and must not present a failed connection as completed service.

The architecture supports a connected edition, where only the reasoning component may use an external provider under policy, and an isolated edition where recognition, reasoning and synthesis run locally. The choice depends on data, regulation, security, required capacity and the actual integration. Running recognition, reasoning and synthesis locally requires suitable hardware and workflow-quality testing. It does not remove telephony infrastructure needed to receive calls. Both approaches are compared using representative cases so the choice follows operational needs rather than abstract privacy or performance promises.